Federated Identity Management Willem Elbers (MPI-TLA) EUDAT training Date: 26 June 2012
Outline FIM and introduction to components Federation and metadata National Identity federations and inter federations Attributes Issues Summary
Federated Identity Management Federated Identity Management (FIM) is about technologies, standards and use-cases which serve to enable the portability of identity information across otherwise autonomous security domains 1 A typical use-case with FIM is the (web-based) single sign-on scenario where a user signs in once with his/her home organization and can access multiple services hosted at different organizations. Technologies: Shibboleth, Oauth, simplesamlphp, Standards: SAML 2.0, 1 http://en.wikipedia.org/wiki/federated_identity_management
Identity Provider (IDP) Typically running at the users home organization Authenticates a user Connected to a user store (LDAP, database, ) Configures attributes to release Decides which service providers to trust In case of shibboleth just a java web application deployed in a servlet container
Service Provider (SP) Typically running at the organization providing the service Makes an access control decision based on the attributes and/or supplied identity information Redirects the user to a login endpoint if no identity information is available Can be an individual IDP Can be a where are you from page Decides which identity providers to accept Decides which attributes to accept In case of shibboleth installed into apache
SP Attribute Filter SP attribute map configuration (attribute-map.xml) SAML1 and SAML2 naming nameformats default nameformat: SAML1 = urn:mace:shibboleth:1.0:attributenamespace:uri SAML2 = urn:oasis:names:tc:saml:2.0:attrname-format:uri Our mapping for edupersonprincipalname: <Attribute name="urn:mace:dir:attribute-def:edupersonprincipalname" id="edupersonprincipalname"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" id="edupersonprincipalname"/> <Attribute name="urn:mace:dir:attribute-def:edupersonprincipalname" nameformat="urn:oasis:names:tc:saml:2.0:attrname-format:unspecified" id="edupersonprincipalname"/>
Shibboleth and Apache Load shibboleth module LoadModule mod_shib /shibboleth-sp/lib/shibboleth/mod_shib_22.so Protect a path <Location /ds/imdi_browser> AuthType shibboleth ShibRequireSession On ShibUseHeaders On Satisfy All Require valid-user </Location>
Where Are You From (WAYF) A typical FIM use-case is an SP accepting users authenticated by a (large) number of IDPs. How does the SP decide which login endpoint the user needs to be redirected to? Where are you from page Let the user select the IDP he/she wants to authenticate with In the case of shibboleth there is a default WAYF page, other alternatives are e.g. DiscoJuice 1 Default WAYF: http://lux17.mpi.nl/ DiscoJuice: http://catalog.clarin.eu/ds/componentregistry/# 1 http://www.discojuice.org
SAML 2.0 Security Assertion Markup Language 2.0 is a version of the SAML OASIS standard for exchanging authentication and authorization data between security domains XML based protocol using security tokens containing assertions to pass information about a principal between an identity provider and a service provider Metadata creates the trust relation between IDPs and SPs based on exchanged public keys
SSO Flow Schematic redirect interaction Redirect to login endpoint WAYF Redirect to IDP Where are you from? I am from MPI-TLA Protected Resource Service Provider Request access to a resource Provide resource or deny access Example User Who are you? I am Willem Elbers Identity rovider Identity rovider Identity rovider Set authentication information and attributes And redirect back to original request location
Identity Federation (IDF) Group of IDPs and SPs that trust each other Trust relation created by legal contracts Defined in metadata By trusting each others keys Within the IDF users can use a single identity to access all services SPs trust IDPs loaded by metadata IDPs trust SPs loaded by metadata Building federations is establishing the legal contracts and creating and exchanging metadata sets with IDPs and SPs that trust each other
Metadata IDP example 1 <EntityDescriptor entityid="https://idp.clarin.eu" > <IDPSSODescriptor.> <Extensions>...</Extensions> <KeyDescriptor>...</KeyDescriptor> <SingleSignOnService Location="https://catalog.clarin.eu/mw/shibboleth-idp/profile/Shibboleth/SSO"/> </IDPSSODescriptor> <AttributeAuthorityDescriptor > <Extensions>...</Extensions> Provide backwards compatibility <KeyDescriptor>...</KeyDescriptor> <AttributeService Location="https://catalog.clarin.eu/mw/shibboleth-idp/profile/SAML1/SOAP/AttributeQuery"/> </AttributeAuthorityDescriptor> <Organization></Organization> <ContactPerson contacttype="technical"></contactperson> <ContactPerson contacttype="administrative"></contactperson> </EntityDescriptor> 1 full metadata files available at http://idp.mpi.nl/metadata
Metadata SP example 1 <EntityDescriptor entityid="https://sp.catalog.clarin.eu"> <SPSSODescriptor > <Extensions></Extensions> <KeyDescriptor></KeyDescriptor> <SingleLogoutService Location="https://catalog.clarin.eu/Shibboleth.sso/SLO/SOAP"/> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat> <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat> <ManageNameIDService Location="https://catalog.clarin.eu/Shibboleth.sso/NIM/SOAP"/> <AssertionConsumerService Location="https://catalog.clarin.eu/Shibboleth.sso/SAML2/POST" index="1"/>. <Organization></Organization> <ContactPerson contacttype="technical"></contactperson> </SPSSODescriptor> </EntityDescriptor> 1 full metadata files available at http://idp.mpi.nl/metadata
Setting Up Technical (Shibboleth case) Service provider Requires certificate 0.5 1 day to set-up Identity provider Requires certificate 1-2 day(s) to set-up Integration with applications (depends on set-up) Legal (Joining federations) Signing contracts Can take a long time Maintenance Mostly keeping the metadata up-to-date Connecting new IDPs, SPs or federations can take a long time due to legal issues
The national IDFs & edugain Seemed obvious to use FIM provided by the national academic IDFs and especially the EU edugain interfederation, at that moment (2009) a pilot project. We hoped for: transparent participation for SPs and IdPs standard attribute set Not too worried about attribute harmonization since Authorization in CLARIN usually on basis of identity and signed licenses IdP1 SP2 user attributes Identity Federation What makes the federation - Metadata - Agreements: - technical e.g. SAML2 - Legal contracts SP1 IdP2
Using edugain IDF a SP1 The CLARIN SPs are members of their national IDFs Rely on the edugain interfederation to provide the necessary exchange of metadata Contracts, metadata & attr. exchange SP3 IDF c IDF b SP2 edugain homeless users?
Academic IDF Attributes IDF Mandatory Further remarks DFN-AAI sn, email, eppn, epsa, epentitlement, eptid,(*) What is the predominant unique identifier for end users? eppn, eptid Is there a policy for what should be used as the unique ID? No. HAKA cn, sn, displayname, edupersonprincipalname, schachomeorganization, schachomeorganizationtype Currently, eppn is the predominant unique ID. The federation operator has published instructions on use of eptid but hasn't strongly insisted its use. SURFfed None The predominant unique identifier for end users is eppn. There is no formal policy for what should be used as the unique ID From: https://refeds.terena.org/ (*) within DFN-AAI we see no compliance with the official DFN attribute policy. There is confusion why attributes do not appear. Some claim DFN privacy policy is the cause. More likely the Universities have their own policy
Solutions for getting attributes I How do we get the right attributes to the SPs? Advice users without the required attributes to contact their IdP and leave it to them. bad idea, you will have few users Attribute release consent modules (uapprove) will help IdP administrators to agree on providing all possible attributes. Have appropriate fall-back configuration to come to a unique user identifier (eppn, etid, email). Have the applications query the user when other attributes are required.
Solutions for getting attributes II Lobby for mandatory attribute release policies of national IDFs and edugain Create an external VO-Platform (central user attribute provider) providing all the required attributes (and perhaps some other useful information) SPs will get all required attributes with correct semantics. Can still rely on user authentication at the home institute Possibly inconsistent attributes Who manages this probably very big DB? However if everything else fails we have no other option. In view of the attribute release problems in Germany, CLARIN D has decided to create a CLARIN IdP that will cater for all German users in need.
Homeless IdP There are users also from countries without a proper IDF For these a homeless IDP can be used with a simple registration procedure Also used by users with IDPs not releasing the correct attributes The verification of these users identity is limited. The IdP is therefore not part of any national IDF and (CLARIN) SPs are warned not to expose sensitive data & services to these users. homeless users?
Basic components Federations National IDFs Summary How to minimize administrative overhead? Attributes How to ensure all required attributes are supplied by the IDPs? Same attribute provided in different flavors Catering for users without a (national) IDF Homeless IDP Different level of trust for these users
Questions Thank you for your attention
Think of parsers, taggers, translators, aligners, speech recognizers, Language Technology R Currently often still use download first, process and store paradigm For efficiency need to use a Service Oriented Architecture (SOA), where only remote processing takes place Add to that a way of combining distributed services in a workflow with interaction with resource repositories Tools like this exist in a more or less usable form: TAVERNA, GATE, Weblicht,... Workflow Editor S WF specification Workflow Engine R WS1 WS2 WS3 tokenizer POS tagger NE recognition
Web service security/delegation in workflows delegation dataflow federated authentication tokenizer Web Application Workflow engine parser parsera parserb Composite Web service (distributed) web-services semantic tagger repository
1 Possible solution using OAuth2 In cooperation with BiG- GRID we have been 4 Portal WS 1 3 2 IdP SAML assertion Exchange assertion for token investigating different solutions + Oauth2 scenario seems to support much of what we need + Constrained delegation - Need for a central AS AuthZ Service WS n