1. Punching data to the authentication server
TNC 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 FEIDE Server S ?? Internal NIS ?? AD BAS AT C LT FS
AT-index
Internal SO AT AT

5. Operational status BAS Unique ID, current use 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 perspective
SSN used internally
Support for multiple ID

6. Operational status (2) AT, authentication server AT-index
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) FEIDE project
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 Root: AT-index
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 feide-bas@uninett.no
Mostly Norwegian information, some in English