Punching data to the authentication server TNC 2002, 05.06.2002 - PowerPoint PPT Presentation

Gabriel
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Punching data to the authentication server TNC 2002, 05.06.2002 PowerPoint Presentation
Download Presentation
Punching data to the authentication server TNC 2002, 05.06.2002

play fullscreen
1 / 18
Download Presentation
Punching data to the authentication server TNC 2002, 05.06.2002
280 Views
Download Presentation

Punching data to the authentication server TNC 2002, 05.06.2002

- - - - - - - - - - - - - - - - - - - - - - - - - - - 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