Shibboleth Developers

["RL 'Bob' Morgan" <>]

> If you can come up with any context in which Shibboleth and OAuth 
> overlap, I'd be happy to hear it. I haven't come up with anything. (They 
> compose just fine, I'm speaking more about why there's anything 
> Shibboleth should do.)

I wrote a note to the oauth list recently (below) with some speculation 
about use cases and overlap.  Seems to me there might eventually be 
touchpoints (between SAML support and OAuth support in an infrastructure) 
in trust establishment and discovery, and perhaps in consent management. 
This might imply that it would be good for the components of Shib that do 
those things to be separable enough that they could serve OAuth or other 
protocols (there's some of that already in Shib's support of WS-Fed and 
Information Card).

The general question for the Shib project is whether to tackle new 
web-identity protocols as they come up, and add them to the product, or 
whether to focus on what Shib does well (SAML and its supporting elements, 
primarily) and assume that sites that want OpenID, OAuth, 
PortableContacts, XRI, etc can make those integrations work themselves. 
The Shib product does support WS-Fed and Information Card, though in a 
very limited way, consistent with what interest we've seen in the 
community in deploying those protocols.  Real support of a protocol is 
hard and expensive work, and integration of a new protocol into existing 
infra can be even harder, so it's not a decision to be made lightly.

 - RL "Bob"

---

Date: Tue, 20 Jan 2009 15:52:23 -0800 (PST)
From: RL 'Bob' Morgan 
<>
To: OAuth 
<>
Subject: Re: [oauth] Difference between OAuth and Shibboleth


> I am planning to start a project that will use token authorization and 
> was wondering what the difference was between OAuth and Shibboleth. So 
> far, the only thing I gather is that Shibboleth is used more in an 
> educational environment while OAuth seems more commercial... am I 
> missing something else here? They seem to do very similar things, but 
> what are the advantages/disadvantages of using one or the other?

To add to what others have said:

  * Shibboleth is a software package that is primarily an implementation of 
the SAML web browser signon profile.  It also supports WS-Federation and 
Information Card to some extent.  All of these are about doing signon to 
relying parties (ie, web sites with resources the user wants to get to) 
using the services of identity providers.  Shib is notable as a SAML 
implementation in that it puts a lot of emphasis on (a) multi-party 
arrangements (eg http://incommonfederation.org/) and (b) user attributes 
sent as part of the authentication process.

  * I won't try to summarize OAuth here on the oauth list, but will just 
say that it is complementary to externalized identity schemes such as SAML 
and Information Card and OpenID.

By way of answering your advantages/disadvantages question, here's a use 
case I've been speculating about recently.  Today in the Shibboleth 
community we have quite a few instances of affiliation-based 
authorization.  This means, as just one example, getting special student 
deals from a site like http://www.studentuniverse.com/ by proving you're a 
student using SAML signon.  At student signon time a campus IdP sends an 
attribute with a "" value which StudentUniverse trusts 
based on being a federation participant.  This works well and is much 
better than the traditional funky ways these types of sites have had to 
prove studentness.

You could support this scenario via OAuth.  StudentUniverse would be the 
OAuth consumer, the university would be the OAuth provider.  The student 
experience would be to be sent from studentuniverse.com to the university 
site, authenticate, and be asked "share student status with 
studentuniverse.com?".  StudentUniverse could then check that status via 
an OAuth-authenticated web channel whenever they wanted for as long as the 
access token was valid.  This would require us to define schema for 
expressing is-a-student via that channel, as well as the rest of OAuth 
service provider support.

There are a lot of issues to compare and contrast.  Here are a few.

There is some appeal in the OAuth functionality that lets the consumer 
site look up the data whenever it wants after delegation rather than just 
at signon time.  (This could be done by out-of-band SAML attribute 
requests also, but hardly anyone uses SAML that way these days.)  The data 
could include other info about the student also (name, address, email, 
etc; this can be sent via SAML too, in fact name is sent as part of the 
studentuniverse use case).

User consent to delegation is obviously at the center of the OAuth design. 
User consent in Shibboleth has so far been honored more in our design 
philosophy than our implementation; another way to put it is that it has 
been up to deployers to provide features to manage user consent regarding 
attribute release.  There's some work being done to address this in the 
product, where part of the work is to integrate the use of consent in with 
other scenarios where consent isn't needed (eg an employee going to an 
outsourced site for HR services).

With SAML today we have constructed trust communities supporting federated 
signon for lots of different applications (http://www.ukfederation.org.uk/ 
is the largest I'm aware of, with over 600 member organizations).  OAuth, 
today, has no features to support large-scale communities in this fashion, 
it's just pairwise arrangements between providers and consumers. 
Choosing to use OAuth instead of SAML for a use case like the one above, 
in our community, would imply developing those features or bootstrapping 
from SAML or something.

  - RL "Bob"