20051114: WAYFs And Discovery

Shibboleth Development and Support Services

WAYFs and Discovery
Where Are You From and Where Do You Want to Go Next?

Ian Young and Rod Widdowson, SDSS

JISC CM Programme meeting, Windermere, 14-15 Nov. 2005


SDSS Project Goals

• Implement a development federation …
… to support other CM projects
… to participate in Internet2 development
… to convert EDINA services

• Gain experience relevant to the creation of a
UK production federation

JISC CM Programme Meeting, Windermere 14–15 November 2005 X

The Discovery Problem

Authentication Request

IdP SMH SP


The Discovery Problem

• User’s client approaches SP
• SP has no existing session
• “something magic happens”
• Result is that the SP’s authentication request
can reach the IdP

• IdP authenticates
• IdP sends response to SP
• SP authorises


Authentication Request

• A Shibboleth authentication request message is
just an HTTP GET with parameters:
– requesting entity
– return address
– resource name
– time (optional)

• Simple, unsigned, format means it can be
generated and relayed easily

• SAML 2.0 AuthenticationRequest complications


Discovery Techniques

• Traditional (centralised)
– WAYF-centric discovery

• Decentralised
– SP-centric discovery
– IdP-centric “discovery”

• Futuristic
– Client-centric discovery

JISC CM Programme Meeting, Windermere 14–15 November 2005 3

Traditional Model

IdP SP

WAYF
IdP SP

IdP SP
<md/>

Federation


Traditional Model

• Federation defines communication boundary
• Collection of Identity Providers
• Collection of Service Providers
• Federation metadata lists entities
• Single central WAYF service
• Works well for “federation of me”



Model Failures

• Multiple identities
• Sub-federations
• Ad-hoc non-federations
• Portals
• Multiple Federations
– no single federation’s WAYF is appropriate
– multi-WAYF can help



SDSS WAYF Contributions

• All of this work is now in Internet2 CVS HEAD
• Bundled with next minor IdP release
• Target environments:
– central WAYF for a federation, but with support for
associated federations
– custom WAYF at individual SPs
– custom WAYF for group of SPs

• Drop-in replacement for existing WAYF



SDSS-Contributed WAYF Extensions

• Multiple metadata files
• Handles 1.1/1.2 and new SAML 2.0 metadata
• Maintains SAML discovery cookie
• Multiple configurations in one deployment:
– different metadata subsets
– different “second visit” behaviour
– different filtering and listing behaviour
– different JSPs


Multi WAYF example: Shibboleth Wiki

Automatic Federation Filtering


SP-centric Discovery

• In many cases, better than WAYF-centric discovery

• Service Provider often knows its community of users
– Particularly true for licensed content, where a real-world
contract will exist
– Contracts trump metadata

• Many possibilities, including:
– local custom WAYF
– custom application logic (e.g., IP address as hint)
– SAML discovery cookie (in 1.3 SP)
– combination approaches

Example: Elsevier ScienceDirect


Application Logic

• For example, IP addresses as hints
• Many service providers know customer IP
address ranges because they are used for non-
Shibboleth authorization

• Good way of detecting (probably) local users
• IP address can only be a hint



SP SAML Cookie

• Built-in in 1.3 SP
• Maintained as list of most-recently used IdPs
• This helps you do your own application logic
• Or, can share cookie with local custom WAYF



IdP-centric “Discovery”

• Shibboleth is normally SP-first, but can be used
IdP-first

• Construct an authentication request on behalf
of desired SP and send it directly to the IdP

• IdP-first access makes the discovery problem
vanish

• Example: institutional portals
• MyAthens is a sophisticated version of this


LSE Link to EIG

https://gate-test.library.lse.ac.uk/shibboleth/HS?
target=http%3A%2F
%2Feig.sdss.ac.uk%2Feiglogin-sso%3Fx
%3D68%26y%3D9%26logout_url%3Dhttp
%253A%252F%252Fedina.ac.uk%252Feig
%252Fshibb.shtml&shire=http%3A%2F
%2Feig.sdss.ac.uk
%2FShibboleth.shire&providerId=urn
%3Amace%3Aac.uk%3Asdss.ac.uk
%3Aprovider%3Aservice%3Aeig.sdss.ac.uk



LSE Link to EIG

• https://gate-test.library.lse.ac.uk/shibboleth/HS
– providerId=urn:mace:ac.uk:sdss.ac.uk:provider:servic
e:eig.sdss.ac.uk
– shire=http://eig.sdss.ac.uk/Shibboleth.shire
– target=http://eig.sdss.ac.uk/eiglogin-sso
 (with encoded parameters of its own)



IdP-centric “Discovery”

• User experience improved: direct from portal to
IdP, direct from there to SP

• Can capture links from a normal transaction
• BUT can be brittle: required link may change
• SP (1.3) can assist by providing session initiator
URL with a providerId parameter indicating
IdP

• Much simpler URL, much more robust


Session Initiators

• SP deployers can assist with IdP-centric
discovery

• 1.3 SP allows definition of “session initiators”
– each session initiator has its own URL

• Session initiator allows parameter indicating IdP
– ?providerId=<IdP entity name>

• Portal link becomes much simpler
• Portal link much less likely to break over time


Client-centric Discovery

• The user knows their own identity (or identities)
• They could communicate this directly to their
client

• Discovery becomes simple selection between
available identities

• Pro: probably the best user experience
• Con: you need to change or extend the browser



SAML 2.0 ECP

• “Enhanced Client or Proxy” profile of SAML 2.0
• So far, used in mobile phones and WAP
gateways

• No desktop implementations known at present
• May be possible to implement as a browser
plug-in

• If so, may be candidate for Shibboleth 2.0
• If not, probably won’t happen any time soon


SAML 2.0 ECP Flow

• Client approaches SP, indicating PAOS ability
• SP responds with a SAML 2.0 AuthnRequest
• ECP code is triggered by this
• ECP interacts with the user to choose an IdP
• ECP relays AuthnRequest to chosen IdP
• ECP relays response to SP



SAML 2.0 ECP

• Pro:
– User experience improved
– Part of SAML 2.0

• Con:
– If browser modifications required, not likely to
happen soon
– If browser plug-in is adequate, user still needs to
acquire it



InfoCard

• Microsoft’s code name for one component of an
“Identity Metasystem”

• Due to be shipped in Windows Vista
• Based on WS-*, particularly WS-Trust, WS-
MetadataExchange and WS-SecurityPolicy

• Can move SAML security tokens around for Shibb
• User experience is like a wallet of plastic cards
• Each card represents an identity at a particular IdP


InfoCard References

• Kim Cameron, Identity and Access Architect,
Microsoft
– http://www.identityblog.com/
– check out the “Laws of Identity” there

• Andy Harjanto, Program Manager, Microsoft
– http://blogs.msdn.com/andyhar/



InfoCard Flow

• Client approaches SP
• SP returns HTML page containing an <object>
tag

• Identity selection user interface triggered
• InfoCard figures out which identities could work
• User selects required identity from those
• Client relays attribute assertion from selected
IdP to the SP


InfoCard

Source: Microsoft 24


InfoCard

• Pro:
– Excellent user experience
– Eventually, really wide deployment expected
– Good candidate for support in Shibboleth 2.0

• Con:
– Memories of Passport still colour discussion
– Non-Microsoft browser story is unclear as yet
– Complex, hard to implement all of it
– Timescale for significant adoption is post-Vista


Conclusions

• Centralised WAYF-based discovery is an essential
backstop for now

• We can improve the WAYF
– but probably not much more

• There are better alternative approaches we can
deploy now
– SPs can implement more intelligent discovery
– Institutional portals can provide shortcuts

• Even better solutions in the future (1-2 years)


Contacts

• Talk:
– Ian: ian@iay.org.uk
– Rod: rdw@steadingsoftware.com

• SDSS project:
– Web site: http://sdss.ac.uk/
– Contact: edina@ed.ac.uk


20051114: WAYFs And Discovery

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (8)

Similar to 20051114: WAYFs And Discovery

Similar to 20051114: WAYFs And Discovery (20)

Recently uploaded

Recently uploaded (20)

20051114: WAYFs And Discovery