> 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 "[email protected]" 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" --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
