2003 © SWITCH Realization of a Vision: Authentication and Authorization Infrastructure for the Swiss Higher Education Community Copyright Martin Sutter, This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

2003 © SWITCH / Martin Sutter Page 2 EDUCAUSE 2003 Bologna Declaration - harmonizing Swiss academia - overcoming mobility obstacles - simplifying administration registration & matriculation guest university A guest university B Dept. X Dept. Y Dept. Z home university physical visit e-learning, libraries, etc. (virtual visit) real lectures e-learning other resources (e.g. library)

2003 © SWITCH / Martin Sutter Page 3 EDUCAUSE 2003 user University of Zurich resource owner 1 user - 1 resource - 1 organization:  NO PROBLEM The AA Problem (1) + Swiss Passport info about user step 1: registration step 2: accessing the resource ID, credentials grant / deny ? ID, credentials

2003 © SWITCH / Martin Sutter Page 4 EDUCAUSE 2003 local users - local resources - organizations, but no relations:  NOT REALLY A PROBLEM The AA Problem (2) University Hospital of Geneva users resource C info about user ID, credentials info about user info about user University of Lausanne resource B info about user ID, credentials users info about user info about user resource A info about user University of Zurich ID, credentials users info about user info about user

2003 © SWITCH / Martin Sutter Page 5 EDUCAUSE 2003 University Hospital of Geneva user Z resource C info about user ID, credentials University of Lausanne user Y resource B info about user ID, credentials resource A info about user University of Zurich user X ID, credentials many users - many resources - many organizations anybody from anywhere to anywhere:  A PROBLEM The AA Problem (3) ID, credentials

2003 © SWITCH / Martin Sutter Page 6 EDUCAUSE 2003 organization ID, credentials user registration authentication authorization user DB The AA Problem (4) 1 resource C resource B resource A 2

2003 © SWITCH / Martin Sutter Page 7 EDUCAUSE 2003 The AAI model (1) The core functionality of an AAI, during the authentication and authorization process, must tightly couple the interaction between all involved, namely –the users –their home organizations –the resources The three basic interactions are –user authentication –access request –delivery of authorization attributes The set of authorization attributes has to be configurable and extensible.

2003 © SWITCH / Martin Sutter Page 8 EDUCAUSE 2003 user‘s home organization user info user resource owner resource access control manager access control definition data system Legend: registra- tion registration pre-processing user DB The AAI Model (1) attribute release policy

2003 © SWITCH / Martin Sutter Page 9 EDUCAUSE 2003 resource owner user‘s home organization AAI access control manager resource access control definition user authentication system user DB authentication 1 access request of an authenticated user 2 authorization information delivery of authorization information 3 The AAI Model (2) data system Legend: AAI interaction attribute release policy grant / deny ?

2003 © SWITCH / Martin Sutter Page 10 EDUCAUSE 2003 resource owner user‘s home organization AAI access control authorization manager (authorization) authenti- cation log other applications (accounting, billing, statistics,...) The AAI Model (3) Input to accounting or billing systems: AAI provides identity of user and/or name of home organization resource measures the interactions between a user and the resource

2003 © SWITCH / Martin Sutter Page 11 EDUCAUSE 2003 Connecting Campuses In practice, everything is not so simple… connecting resources to the AAI faces problems campus history commercial products financial considerations …

2003 © SWITCH / Martin Sutter Page 12 EDUCAUSE 2003 resource owner AAI access control manager resource AAI access control definition AAI portal user DB resource owner AAI access control manager resource AAI access control definition AAI proxy user DB AAI Implementation The translation of our AAI concept into reality can be accomplished in three ways: –direct attachment of the resource to the AAI  accessible resource required –indirect attachment of the resource to the AAI, method I  “AAI proxy” as a front end to the resource –indirect attachment of the resource to the AAI, method II  “AAI portal” resource owner AAI access control manager AAI access control definition user DB resource with AAI built-in

2003 © SWITCH / Martin Sutter Page 13 EDUCAUSE 2003 resource owner AAI access control manager resource AAI access control definition AAI portal or AAI proxy user DB personalized “black box” web resources with proprietary access control and user administration examples: - e-learning platforms - standard applications Typical Resources  the AAI proxy / portal is essential

2003 © SWITCH / Martin Sutter Page 14 EDUCAUSE 2003 home organization user authentication and authorization infrastructure AAI enabled resources Portal for Universal Access to AAI AAI proxy non AAI enabled & AAI enabled resources “raw” AAI additional functionality AAI portal

2003 © SWITCH / Martin Sutter Page 15 EDUCAUSE 2003 resource owner resource portal database AAI portal - access control management - e-community management resource database AAI interface AAI Portal

2003 © SWITCH / Martin Sutter Page 16 EDUCAUSE 2003 AAI portal user’s home organization resource user Bob is redirected to his home organization for authentication user Bob is redirected to the resource upon successful authentication Bob is routed back to the AAI portal user Bob contacts AAI portal‘s URL: Function of the AAI Portal

2003 © SWITCH / Martin Sutter Page 17 EDUCAUSE 2003 interface to AAI X interface to AAI Y interface for direct access AAI portal database resource administrator area AAI portal administrator area “plug-ins” for multiple AAI’s Multipurpose / -channel AAI Portal N resource channels per user different portal areas connecting unit resource user area interface to resource U interface to resource V interface to resource W

2003 © SWITCH / Martin Sutter Page 18 EDUCAUSE 2003 e-Academia / AAI Concept (2000) “… let’s develop e-Academia, let us build the foundations in the form of a uniform authentication and authorization infrastructure (AAI) for the higher education system in Switzerland…” “We want a virtual community across our institutions in which all persons associated with the Swiss Higher Education System are able to gain access to its electronic resources, independent of the accrediting organization and independent of the place where they happen to be working.” Vision of e-Academia AAI as the foundation of e-Academia Study Implement. V1.0 PilotConcept Roadmap 2000 Implementation V2.0

2003 © SWITCH / Martin Sutter Page 19 EDUCAUSE 2003 Shibboleth Joint project Internet2 / MACE and IBM Architecture for –vendor-independent web access –operation across institutional boundaries Can securely transfer user attributes Handles existing heterogeneous security systems Uses federated administration

2003 © SWITCH / Martin Sutter Page 20 EDUCAUSE 2003 SWITCHaai Project Planning / Financing Impl. V1.0 Pilot Operation V SWITCH, Pilot Projects SWITCH, Universities, Subsidy (?) Universities Financing of initial and recurring costs: Implementation V2.0 Operation V2.0 - improvements - new releases Implementation V3.0 Operation V3.0 Study V3.0 - accounting 1) - ECTS 2) 1) AAI + accounting = AAA 2) ECTS: AAI/AAA as information carrier

2003 © SWITCH / Martin Sutter Page 21 EDUCAUSE 2003 Central AAI Services SWITCHaai Service Portfolio Service Portfolio Core components Consulting, Training, Test Lab Outsourcing ServicesVirtual Home Org Support Home Org Support Resources AAI access provider Marketing main focus in 2004 on request

2003 © SWITCH / Martin Sutter Page 22 EDUCAUSE 2003 Conclusion and Outlook The AAI for the higher education community in Switzerland is becoming a concrete matter –conceptual questions are solved –prototype projects are running –the infrastructure is being implemented First results are very promising For a fully established AAI continuing joint effort is required In a more distant future the Swiss AAI should be connected to other AAI’s in other countries Q & A

2003 © SWITCH / Martin Sutter Page 23 EDUCAUSE 2003 Unique Identifier (anonymous) Surname Given name Date of birth Gender Address(es) Phone number(s) Preferred language Name of Home Organization Type of Home Organization Affiliation (student, staff, faculty, …) Study branch Study level Staff category Organization Path Organization Unit Path Group membership User attributes for AAI are based on standards (LDAP: eduPerson, SHIS/SIUS) have to be available in real-time have to be handled as required by federal and cantonal data protection laws: attributes have to be accurate attributes have to be stored securely attributes should only be transferred to resources with a valid case to use it. will be revised in the future in a standardised change process, depending on the requirements of Resource Owners and Home Organizations Personal attributesGroup membership Authorization Attributes

2003 © SWITCH / Martin Sutter Page 24 EDUCAUSE 2003 Shibboleth AA Process Resource WAYF Users Home OrgResource Owner 1 SHIRE I don’t know you. Not even which home org you are from. I redirect your request to the WAYF 3 2 Please tell me where you come from HS 5 6 I don’t know you. Please authenticate yourself 7 User DB Credentials OK, I know you now. I redirect your request to the target, together with a handle 4 OK, I redirect your request now to the Handle Service of your home org. SHAR Handle 8 I don’t know the attributes of this user. Let’s ask the Attribute Authority Handle 9 AA Let’s pass over the attributes the user has allowed me to release Attributes 10 Resource Manager Attributes OK, based on the attributes, I grant access to the resource

2003 © SWITCH / Martin Sutter Page 25 EDUCAUSE 2003 AAI simplifies the protection of information by applying standardized mechanisms. Resource owners can concentrate on the protection of their resources without having to implement an entire system including registration and authentication. Information protection AAI makes it possible to authorize users based on personal attributes of a user instead of IP addresses. User authorization thus becomes location-independent. Remote access After a single registration a user can access a number of resources. Only one authentication technology is applied. User friendliness Standardized AA systems and cooperation among IT organizations improve the efficiency in the implementation and operation of security solutions. IT efficiency Without AAI, a user has to register with various organizations. It is feared that the administrative overhead of individual organizations will increase dramatically. AAI counteracts this tendency. Administration overhead Complicated and inconsistent AA mechanisms, or isolation of resources and user groups, respectively, is no longer state of the art. Not having an AAI will damage the image in the long run. Image AAI is a requirement if students of different universities wish to use common resources, and it is the basis for initiatives such as the Swiss Virtual Campus. Virtual Mobility Advantages of the AAI

2003 © SWITCH / Martin Sutter Page 26 EDUCAUSE 2003 Task Force AAI-TF-CA CA Taskforce: final report available – Task Force recommendations: –Step 1: quick and pragmatic solution: Issuing service for server certificates only –Step 2: New separate task force preparing the setup of a issuing service of both server and client certificates Base proposal for step 1 –SWITCH to set up SWITCH-ROOT-CA –Existing and new organisational server certificate CAs get signed by SWITCH-ROOT-CA –SWITCH-SERVER-CA under SWITCH-ROOT-CA issues server certificates –SWITCH customers operate RA (Registration Authority, no dedicated CA required) –Issuing of client certificates excluded, but doable after a policy update