Introduction toFederated Identity
Nate KlingensteinInternet2
ndk@internet2.edu
国立情報学研究所
２００７年６月１日

Today’s Topics• The basics of identity management• Introduction to federated identity
around the world• Relationship to PKI and other systems• How to connect an IdP and SP to yourapplications• Introduction to installing Shibboleth2Why manage identities
yourself?
• Campus people need to be involved• Human resources (HR)• Student information (SIS)• Departments• Application developers & maintainers• Providers of software and services

need to be involved• Without good identity management,
research is hard to do3

The Ultimate Identity
Management Goal
• Deliver the identity information thatan application needs• Sometimes authentication• Sometimes attributes• Sometimes authorization• Securely• Simply4

Good data starts athome• Registration processes• Creating accounts, entering names

and addresses, managing person data

• Figuring out who is responsible for what

• Authentication• Deleting accounts & identities
5Basic IAM Functions
Systems of Record

Student Information System

Enterprise Directory
Registry

LDAP

Human Resources

Join
Reflect
Other

Credential

Basic IAM Functions
Systems of Record

Enterprise Directory
Registry

LDAP

Application
AuthN

Reflect

Application

Join
Credential

Credential

Provision

AuthN/Zbased on local
account

Basic IAM Functions
Systems of Record

Enterprise DirectoryRegistry

LDAPAuthN
Reflect

Application

Join
Credential

Credential

Relay
Attributes

Authentication
andauthorization
using relayed
attributes

Basic IAM Functions
Systems of Record

Enterprise Directory
Registry

LDAP

AuthN
Reflect

ManageAffiliations(Roles)Application

Join
Credential

ManagePrivileges

Relay
Attributes

Authorization
based onreceived
attributes

Good data goes aroundthe world too• Lots of educational applications andservices are now located outside theuniversity• Classes at other universities• Research groups• Content providers/scientific journals• Web-based applications like wiki’s
10Extending Campus
Identity• These outside organizations want toprovide services for campus members• They require information aboutpeople, but the campus is theauthority for this information• The ultimate goal is still the same
• Get the data to the applications securely
and simply

11Federated Identity• In many ways, it’s not a new idea
• Still doing the same things• However, the application and theidentity source can be in differentorganizations• This means you have less control• And things can’t be as tightly
connected

12

Existing technologies are
not perfect• IP Address authentication• Requires people be on campus or use areverse proxy• Monitoring access is difficult• Not very secure• PKI, direct username/password, etc.
• External organization must be able to log
on your users• Trust, revocation, password reading, more
• No attributes
13

Existing technologies are
not perfect• Additional accounts• Yet another username/password toremember• Doesn’t solve the problem of getting
trusted campus data when needed• Possession of email address• *@*.ac.jp• And more
14Federated Identity• “Asserts” an identity in one domain
to access services• In the same or a different domain• Trust between the service provider
and the identity provider is used

• Usually done “out of band” by talking• Sometimes with a federation’s help
15

Federated Identity• Lots of choices• Everyone can use any authentication theywant• Everyone can put attributes anywhere theywant• Everyone can trust who they want to trust• Everyone can use any SAML-based IdP or SP
software they want16

Simplified federated ID
1. I’d like access
2. Where are you from?
3. MySchool-U
4. Go AuthN at home

AuthN

Relay
Attributes

5. Success

5.b Here are the attributes thatyou get to see

Application

Where does federated identity fit?
Systems of Record

Enterprise Directory
Registry

LDAP

AuthN
Reflect

ManageAffiliations(Roles)Application

Join
Credential

ManagePrivileges

Relay
Attributes

Where does federated identity fit?
Enterprise Directory
Registry

LDAP

Federated identity carriesauthentication andattribute information tothe applications
Reflect

Join

ManagePrivileges

Relay
AuthN
Credential

Relay
Attributes

Application

IdP Discovery• How do we determine which campus
a user is from?

• A very hard problem with lots ofpossible answers• I’ll demonstrate two common ways
• Buttons at the application• The “Where are you From?” WAYF Server
20

Let’s try it out!
http://www.switch.ch/aai/demo/
https://kohala.switch.ch/secure/https://www.testshib.org/

21

Some important words• Identity Provider (IdP)
A system that sends information aboutauthenticated users to Service Providers• Service Provider (SP)A system that receives and processes
information about users from IdP’s. It
protects resources and decides to grant
access based on this information.

22

More important words• Assertion
A statement created by an IdP about auser’s authentication or attributes.

• Request
A request from an SP for an IdP to perform
an action to create an assertion.

• Query
A request from an SP to an IdP for
information that alreadyexists
23

Shibboleth• Shibboleth Profile extends SAML 1.1

to add authentication request, handle• Contributed to SAML 2.0 specifications• Shibboleth software is free, opensource implementation of SAML

• 1.1 in Shibboleth 1.x• 2.0 in Shibboleth 2.024

Trust• Federated identity relies on trust

between providers & organizations• The SP trusts the IdP to send true
information about users• The IdP trusts the SP to use attributes
well• Trust can get more complicated thanthis25

Federations• An organization that helps IdP’s andSP’s trust each other• It does a few other important things too• IdP’s and SP’s in the same federation
can work together easily• Federations are starting to connect to eachother too• Fix “handshake” problem
26

Federations around theworld• Australia• Belgium• Canada• China• Denmark• Finland• France• Germany• Greece• New Zealand• Norway• Spain27• Sweden• Switzerland• The Netherlands• United Kingdom• United States

Major Content Providers
that use Shibboleth• EBSCO• JSTOR• OCLC• Elsevier ScienceDirect• Thomson Gale
• Many, many more
28

InCommon• U.S. higher education federation• Over 50 universities and partners• Most major content providers• Many states have their own

independent federations, e.g. Texas

29

Status of Haka Federation (Finland) Operational 8/2005
 23 (of 48) Federation Members•with 213 000 end users (68% of eduPersons; in universities 90%)

 3 Federation partners•

Library content providers, ASP service providers

 13 IdPs operational•with 159 000 end users (51% of eduPersons) 20 SPs
 168 400 logins in March 2007
 federating sw: Shibboleth ver 1.3•

2 IdPs still running Shibboleth 1.2

SPs in the Haka federation
Library services
 Nelli portal (Ex libris Metalib) Library management system(Endeavor Voyager)

Student administration
 Application form for becoming a visiting
student www.joopas.fieLearning Moodle, A&O, Optima learning
management systems

HR administration
 Competence management system/ASP(Personec hr)

CSC’s services
 Funet extranet
 Scientist’s Interface

Other administration
 Process database for universities
WLAN roaming (Jyväskylä polytech)UK Federation• 68 members with many more soon
• Official Shibboleth/SAML-based federation forall of UK education, including K-12

• Replaces Athens, a centralizednationwide authentication solution• Athens will remain as a legacy service,

but cost money, while Shibboleth is free32

Norway’s FEIDE• A lot like Athens, but with SAML 2.0• One Sun Access Manager IdP feeds off many
LDAP directories• Hard road, but working well now• Passwords are given to the central server,which then LDAP BIND’s to campuses• Denmark considering a “hybrid”

model that has both kinds of IdP
33

Federations vs.
Federated Identity• A federation is not necessary to use
federated identity• A single IdP or SP may join manyfederations• IdP’s and SP’s in a federation canmake further agreements together

34

Campus Federations• There is no technical difference

between a federation of many schools
and a federation on campus• Trust may be more close• A campus may have only one IdP• Or in bad cases... several

35

Federating Technologies• SAML 1.1• Shibboleth 1.x Profile• SAML 2.0• Liberty Alliance ID-WSF• WS-Trust, WS-Federation, WS-*
• OpenID• Cardspace36

SAML 1.1
• Defines standard assertion and queryformats• Attribute assertions• Authentication assertions• Attribute Query• Defines protocols for carrying them37

Shibboleth 1.x• Builds on SAML 1.1• Adds an authentication request• “Please authenticate this user and send
them back to me.”• Makes use of a “handle” as atemporary user reference• String for the following attribute query38

SAML 2.0
• Designed using SAML 1.1, Shibboleth,and Liberty ID-FF 1.1 as inputs• The major enterprise federation
standard• Assertions, requests, and queries

39Some SAML 2.0 Vendor
Implementations• Oracle• Sun• IBM• CA/Netegrity• RSA• Novell• Google• Symlabs• Entrust• PingIdentity• Trustgenix• Juniper
40

SAML 2.0
• Protocol bindings place assertions andquestions in messages for transport• SOAP• HTTP• Others are possible

41

SAML 2.0
• Profiles standardize ways toaccomplish common goals using theassertions, queries, and bindings• Web SSO Profile is the most commonly used

• Almost every major vendor has
implemented SAML 2.0 support• But in different ways
• Interoperability, with work42

Cardspace• Built into Windows Vista• User interface for selecting identity
information to access sites• Cards represent an identity at an IdP• Microsoft is funding Shibboleth/Cardspace integration• http://www.identityblog.com/?p=779
43

Liberty Alliance
ID-WSF 2.0• Defines formal SOAP web services foridentity transactions• Getting a new identity token• Transforming existing identity tokens• Uses SAML as a token format• Enables delegation & more
• Not used as much as SAML
44

WS-Security• Places security tokens in SOAP header• Bindings for SAML, X.509, Username/
Password, Kerberos• Works well with other standards• Significant uptake within webservices world45

WS-Trust• A container for identity tokens ofmany sorts• SAML, PKI, Kerberos, etc.

• Provides for transformation of thesetokens from one type to another• “Another layer of generalization”• Increases wire interoperability
46

WS-Federation• Controversial specification developedby IBM and Microsoft. OASIS has aworking group for it, but there aremany complaints• Depends on unreleased specifications• Many parts overlap heavily with SAML

47

Other WS-*
• WS-SecureConversation• Like TLS/SSL, but for SOAP• WS-SecurityPolicy• Allows a SOAP endpoint to describe what it
wants to receive• There are more, some standard, somenot48

OpenID• Came from the world of blogs• How can I log into your blog using myblogging identity when there are many blog
sites in the world?

• Allows a user to prove they are theowner of a URL• This URL is their identity• No XML means simpler installation• HTTP Headers

49OpenID• No trust relationship between
providers• Users are responsible for deciding
whether to trust a URL as a valididentity• URL’s are often exchanged through trusted

communication. “Yasuo emailed me thisURL, and I know it’s Yasuo because we havetalked for years.”
50

OpenID• Can assert authentication• Cannot assert authorization orattributes• But, some are trying to add attributesupport• Doesn’t cover all institutional needs• Very popular outside, though• Use campus login for some OpenID sites?
51