1 / 18

Punching data to the authentication server TNC 2002, 05.06.2002

Punching data to the authentication server TNC 2002, 05.06.2002 Ingrid Melve, UNINETT, Bård H. Moum Jakobsen, Oslo University. Our goal. Access control in heterogeneous, loosely coupled systems Replacing system specific (and single-vendor) access controls

blenda
Download Presentation

Punching data to the authentication server TNC 2002, 05.06.2002

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Punching data to the authentication server TNC 2002, 05.06.2002 Ingrid Melve, UNINETT, Bård H. Moum Jakobsen, Oslo University

  2. Our goal • Access control in heterogeneous, loosely coupled systems • Replacing system specific (and single-vendor) access controls • Protecting user's privacy in cross-institutional authentication • Replacing locally maintained userDB per server with a global authentication mechanism

  3. Data flow, from birth to access control • FEIDE: Common Electronic person IDentity for Education • Authoritative systems • Building a user management system: BAS • Setting up an authentication server, exporting data from BAS • Collaborating authentication servers: indexing and referring

  4. FEIDE system NIS FEIDE AD ?? Server S BAS AT C LT FS AT-index ?? SO Internal AT AT

  5. Operational status • BAS • Operational at UiO • Several colleges partly operational, need to adjust schema • UREG software available • Integrates with Student Registry (FS) • Integrates with one Payroll System (LT) • Unique ID, current use • user@realm User perspective • SSN used internally • Support for multiple ID

  6. Operational status (2) • AT, authentication server • OpenLDAP tested, small scale operational • AT-index • LIMS tested, about to go operational • Plugins for servers • Modified mod_ldap for apache tested, small scale operational • Java-API underway

  7. Birth of data: the punching part • Authoritative data systems • Student Registry (FS or MSTAS) • Payroll Systems (should be Human Resource systems later) • “Others” from “sources” • Defining ownership of user administrative data • Data inserted by administrative staff

  8. Who are your users? • Normal user categories are • Employees • Students • Others/aliens • Delegating rights is an administrative procedure, not the IT-departments department • Thou shallst tidy thy user administration

  9. Seclusion of data: User Management System • Building a BAS • Importing data from authoritative sources • Integrity checking, based on SSN • Data export to Authentication Server, AT • Data export to AD, NIS and others • BAS is the processing part

  10. Privacy of data • FEIDE is designed around protecting the user's privacy • Strong crypto to protect data transfer and storage • Never ask for more than you need • Support for multiple ID per person

  11. Data model: eduPerson++ • eduPerson with extra attributes: • norInstitutionNumber • norOrgUnitNumber • birthDate • norSSN • Supplementary local object classes • norOrganization • norOrganizationalUnit • norPerson

  12. Sharing of data: delivering the punch • Exporting data from BAS to separate server: AT • AT is accessed over LDAP from network service backend • Credential types • Username/password • Certificate • Role definitions • Policy modules

  13. Authentication Index Server • Use LDAP redirects to AT • Indexing LDAP servers by extracting TIO-files • Currently using LIMS-server • Status: testing, about to go operational • Scales with many users (500k) and small number of LDAP-servers

  14. Further work • Authorization • Scaling issues • Support for client certificates and smart cards • Building plugins for more network resources • Integration with perimeter control (Radius)

  15. Who does what? • BAS providers (university) • User administration • FEIDE project • Testing, piloting, handbook • Proof of concept software (GPL) • Legal framework • Operational AT-index • Information and service providers • Replace local user database with authentication to AT (add plugin)

  16. FEIDE system buildup • All Internet services need • A root • A data model • A transfer protocol • Root: AT-index • Data model: eduPerson++, unique IDs • Transfer protocol: currently LDAP

  17. Why LDAP? • The hard part is defining roles and groups and rights, schemas exist (eduPerson, posixAccount) • Cross-platform implementations, sever backends • Read many, write few • Support for X.509 certificates • Indexing information from multiple LDAP servers, build on NEEDS • Familiar technology

  18. More information • http://www.feide.no • Mostly Norwegian information,some in English • feide-bas@uninett.no • bard.jakobsen@usit.uio.no • ingrid.melve@uninett.no

More Related