[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [saml-dev] RE: How to provide SAML assertions in RESTful services
John and everyone, Perhaps I'm guilty of holding a hammer and seeing only nails but I've been working with/on OAuth 2 lately and I think portions of it may fit this use case. Initially it's likely more appropriate for the interoperability aspect rather than the security aspect but, as Scott points out, your security in this case is primary from the use of mutually authenticated TLS. In OAuth 2 there is an assertion access grant type [1] which is a means for what they call an autonomous client [2] to obtain an access token [3] by presenting an arbitrary assertion or token. That access token can then be used in remote API calls to the resource server (the service provider in your use case is what OAuth would call a resource server [3]). If I understand you use-case correctly, it would work something like this: a) The client (or smart system as you called it at one point) presents a SAML assertion on behalf of the user to an authorization server (another oauth term [3]). The user may be present and authenticated at the client or the client may be acting on its own on behalf of the user. b) The authorization server validates the assertion and returns an oauth access token. c) The access token is then passed in the RESTful API calls in a standardized way[4]. The access token is opaque to the client but can contain (directly or via reference) whatever information the service provider needs about the user. If this sounds like it might fit, I'd be happy to explore it in more detail. In the meantime, there's actually a wiki page[5] that describes some of the background of the scenario. Some of it is a little out of date now, I think, but the sequence diagram in section 2 and general description are useful in understanding this. A couple caveats: -OAuth 2.0 is still in draft not yet stable. -The assertion access grant request suggests the possible use of SAML but was intentionally left open ended as an extension point in the core OAuth spec. I'm currently working on an internet draft titled, "SAML 2.0 Bearer Assertion Profile for OAuth 2.0" that is intended to provide a tight and interoperable instantiation of the assertion access grant. I hope to have an initial draft of that available soon. The way the client obtains the assertion is not defined but there are a number of ways to accomplish that and it sounds like you've already got that part solved anyway. Okay Scott, have at it... [1] "4.1.3. Assertion" http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-4.1.3 [2] "1.4.4. Autonomous [Client Profile]" http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-1.4.4 [3] "1.2. Terminology" http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-1.2 [4] "5. Accessing a Protected Resource" http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-5 [6] "2 Exchanging a SAML Assertion for an OAuth Token" http://iiw.idcommons.net/SAML_Profiles_for_OAuth#Exchanging_a_SAML_Assertion_for_an_OAuth_Token On Sat, Jun 26, 2010 at 1:13 PM, Scott Cantor <cantor.2@osu.edu> wrote: >> I think you are being overly pessimistic. The scope of what I am doing >> right now is defining the interoperability mechanisms. The operational >> choices are above and beyond what we define in the interop profile. >> Specifically with SOAP and WS-Security the capabilities of WS-Security >> are available to be used. > > I don't see how, apart from perhaps some encryption or signing to duplicate > what the TLS layer is doing. What you described is a case in which there is > no security from the WS-Security layer, only data about the user identity. > The security model is of trusted endpoints communicating over a secure > channel and asserting without proof who they are acting on behalf of. That > doesn't involve any WSS features. > > This is not a criticism, it's a description. If that's the use case, then > that's the use case. There's nothing wrong with that. > >> I would hope that this is a >> useful profiling. These choices are primarily due to the sensitive >> nature of healthcare, and the extremely distributed organizational >> arrangements. > > That's fine. But it is not something that seems to demand WS-Security to any > obvious extent, and I don't really see where OAuth fits either. Mainly > because you're avoiding the requirement to involve the *user* in the > security flow between the federated systems. That's a greatly simplifying > assumption, and it's not really that uncommon either. > >> Does this give you more room to express security concerns? > > I really have no concerns. I think your security here is very traditional, > and very easy to understand. > > What I was saying was that your use case is not one that lends itself to > some kind of comparison of SOAP vs REST security, because neither is > involved. It's TLS. > > -- Scott > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: saml-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: saml-dev-help@lists.oasis-open.org > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]