OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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.


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 

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 

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

TEG 2008-09-18.odp

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]