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