Shibboleth Development and Support Services WAYFs and... · 2005-11-29 · Shibboleth Development and Support Services JISC CM Programme Meeting, Windermere 14–15 November 2005

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?

Will try and get people out on time for coffee and biscuits

have therefore hidden a number of slides with more details

if time, will take questions at the end


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

Stolen from Sandy’s talk tomorrow

Federation has 56 entities today

Eleven institutional & departmental IdPsEight production services: five EDINA services converted + 3 MIMAS

Understand technology, not just deploy it. Try and help move it forward a little.

The Discovery Problem

SPSMHIdPAuthentication Request

Start with a user, making use of a client by which we mean a browserUser’s client approaches SP, SP has no existing sessionUser wishes to make use of identity from a particular IdPdiscovery problem is how to let SP and IdP communicate“something magic happens”Result is that the SP’s authentication request can reach the IdPIdP authenticatesIdP sends response to SPSP authorises



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

[this slide is not part of the presentation, but will be available in the archived version]



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

Rest of talk will be about different techniques to make “something magic happen”

Traditional Model

Federation

SP

SP

SPIdP

IdP

IdP

WAYF

<md/>

Emphasise: WAYF is not a Shibboleth component, but *A* solution to the discovery problem

This model has a number of failure modes

Because of the limited time available we will concentrate on

the most obvious one

which is that it doesn’t (can’t) work in the presence of SPs and IdPs that are members of multiple federations



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

Multiple identities: WAYF will offer all IdPs, even those that won’t let you in to the resource.

Sub-federation: tight group of IdPs and SPs within a much larger federation. You get offered all the IdPs in the federation, whereas only some small subset are relevant

First two items are confusing for users: too much information

Non-federations: SPs and IdPs can communicate with each other without formal federation membership, no centralised discovery system can be aware of this.

Portals: many institutional users don’t really need to “discover” where they are from

Multiple federations: this is one we can do something about

Example: Shibboleth Wiki

Example of the centralised WAYF model’s failure mode for multiple federations

Note selection of login buttons, one per federation leading to WAYFobviously not scalable

Worse, if you don’t remember to log in explicitly, automatic session invokes one of these WAYFs (InCommon one)

Not a good user experience and likely to get worse with time



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

Three target environments



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

SAML discovery cookie format allows a list of recently used IdPs

each configuration appears at a different URL

effect is that you can run any number of WAYFs for the price of one

one WAYF deployment can support multiple user experiences, multiple user communities

Old (1.1/1.2) WAYF

This is the familiar old WAYF from 1.1/1.2 days

Has been pretty much unchanged over that time, until the run-up to 1.3

22 IdPs in the drop-down list for SDSS at present

Drop-in Replacement

This is the new WAYF pretending to be the old WAYF

Drop-down at right (Scott’s) has Do not remember Remember for session Remember for a week

Revisit WAYF

Old WAYF would always go straight through to last IdP

New one has that as a configurable option

Note clear button; there is also a cookie clearing service which can be used when the WAYF is configured for “straight through” operation

Multi WAYF example: Shibboleth Wiki

This is the new WAYF in multi-federation mode

The request sent to it is for the Internet2 Shibboleth Wiki, which is a member of InCommon, InQueue and SDSS

Initial state is that all IdPs are visible in right-hand box

Click on a federation in the left-hand list and the right-hand list narrows

This is just an example of what you can do for presentation. The new code is an improved toolbox, not a prescription for what all WAYFs have to look like.

Automatic Federation Filtering

This is the same multi-federation WAYF sent a request for a my test SP, which is a member of SDSS and InQueue, but not InCommon

The WAYF has filtered out the whole InCommon federation, because nothing in InCommon will talk to my SP. It knows this from the metadata.

This means I can get to my SDSS identity, and also my OpenIDP.org identity but I am not offered InCommon IdPs

Less to choose from means a less confusing interface

This filtering is configurable. You can turn it off in a testing configuration, for example.

Different JSPs

Each configuration can have a different JSP, or they can all share the same one.

This is a random example of use of a custom JSP with everything cut out.

Its the sort of thing you might put in an SP login page that has other things on it as well.

Resisted the temptation to make something outlandish: better to make it look recognisable and avoid user confusion from multiple discovery UIs.

SUMMARY: We have improved the WAYF relative to some current issues, but we don’t think that makes a centralised WAYF always the best solution



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

http://www.sciencedirect.com/

Observations: does NOT talk about Shibboleth does NOT include all 168 InQueue IdPs

for the particular circumstances of this SP, this is a much better user experience than any central WAYF could hope to offer



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

http://elibrary.lse.ac.uk/

LSE Portal Links

This is just “zooming in” from the previous page.



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

Skip right past this, it is there only to show how horrible the link is.



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

This is a Shibboleth authentication request direct to the IdP providerId says who is asking (SP entity name) shire says where to return the answer target says where to go after that



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

This is not what session initiators were originally intended for!



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

By client, again, we mean the user’s browser as before



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

PAOS (reverse SOAP) ability is signalled by an HTTP PAOS header containing urn:liberty:paos:2003-08 and indicated acceptance of the application/vnd.paos+xml MIME type



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

But, not the only client-centric discovery mechanism on the horizon



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

Metasystem: important to understand that this is not a new identity system per se (not another technology like Passport!) but a mechanism for working with other underlying identity systems.

There is a separate hidden slide with references to blogs for Kim Cameron and Andy Harjanto. Cameron’s Laws of Identity worth reading for anyone working in this area.

Vista (ish) Sep 2006

Shipping: some indications it might appear in IE7 for XP, too

Cards: imagine not just “ID card”, credit card etc., but also things like Starbucks frequent flyer card.

Includes the idea of self-asserted identities.



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

In the Windows implementation, identity selection is firewalled so that there is no way to script it or access it programmatically. This is intended to help prevent phishing.

InfoCard

24Source: Microsoft

Explicit permission from Andy Harjanto to use images from his PDC talk.

This should probably be regarded as an “artist’s impression”



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

Support in Shibboleth 2.0 may have to be limited to SAML-only, for example.

Some signs that the Firefox team may pick this up, also Safari

In a way, the extended timescale is good: something like this needs to be tried



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

Documents

Shibboleth Development and Support Services WAYFs and... · 2005-11-29 · Shibboleth Development and Support Services JISC CM Programme Meeting, Windermere 14–15 November 2005