[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: OAuth as a potential HTTP server-to-server binding for SAML
Hi, I wanted to share some slides I put together and notes from a recent meeting to see if there is any interest in the community to taking this forward. Eve kindly took the notes for the meeting and I'm including them here. I've also attached the slides. Hopefully, between the notes and the slides, the concepts/possibilities are clear. If not, I'd be happy to discuss on the next call. Regardless, I'd appreciate any feedback. Thanks, George Attending: Eve, Frederick, Hubert, Paul, Conor, Marc, Gael, George George's slides didn't come up at the last TEG meeting, but Hubert was specially interested in them because of their potential applicability to the RESTful ID-WSF framework. We asked George to present his slides. George's thinking in putting this together (and sending some mail to SSTC) was: AOL wants to leverage SAML messages in a server-to-server environment, without using SOAP. The existing HTTP bindings are all browser-based. AOL implemented a "delegated authentication" scenario with its own enhancements and with SimpleSign. It's "back-channel federation". The "delegated authentication" API uses a non-standard HTTP Authorization header with a SimpleSign posted AuthnRequest. A successful response is a SimpleSign'd SAML Resposne message. A different API, "federated login" (for IdP-Intitated SSO), also uses SAML, SimpleSign and some query parameters. The goal is for both SAML Assertions to be the same so host processing logic is consistent. OAuth came into his thinking because it's a secure API call over HTTP. The Concordia DIDW presentation from Patrick touched on SAML/OAuth combinations. Bootstrapping into OAuth wasn't of interest to AOL; rather, OAuth as a protective binding for SAML that's traveling server-to-server. You could leverage OAuth's RSA-SHA1 signature method and SAML's metadata to exchange key material somehow. Hubert notes that XML Signature can contain keyinfo, so that's a benefit of using it instead. George is wondering about adding keyinfo data as an optional parameter in the call, to make it more similar to SAML mechanisms. Or you could use a signed XRDS to convey this data. (It's out of scope for OAuth to say how this material gets exchanged.) For OAuth, "three-legged" is the normal case: consumer, service provider, and user. Messages are signed with both the consumer secret and the access token secret. "Two-legged" is for when you don't have an access token secret, just a consumer secret; you're signing on behalf of yourself, not the user. It's not "identity-based" (or rather, as Marc notes, it has only two identities, not three!). In OAuth, the access token secret represents a ton of info: the user's consent etc. The OAuth spec folks could probably do a lot to separate out some of the access token data, but George hasn't had much success convincing them of this. In George's AOL scenario, the user's identity is just a payload in the request. It's very much about delegating authentication to a partner server. OAuth doesn't assume the user is necessarily online when the request gets conveyed (as long as the token is still valid), but the user had to be online to give the consent etc. Yahoo is working on extensions to OAuth that limit the validity period -- which is today typically forever. Today, all data must be encoded in a form parameter in order to be signed. This gives flexibility to add more data, so it's not all bad. Patrick's DIDW presentation involved SAML bootstrapping into a traditional OAuth three-legged scenario. OAuth's response messages aren't currently signed, and aren't expected to go through proxies. George observes that it seems you request a "unauthorized request token", and then the user authenticates and the access token gets created; George wonders why the former and latter can't be created simultaneously and passed through the browser. George's idea of an "OAuth SAML binding" proposes a specific combination of SAML and two-legged OAuth for RESTful server-to-server communication between SAML parties. We already have a SOAP binding that has its own implications for software stacks etc., and the Web 2.0 community for various reasons isn't interested. Hubert points out that the RESTful framework he's working on has steps like service registration; could this binding be used for those communications? It seems yes. OAuth is similar to SimpleSign in the way it signs messages but doesn't require any front-channel communications (and different browsers tend to handle base64 strings differently, breaking interop). You could URL-encode a SAML message and then URL-decode it to help solve this. Using base64 types of solutions, you run into the SimpleSign problem. It would be nice to leverage existing libraries for OAuth. Marc asks about other parameters in the form. OAuth allows adding whatever POST parameters you want. Mostly, the actual signature and invocation data is preferred to be in the authorization header, but they can be norml POST parameters. If you're just exchanging SAML messages, you could have one parameter for a "SAML message" and be done. OAuth leverages the authz parameter for the three-legged (user-present) scenario; for two-legged, you don't really need it. Are all the right HTTP headers included? Good question! Signing other headers for integrity would likely be of interest depending on the scenario. Replay threats are mitigated through timestamps and nonces mentioned in the main OAuth spec. George's slides present some interesting questions: Should SAML Assertions always be exchanged for OAuth AccessTokens and AccessSecrets? Should there be a way to exchange an AccessToken/AccessSecret for the “equivalent” SAML Assertion? What about making the AccessToken be a SAML Assertion URI? - or SAML Assertion ID? Impacts of using a signature method other than RSA-SHA1? Marc observes that in a generic OAuth SAML binding, access secrets/tokens are less interesting. George believes they can be separated. A web service discovery protocol done over HTTP could leverage OAuth and then just extend it as necessary. Marc is interested in this for his and Hubert's RESTful ID-WSF work. Eve wonders if SAML assertions as official (if "alternate") OAuth tokens would be of interest in that community. It appears some people wouldn't have any need for it, and others might be okay with it, though it's hard to get a read. Eve asks about next steps. Possible homes: TEG (RESTful ID-WSF), Concordia (particularly three-legged scenario), SSTC (generic binding). Hubert will pick up the discussion in TEG, and George can participate in proposing a binding spec to SSTC, hoping to find others who are more experienced at writing these. AOL is already working with the OAuth community on a couple of extensions. Discussions are ongoing about taking OAuth to IETF. We don't have any problem sharing these notes or George's slides with SSTC to kick off some work and look for partners. -- Chief Architect AIM: gffletch Identity Services Work: george.fletcher@corp.aol.com AOL LLC Home: gffletch@aol.com Mobile: +1-703-462-3494 Office: +1-703-265-2544 Blog: http://practicalid.blogspot.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]