Interoperability Shibboleth and gLite in EGEE-2

1. InteroperabilityShibboleth and gLitein EGEE-2 MWSG Amsterdam Dec 15, 2005 Christoph Witzig SWITCH

2. Outline • Introduction • Presentation of SWITCH • Motivation of AAIs • Overview of Shibboleth • SWITCHaai: the six building blocks • Interoperability Shibboleth - gLite in EGEE-2 • Work in 3 phases • Related work • Policy issues • Summary Inter- operability Organisational Framework Identity Provider Service Providers Central Services Funding

3. Legal Marketing/Sales/PR/Coord. universities Finance/Accounting Human Resources Business Development Strategic planning Technology monitoring International relations Network Management Services Security Internet Identifiers NetServices Domain Names(Registration) Network Infrastructure Incident Handling e - mobility Incident Handling • Invoicing • Administration • Help Desk • Online-Queries • Consulting • SWITCHlambda • SWITCHaai Beratung • SWITCHmobile Critical Infra- structure Protection Network engineering Labor virtual communities Consulting • IP Routing • IPv6, QoS, Multicast • PERT Domain Names (further services) • SWITCHvconf Interne DL HW/OS, Beratung, E-Mail • Collaboration Tools • Added Services for End Users • Added Services for second level service provider • Content Delivery Laboratory and tools Grid technologies Consulting User Registration consulting SWITCH

4. Without AAI University A • Tedious user registration at all resources • Unreliable and outdated user data at resources • Different login processes • Many different passwords • Many resources not protected due to difficulties • Often IP-based authorization • Costly implementation of inter-institutional access Student Admin Web Mail e-Learning Library B e-Journals Literature DB University C Research DB e-Learning User Administration Authentication Authorization Resource Credentials

5. With AAI University A • No user registration and user data maintenance at resource needed • Single login process for the users • Many new resources available for the users • Enlarged user communities for resources • Authorization independent of location • Efficient implementation of inter-institutional access AAI Student Admin Web Mail e-Learning Library B e-Journals Literature DB University C Research DB e-Learning User Administration Authentication Authorization Resource Credentials

6. SWITCHaai Project 2001 2002 2003 2004 2005 2006 2007 Study Pilot Implementation Operation Architecture Evaluation -> Shibboleth

7. Shibboleth • Open Source • Developed by Internet2 • Federated Approach • Privacy • National deployment projects in the US, UK and Finland, growing interest in other European countries • Currenty for web resources only - will be extended • Based on SAML • Cooperations with Liberty Alliance • Cooperations with Content Providers (e-journals) http://shibboleth.internet2.edu/

8. How it works

9. Demo (Try it yourself) • http://www.switch.ch/aai • Live Demo • demo resource http://www.switch.ch/aai/demo/demo_live.html

10. Outline • Introduction • SWITCHaai: the six building blocks • Interoperability Shibboleth - gLite in EGEE-2 • Summary Inter- operability Organisational Framework Identity Provider Service Providers Central Services Funding

11. AAI Identity Provider Operational Getting ready (2005/2006) UniSG ETHZ USZ UniBAS UniZH ZHWIN SWITCH UniNE UniBE UniLU UniFR VHO UniL UniGE USI/SUPSI 120’000 Users of Swiss Higher Education already are AAI-enabled ( = 65% of all users) Identity Providers

12. Directories within an AAI Identity Provider AAI-enabled Identity Provider • Authentication System • any Apache compatible authentication • any Tomcat compatible authentication method • any IIS compatible authentication method • User Directory • Integration via Java APIs • LDAP via JNDI • Databases via JDBC • Username is the link between the two parts AAI AuthenticationSystem UserDirectory Identity Providers

13. VHO Service @SWITCH User Dir Virtual Home Organization - VHO • Integrate End Users without Identity Provider • Resource Owner creates @VHO “AAI-enabled” accounts for users without an Identity Provider • A VHO account is only usable for that resource managed by the Resource Owner Some end users without Identity Provider Federation Member Identity Provider Resource Owner End User Admin VHO Policy Identity Providers

14. AAI Service Providers (Resources) e-Learning Libraries OLAT Vista@SVC EZproxy WebCT@ETHZ VITELS ScienceDirect EBSCO DOIT ILIAS BSCW Moodle … AD Learn & Co Blackboard Other Web Applications Commercial Contents Web-SMS SwissLex CompiCampus eShops IS-Academia Vconf TWiki ca. 50 AAI-enabled hosts, ca. 10’000 active users Service Providers

15. Showcase: DOIT DOIT: Dermatology Online with Interactive Technology Access Rule: HomeOrg = UniZH | UniBE | UniL Affiliation = Student StudyBranch = Medicine StudyLevel = 20 Identity Provider AAI Service Provider (Resource) ETHZ UniZH ZHWIN SWITCH UniBE UniLU VHO UniL UniGE Service Providers http://www.cyberderm.net/ 500 AAI Users

16. AAIportal: Integration of “black boxes” • Authentication/Authorization Gateway • User Management (optional) • Adaptors toBlackbox Applications: • WebCT Vista • WebCT CE • … Sign On Application AAIportal A1 A2 API . . . Shibboleth Service Providers

17. Authorization Attributes (1) • AAI transfers user attributes from a Home Organization to a Resource • Requires a common understanding of what a value means Authorization Attribute Specification v1.1 • A task force selected the attributes for SWITCHaai • minimal set to start with • attributes with pre-existing ‘common understanding’ • in line with foreign activities Interoperation http://www.switch.ch/aai/docs/AAI_Attr_Specs.pdf

18. Authorization Attributes (2) Personal attributes Group membership Group membership • based on eduPerson specification • study branch, study level, staff category are based on SHIS/SIUS • username and password are missing only used locally! • ‘Matrikelnummer’ is missingfor data protection reasons • Unique Identifier • Surname • Given name • E-mail • Address(es) • Phone number(s) • Preferred language • Date of birth • Gender • Name ofHome Organization • Type ofHome Organization • Affiliation (student, staff, faculty, …) • Study branch • Study level • Staff category • Group membership • Organization Path • Organizational Unit Path Interoperation

19. International AAI Activities • Shibboleth deployment underway in: USA (Internet2, InCommon), Finland (HAKA), Switzerland (SWITCH) • Shibboleth related activities in: United Kingdom (JISC), France (CRU), Australia (AARNet), University of Amsterdam (NL), KU Leuven (BE), StatsbiblioteketDenmark • Compatibility with Shibboleth planned for: PAPI (RedIRIS, ES), A-Select (SURFnet, NL), Athens • Terena TF-EMC2 – Task Force European Middleware Coordination and Collaboration http://www.terena.nl/tech/task-forces/tf-emc2/ • GN2 – JRA5 – Ubiquity (Mobility) and Roaming Access to Services Define, prototype and build a roaming infrastructure and an AAI Cotswolds Group - Federations Coordination (Europe, US) Interoperation

20. Organisational Framework Organisation SWITCH acts as SWITCHaai Federation Service Provider Federation membership based on signed service agreements

21. Data Protection / Privacy Issues Data protection laws (Switzerland, EU) allows only to gather personal data that is required The Identity provider may restrict the data release as strict as seen fit Service Provider (Resource) Attributes User’s Identity Provider site.ARP <*.uniXY.ch> UniqueID allow Affiliation allow HomeOrgType allow HomeOrgName allow </*.uniXY.ch> <Resource B> UniqueID allow FirstName allow LastName allow </Resource B> <Resource C> UniqueID allow FirstName allow LastName allow EMail allow </Resource C> Resource Registration Authority Admin Required Attributes Organisation Resource Registry operated by SWITCH) Proposed site.ARP

22. Funding funding / costs pilot project project operational service funded by subsidies funded by SWITCH funded by tariffs 0 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 Funding

23. Central AAI-Services • Strategy & Marketing • International Contacts • Support, Consulting, Training • Providing Federation-specific Files and Configuration Guides • Operating WAYF (Where Are You From Server) • Test-HomeOrg and Test-Resource • Tools (AAIportal, AAIproxy) • Virtual Home Organization • Jump Start Service Central Services

24. SWITCHaai Outlook • Adding new institutions • Adding new resources • New directions: • ECTS (Study) • AAA (Study) • Federation Partners • Interoperability with grid: EGEE-2

25. Outline • Introduction • SWITCHaai: the six building blocks • Interoperability Shibboleth - gLite in EGEE-2 • Work in 3 phases • Related work • Policy issues • Summary Inter- operability Organisational Framework Identity Provider Service Providers Central Services Funding

26. Interoperability Shibboleth - gLite • Part of EGEE-2 proposal (by SWITCH in EGEE NREN Federation) • Focus is on • Interoperability (NO replacement for X.509) • Specific for EGEE infrastructure (VOMS etc) • Integrate, re-use, re-engineer existing code, write new code only as needed • Key Concepts: • Home institution of the user should be the Identity Provider • Home institution provides some attributes • But VO is needed for (grid specific) attributes • Proposal of doing work in three phases: • Two initial, shorter phases with the intention of hooking SWITCHaai up to the grid with a minimal amount of effort to have a working system • A third phase with adding support for SAML at the resource (service provider)

27. Phase 1 and 2

28. Access for Grid Users to Shib SP • Intention: add “symmetry” between enabling access for Shib and grid users • Test-bed SWITCH INFN in 2006

29. SAML Support at the Resource • Third (and main) phase of project • Goal: Support for SAML for authentication and authorization without relying on X.509 (on a configurable basis) • Should be based on SAML2 • Supports ECP Profile (constrained delegation) • Will be used in Shibboleth 2

30. Related Efforts • GridShib: • Emphasis is on providing attributes based authorization • Based on GT4 and Shib 1.3 • Beta version available since Sept 05 • OGSA authZ working group: • Defines specifications for basic interoperability and pluggability of authorization modules in OGSA framework • Condor Shibboleth Merger Project • Phase I: Shib enabled Condor web portal • Phase II: Shib enabled Condor fat client • Shibboleth - grid activities in UK • ESP-Grid • Further work is planned (JISC) to look at CA/Shib issues • Issue of attribute management between IdP and VO (e.g. Signet)

31. Policy Issues for Phase 1 • Question: • what policy shall be formulated for the certificates generated out of SWITCHaai? • Minimum requirements for • SLCS certificates: TAGPMA (recently adopted) • “traditional” certificates: EUGRIDPMA

32. Minimum requirements Minimum requirements for SLCS and traditional user certificates

33. Policy Issues for Phase 1 • Question 1: why two minimum requirements documents? • Wouldn’t it be easier to have one document and simply state the differences where appropriate? • Question 2: Why distinguish between SLCS and “traditional” certificates? • If you really trust your identity management systems, why not generate the traditional certificates?

34. What SWITCH would like to do…. Generation of X.509 by Shib Resource based on AuthN at IdP User generates key pair and submits certificate signing request Admin. Procedures are key for quality of user management System (EUGRIDPMA compliant)

35. Issue of certificates by SWITCHpki • Generation of server certificates as now (unchanged) • Generation of user certificates • If { Shib IdP EUGRIDPMA compliant } then { automatic generation } • Else { user follows “standard” procedures (e.g. picture id) } • Example: • User management of HEP staff physicists of University of Berne follows EUGRIDPMA compliant norms • They have access to Shib resource to obtain their user certificate (with varying lifetime)

36. Advantages • One set of requirements for all certificates • simplicity of policy • One infrastructure to handle all certificate requests • Only valid or revocated certificates at all times • Capitalize on the high standards of the user management system of SWITCHaai • for those institutions who follow the more stringent requirements

37. Summary • There is interest and activity for interoperability AAI / Shibboleth - grid • But X.509 is still the standard security mechanism for grids (and likely to remain so for quite some time) • Issue is not only authentication but also attribute sharing between IdP, VO, SP • GridShib: • beta version available • GT4 and Shib 1.3 • SWITCH looks forward to participate in EGEE-2 to add interoperability Shibboleth - gLite • Implement interoperability Shibboleth - gLite • Policy issues • Building a Swiss gLite grid with our partners (universities, CSCS)