20051114: wayfs and discovery

Shibboleth Development and Support Services

Ian Young and Rod Widdowson, SDSS

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

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


JISC CM Programme Meeting, Windermere 14–15 November 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

X

The Discovery Problem

SPSMHIdPAuthentication Request



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

X



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

X



Discovery Techniques

• Traditional (centralised)

– WAYF-centric discovery

• Decentralised

– SP-centric discovery

– IdP-centric “discovery”

• Futuristic

– Client-centric discovery

3

Traditional Model

Federation

SP

SP

SPIdP

IdP

IdP

WAYF

<md/>



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”

X



Model Failures

• Multiple identities

• Sub-federations

• Ad-hoc non-federations

• Portals

• Multiple Federations

– no single federation’s WAYF is appropriate

– multi-WAYF can help

X

Example: Shibboleth Wiki



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

6



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

7

Old (1.1/1.2) WAYF

Drop-in Replacement

Revisit WAYF

Multi WAYF example: Shibboleth Wiki

Automatic Federation Filtering

Different JSPs



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

13

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

X



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

X



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

15

Example: LSE Portal

LSE Portal Links



LSE Link to EIG

18

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:service: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)

X



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

19



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

X



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

20



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

21



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

X



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

X



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

22



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/

X



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

23

InfoCard

24Source: Microsoft



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

25



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)

26



Contacts

• Talk:

– Ian: [email protected]

– Rod: [email protected]

• SDSS project:

– Web site: http://sdss.ac.uk/

– Contact: [email protected]

27

20051114: wayfs and discovery

Technology