Identity Federations - Overview Marco Fargetta - INFN – Italy (marco.fargetta@ct.infn.it) EthERNet e-Research Hackfest – Addis Ababa (Ethiopia)
Identity Management
Authorisation
Remote Identity
Single Sign-On
SAML distinguish two main resources SAML Federation SAML distinguish two main resources Identity Provider (IdP) Service Provider (SP) Federation is a group of resources They sharing a common policy Are managed as a single entity The authentication is always between an IdP and a SP The federation establish only the initial trust among the resources
A user want to access an SP SAML Authentication A user want to access an SP The user is redirect to a Discovery Service It can be an external service or embedded in the SP Allow the user to choose the IdP The user goes back to the SP with the ID of the own IdP The user is redirect to the IdP Authentication is performed The user goes back to the SP with the authentication All the steps above are associated with a SAML assertion (it is an XML)
SAML Authentication
SAML Authentication was mainly designed for WebServices Authentication flow SAML Authentication was mainly designed for WebServices It is possible to implement other type of resources Either web based or native application Resources can support multiple SAML profiles The profile identifies the exchange protocol and the message format Most used profile for web application is redirect The browser show a page with a javascript performing the redirect
IdP keeps tracks of user authentications Single Sign-On IdP keeps tracks of user authentications Multiple requests from different services require to authenticate only once Although services can require different information Attribute release has to be confirmed and authorised by the user This is not implemented in all the IdP software Discovery service could store the user selection If this is the case users could have problem to change the IdP in the future
Each SP is responsible for the authorization of the accessing users SAML Authorisation Each SP is responsible for the authorization of the accessing users Authorisation is not federated The federation is responsible to uniform the attributes used by the resources and create the trust among the entities The user authentication is point-to-point between the two involved resources
An SP can apply the authorisation in different ways SAML Authorisation An SP can apply the authorisation in different ways Accept all the federated users Accept federated user according to some filters User of a subset of IdPs User with some specific value in the attribute Perform an authorisation request step in the SP Some tools are emerging to perform federated authorisation but not widely adopted Not needed for many SPs
A federation is not needed to use SAML Using SAML A federation is not needed to use SAML Authentication is point-to-point in any case IdPs can be deployed to test new SPs services Many public IdPs available for test Simple SPs can be deployed to test IdPs It can be a single web page GrIDP federation provide a test federation where new services can be tested together with some production services
The resource will be tested to identify technical problem, e.g.: Join a federation To join a federation the service should be properly configured to use SAML The resource will be tested to identify technical problem, e.g.: Misconfiguration with some attributes Missed information on the SAML description The organisation has to sign an agreement with the federation Could require to define a policy for the user complying with the federation rules
Resources can be aggregated into a federation Inter-Federation SAML authentication can be used among a bunch of resources by configuring all the connections Resources can be aggregated into a federation Can be either a national federation or a federation with trans-national scope Federation can be aggregated into a inter-federation eduGAIN is the biggest inter-federation
Delegation to multiple service and REST APIs Delegation is possible but over complicated The delegation allows to demand a service to operate on behalf of the user A profile for native application is available and could be used to access REST APIs but has many limitation If APIs are stateless the authentication has to be performed at every request Too computational and network demanding
AARC blueprint architecture AARC is a EU project aiming at define authentication and authorisation for research collaboration Propose to integrate the SAML federation with other technologies best fitting for the problem SAML used to authenticate in a proxy A proxy can release a token for the access to the other services, e. g. SAML <-> OpenID-Connect conversion
Implementation example: the INDIGO-DataCloud IAM service INDIGO-DataCloud is a EU project implementing cloud service for the research communities IAM is the component implementing the SAML to OpenID-Connect proxy Source: Andrea Ceccanti (INFN)
Summary and conclusions Identity Federation allows to connect services with Identities separating the Identity manager from the service manager Many possibility to integrate with SAML federations For specific problems other protocols could be integrated
Thank you! sci-gaia.eu info@sci-gaia.eu