On Tue, Apr 28, 2009 at 1:00 PM, John Kemp <j...@jkemp.net> wrote: > > Hi Brian, > > On Apr 28, 2009, at 1:36 PM, Brian Eaton wrote: > >> >> On Mon, Apr 27, 2009 at 8:25 PM, pkeane <pjke...@gmail.com> wrote: >>> I'm happy with OAuth for the typical sorts of social networking, >>> photo-sharing, etc. use cases, and I use it for that. But I'd very >>> much like to be able recommend it for more highly secure scenarios >>> here on campus (I work in higher ed) that might involve confidential >>> records. For OAuth to replace or be used in conjunction with the >>> cuurent campus SSO and federated systems like Shibboleth, we would >>> really need that extra level of verifiable security. >> >> Hi Peter - >> >> SSO systems such as SAML/OpenID/others all use the equivalent of a >> callback token to bind the session at the identity provider to the >> relying party. The fix to the OAuth protocol is to make it look just >> like the "campus SSO and federated systems" that you mention above: >> >> OpenID: signature on authentication response. >> SAML POST profile: signature on authentication response. >> SAML artifact profile: random single-use artifact value. >> >> All of those systems pass a value that is unpredictable to the >> attacker to a trusted location at the consumer site. None of those >> systems force the user to do anything as obnoxious as manually type a >> pin at the consumer site. > > All of these protocols are for Web-browser based SSO, and establish > the trust between the consumer and SP (using the OAuth terminology) by > relying on Web-browser technologies (ie. an HTTP redirect sent through > the user's browser assures that the browser is the same one at SP as > it was at consumer). >
Hi John- On our campus this is indeeed true -- SSO relies on web browser technologies. In cases when we need to authorize third party services (we currently have Blackboard as a "consumer" for our digital asset management "service provider") we have implemented something similar to OAuth. The problems currently under discussion are not an issue, since we DO have consumer authentication (users must sign into Blackboard) and the we use the same AuthN mechanism in both places (our SSO). > I do not think the assumptions of OAuth are the same as for those > protocols. At least not currently. And I would be wary of going that > way without more thought. > >> If you think manually typing a pin increases security, you should >> explain the attack you're trying to prevent. Why should OAuth have >> such a requirement if SAML and OpenID don't? > > > I think the security requirement is that you ensure that the entity > making a request to the consumer to start the OAuth process is the > same entity which is authenticated to the SP. Are you arguing that the > callback URL suffices in that regard? > I agree that ensuring that u...@consumer (either at the start OR when requesting access token) == u...@sp is the key. The main reasons I have for pushing this are: 1. it guards against scenarios we do not yet envision (like "whitelisting good guys" rather than trying to "blacklist bad guys") 2. it offers the chance to keep the protocol very simple (perhaps even make some things simpler), although at the expense of a slightly more cumbersome user experience. --peter > Cheers, > > - johnk > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
