Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
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
• 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"/>
default nameFormat:SAML1 = urn:mace:shibboleth:1.0:attributeNamespace:uriSAML2 = urn:oasis:names:tc:SAML:2.0:attrname-format:uri
Shibboleth and Apache
• Load shibboleth moduleLoadModule 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. DiscoJuice1
– 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
Iden
tity rovid
erId
entity ro
vider
SSO Flow Schematic
Ide
ntity ro
vider
Service Pro
vider
WAYF
Pro
tected R
esou
rce
Request access to
a resource
Provide resource or
deny access
Where are you
from?I am from
MPI-TLA
Who are you?
I am Willem Elbers
Redirect to login endpoint Redirect to IDP
Set authentication information and attributes
And redirect back to original request location
User
redirect
interaction
Example
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 example1
<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>
<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
Provide backwards compatibility
Metadata SP example1
<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
IdP2
IdP1
SP2
Identity Federation
What makes the federation- Metadata- Agreements:
- technical e.g. SAML2- Legal contracts
SP1
user attributes
Using eduGAIN
SP2
SP3
SP1
IDF a
IDF b
homeless users?
IDF c
eduGain
• 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
Academic IDF AttributesIDF Mandatory Further remarks
DFN-AAI sn, email, ePPN, ePSA, ePEntitlement, ePTID ,(*)
What is the predominant unique identifier for end users? ePPN, ePTIDIs 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?
Summary
• Basic components
• Federations
• National IDFs
– 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
Language TechnologyThink of parsers, taggers,
translators, aligners, speech
recognizers,…
• 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, ...
WS1
WS2
WS3
tokenizer
POS tagger
NErecognition
R
R
Workflow
Engine
Workflow
Editor
S
WFspecification
Web service security/delegation
in workflows
federatedauthentication
dataflowdelegation
CompositeWeb service
Web Application
tokenizer
parser
semantic tagger
Workflow engine
parserA
parserB
repository(distributed)web-services
Possible solution using OAuth2• In cooperation with BiG-
GRID we have been
investigating different
solutions
• + Oauth2 scenario seems
to support much of what
we need
• + Constrained delegation
• - Need for a central AS
Portal WS1
IdP
AuthZService
SAML assertion
Exchange assertionfor token
12
3
4
WSn