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

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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