Co-ordination & Harmonisation of
Advanced e-Infrastructures
for Research and Education Data Sharing
Research Infrastructures
Grant Agreement n. 306819
Identity Federations for Scientific
Collaboration
Luděk Matyska & Michal Procházka
E-AGE 2012
Dubai 13 December 2012
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

2
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

3

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)
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

4

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
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

5

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)
Identity Federations – Schema
6
Figure from http://www.skyworthttg.com
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

7

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
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)



8
Eduroam
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

9
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
10
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


Find Identity federation that covers IdPs with users you are interested in


Just affiliation, name, e-mail, more detailed info, …
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
11
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, …
12
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
13