1. Co-ordination & Harmonisation of Advanced e-Infrastructures for Research and Education Data Sharing Research Infrastructures Grant Agreement n. 306819 Identity Federations for Scientific Collaboration Luděk Matyska & Michal Procházka E-AGE 2012 Dubai 13 December 2012

2. Identification/Authentication  Digital identity and physical identity – prove the connection  Authentication  Process to identify an entity like person, server, …  Commonly used methods are based on  Knowledge (password)  Possession (token, key, fingerprint)  Accomplishment (language, special pronunciation)  Appropriate for mutual authentication  Both sides know something before the authentication can proceed  Problematic in large scale 2

3. Problems of large scale  Number of services asking for authentication grows  “Old” authentication methods impractical  Agreement on a common authentication protocol impossible  Leads to independent per service authentication protocol  Users posses too many passwords/tokens  One password/token per service too large set  Sharing passwords between services potential security weakness  Breach on one service may endanger another service  Service provider needs to manage users  Runs some identity management, implements own authentication  New mechanism to stop password/token explosion  PKI (X.509 certificates) deployed, but rather cumbersome  Still requires an additional token (the certificate) to be kept by user  Additional management overhead (e.g., token expiration and renewal) 3

4. Identity Federations – the Principle  Two basic components  Identity Provider (IdP)  Service Provider (SP)  Identity provider  Service that runs some identity (user) management system  Usually home organization of a particular user (university, company, …)  Makes the authentication decisions  On behalf of unlimited number of external services  Service provider  Any service that requires authentication  User’s authentication delegated to the Identity provider  Authorization (who can use the service) still done by the service itself  Relied from implementation of own authentication mechanism and own identity (user) management system 4

5. Identity Federations – Properties  All authentication delegated to IdP  IdP selects the authentication mechanism  Responsible for identity management (including legal implications)  Can provide simple or complex information  Simple: User is/is not authenticated  Complex: Properties of the user (e.g. is student/employee, is male/female, has a particular position, …)  Complex information release in a form of attributes  Service provider must trust the IdP  Trust the authentication decision  Trust the attributes released about users  The trust requires some formal relationship between IdP and SP  However, it does need to know the real identity of users  Knowledge that some organization authenticated you may be sufficient  General attribute may be sufficient (e.g., you are student) 5

6. Identity Federations – Schema 6 Figure from http://www.skyworthttg.com

7. Identity Federations  IdP and SP must have a mutual relationship  Attributes may contain private information – IdP needs to know that this information is not misused  The attributes are released by IdP not user – user is limited by the agreement between IdP and SP and can not reveal more  May only limit which attributes are released  This process does not scale well – Identity Federations  IdPs create a federation whose representative deals formally with any SP interested in used authentication from IdPs in the federation  Federation agrees on common rules (e.g. which attributes can be released)  SP deals only with the federation (its representative), no need to deal with individual IdPs  IdP just joins the federations, dealing with SP delegated to the federation representative 7

8. Practical considerations  Different implementations: OpenID, Oauth, …  Large scale identity federations: Google login., Facebook login, …  SAML based identity federations very common in academic/research environment  Tens of academic identity federations in production  Usually a national scale  Operated by NREN  EduGain (Europe)  Interfederation at the global level  Another step in dealing with the scalability problem  Currently more a framework to define common policies  InCommon (USA), AAF (Australia), SWITCHaai (Switzerland)  Eduroam 8

9. Example of Service Provision  Web based pathology atlases (http://atlases.muni.cz)http://atlases.muni.cz  Thousands of high resolution images from optical microscope  Extensive annotations and accompanying text  Authentication to protect images from robotic downloads  Local registration offered  Large user base (currently almost 30 thousand users)  Needs just simple information  go for Identity Federation  Part of Identity federation since 2008  Currently connected to 17 Identity federations  Largest set of IFs for one service in the world  Requires only simple attributes (name/e-mail)  Almost 10% of registered users came form Identity federations  Source of a lot of experience in working with Identity federations worldwide 9

10. Some drawbacks  The IdP – SP relationship  Legal work both on IdP (or federation) and SP sides  Implied formal/legal responsibilities  Users (and SP) must wait till IdP and SP sign the contract  IdPs are not directly motivated to go through this process  SP relies on IdP  Service cannot be provided when IdP inaccessible or down  Attributes must come from one IdP only (if it does not have or is not willing to reveal them, no simple remedy exists)  The quality of released attributes usually not formally certified  User cannot influence the IdP – SP relationship 10

11. Deployment Principles  You developed new service, willing to offer it to the community, but want to restrict access to identified users  Define what you need to know about a user  Just affiliation, name, e-mail, more detailed info, …  Find Identity federation that covers IdPs with users you are interested in  More than one Identity federation may be identified  Agree about attributes and policies for their release with selected Identity federation(s)  Install appropriate middleware at your service and connect it with your authorization mechanism  Publish your SP within the Identity federation(s) – users will start coming  You own/manage identity management system  Consider attaching IdP service to it  Identify Identity federation you would like to become member of, agree on technical/political aspects  Install the appropriate middleware, register within federation 11

12. How It Helps  Identity federations help primary users  to access services that require authentication  without need to register again, accept new authentication mechanism and create and maintain new digital identity (new login/password or token)  lowering thus barriers for use of new services  Identity federations help service deployment  Even services that requires authentication can easily attract users as they do not need to learn new authentication mechanism  Reliable authentication can be deployed without actual interaction with users  SP trusts IdP that the information provided is valid and that IdP can reveal identity of user in case of (serious) problem  Ideal for wide deployment (even cross border deployment easy)  Publishers of scientific literature are already in  Wikis, e-learning systems, content management systems, … 12

13. Conclusion  Federated identity a clear improvement over previous approaches  Does not force user to create and remember new passwords/tokens  Appropriate for Single Sign On  Simplifies authentication process for service providers  Federations decrease administrative overheads for IdPs  Ideal for wide scientific collaboration  When IdP established, a wide rage of services can join/connect  Easy to deploy for new service  No need to deal with the authentication and user’s habits  However, it is an infrastructure, so it needs some care  Motivate identity management systems owner to setup IdP over them  To keep federations flexible, willing to find agreement with service providers  Encouraging users and service providers to use it 13