Identity F ederations for Scientific Collaboration

1. 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

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)

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

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)

6. Identity Federations – Schema 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

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

9. Example of Service Provision • Web based pathology atlases (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

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

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

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, …

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