Bart Kerver - Bart.Kerver@surfnet.nl TERENA Storage-meeting, Amsterdam, 29 June 2007

1. Federated Identity Management for the context of storage Bart Kerver - Bart.Kerver@surfnet.nl TERENA Storage-meeting, Amsterdam, 29 June 2007

2. Agenda (ca 30 minutes) Introduction Authentication & Authorization Infrastructures • What is an AAI? • Why the need for an AAI? Federations • What is federation? • Why federate? • Federations are happening! • Global flow • Limitations current feds’ Storage • requirements for storage • SURFnet GRIDdrive project (no summary )

3. Introduction XACML monitoring network logging authorization WS* database accounting registration identification SAML sso dsml ID-FF authenticate directory provisioning access control management dirxml SPML users network resources identities

4. What is an AAI? AAI: Authentication and AuthorizationInfrastructure: • identification/authentication of users; • gathering of identity information of a user (attributes); • authorize users (apply and release attributes); • transport of the assertions; important component: ‘trust’. …and if this is all in place, you’re able to: • provision (eg. create a ‘profile’ for an ELO); • personalize (eg. apply a ‘role’ in an ELO); • control access to resources. Examples:Star Alliance, banking, eduroam, CreditCard …

5. Why the need for an AAI? • Ease of use: less passwords, Single Sign-On, authenticate at home institute; • Collaboration of institutes (national/international); • Mobility of users on the network and among institute (Bologna act, European Credit Transfer System - ECTS); • Growing need for access control and personalization; • Centralized AAI has great (positive) impact on for maintenance/management/security/costs, etcetera.; • Easy to add additional services (resources/content).

6. What is federation? • It’s a formal federation (‘collaboration’) of organizations focused on creating a common framework for trust in support of research and education. • A federation is an association of organizations that use a common set of attributes, practices and policies to exchange information about their users and resources in order to enable collaborations and transactions. So… it’s all about sharing resources • Federation has two main pillars: • procedures/policies (fe. schema, trust, …) • technical implementation (fe. pki, eduperson, metadata, technology) • Federations are not about a certain product but should be build on standards (fe. SAML/Liberty/WS*).

7. Why federate? AAI on different levels with own complexity, eg.: • Faculty (local management of identities) • University (centralize identities / setup IdM!) • National (federate) • International (con-federate) Growing number of service providers and inter-institutional communication results in 1 to N relationships... A B wanted ? C D Identity provider service provider central components for federation

8. Federations are happening HAKA • Applications outsourcing their users • To the home institution of the user • To a single place at the home institution • Academic identity federations are operational • Real services used everyday by large amount of users • Research and educational applications are federated • Federation software available in the marketplace • Identity2.0 aka CardSpace • Making "identity" tangible to users • Convergence is there • With SAML as lingua franca • How to connect all of these federations • ‘Con-federate’ DK-AAI JISC federation

9. Global flow (web!) 1: Access resource at SP 2: you are not authenticated, go to federation 4: Select your IdP (WAYF) 3: What IdP’s are available? 5: I want to authenticate 6: Please supply credentials to authenticate 9: Access to resource granted 7: You are authenticated and authorized, go back to the federation and carry the authentication assertion 8: Redirect to SP with authentication assertion

10. Limitations current ‘feds’. • Federations focus on either network (eduroam - RADIUS) or access to web (http) resources (aka Shibboleth) or are build for GRIDs (fe. Globus/GRID). • Different versions of federations do not interact well (better to say are ‘different worlds’). Good initiative: GRID-Shibboleth (GRIDSHIB). • Commonly federations implement only profiles/bindings for web (http) resources: eg: web-redirects, but standard (SAML) does support others; • Identity Management solutions at Identity Providers commonly only support authentication for federated access based on web (fe. PubCookie, CAS, mod_ldap, A-Select, PAPI);

11. Requirements for storage? Suggestions, idea’s, challenges!? • Mixed access? • Application/API level (webservice?) • Webbrowser access (webdav?) • Persistent identity for storage profile (fe. other federated identity shouldn’t mean loss of profile and therefore data!) • Initially dual identification/authentication methods (both federated and local)? • Use of federation standards, not really converging standards of GRID and federations for web (fe. certificates vs SAML) – how to cover/choose?

12. Project GRIDdrive • SURFnet technology scouting for GRID; • End-to-End security (encryption); • Both web service interface (applications) and browser interface (web) client; • Initially Amazon S3 storage provider, but back-end to other storage providers (storage grids) possible; • Runs virtualized in Amazon EC2 (Elastic Computing Cloud); (bigger load more virtual hardware); • Access only through SURFfederation.

13. Architecture GRIDdrive

14. Federated IdM (authN)

15. Interface (web)

16. Questions ?