Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft

From: Anthony Nadalin <[email-masked]>
Date: Mon, 2 Aug 2010 21:20:54 +0000

There are many cases where we need to have more than 1 SAML assertion be used to represent the authorization token, so would want a provision for multiple SAML tokens and not sure it makes sense to have a separate profile for that or add it as an option here.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Thursday, July 15, 2010 1:50 PM
To: oauth
Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft

I'm gong to join the growing list of people attaching a potential I-D to an email due to he cut off time for the I-D submissions.  Attached is a draft that aims to tightly define the particular format of a SAML
2.0 bearer assertion in requesting an access token using the assertion
grant_type.   I've been working with Chuck at Salesforce.com on this
and the primary goal is to have some documentation or specification that is sufficient to facilitate interoperability between
independently developed implementations or products.    This, of
course, wouldn't preclude using SAML in other ways - it would only provide one concrete definition to implement against.

I intend to submit this as an I-D when the submission process reopens.
  Any feedback from this group would be appreciated as well as thoughts about this eventually becoming a working group draft.

Thanks,
Brian Campbell

---

From: Brian Campbell <[email-masked]>
Date: Mon, 2 Aug 2010 15:53:23 -0600

I guess I'd need to understand the scenario better before I'd have an
opinion one way or the other.   However, I will say that In this
profile I was specifically looking to avoid the complexity that exists
in SAML Web SSO by allowing for multiple assertions and multiple
subject confirmations.

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 2 Aug 2010 22:26:15 +0000

So the scenario we have is where there are multiple tokens from attribute and identity providers need to be delivered to an OAuth authorization server to satisfy the resource owner's policy of required claims. So this is a case where a single SAML token/assertion is not enough to satisfy the claim, we still expect that the signature verification is out of scope.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Monday, August 02, 2010 2:53 PM
To: oauth
Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft

I guess I'd need to understand the scenario better before I'd have an
opinion one way or the other.   However, I will say that In this
profile I was specifically looking to avoid the complexity that exists in SAML Web SSO by allowing for multiple assertions and multiple subject confirmations.

On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin <[email-masked]> wrote:
> I'm gong to join the growing list of people attaching a potential I-D 
> to an email due to he cut off time for the I-D submissions.  Attached 
> is a draft that aims to tightly define the particular format of a SAML
> and the primary goal is to have some documentation or specification 
> that is sufficient to facilitate interoperability between 
> independently developed implementations or products.    This, of course, wouldn't preclude using SAML in other ways - it would only provide one concrete definition to implement against.
>
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Tue, 3 Aug 2010 14:11:42 -0600

Seems like a much more complicated scenario.  Allowing more than one
assertion, off the top of my head, would necessitate some major
changes to this profile:

* Define how multiple assertions are encoded into the single
"assertion" form control (samlp:Response, concatenated, something
else?)
* Deal with subject equality across the assertions
* Define the processing rules for multiple assertion (from different
issuers) and the expected behavior when some but not all are valid.

That seems like it would add significant complexity to the existing
draft (that I'm trying to keep simple) for a particular scenario that
I'm not sure is very common.  But maybe I'm wrong.  Is this something
that others anticipate needing?   If so, does it belong here?

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 3 Aug 2010 22:29:12 +0000

This is a use case we are seeing from the various government agencies (UK, USA, BC), I agree it add complexity but with having to satisfy several claims (i.e. over 21 and being a resident of sate) this seems to be pretty common these days.

-----Original Message-----
From: Brian Campbell [mailto:[email-masked]] 
Sent: Tuesday, August 03, 2010 1:12 PM
To: Anthony Nadalin
Cc: oauth
Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft

Seems like a much more complicated scenario.  Allowing more than one assertion, off the top of my head, would necessitate some major changes to this profile:

* Define how multiple assertions are encoded into the single "assertion" form control (samlp:Response, concatenated, something
else?)
* Deal with subject equality across the assertions
* Define the processing rules for multiple assertion (from different
issuers) and the expected behavior when some but not all are valid.

That seems like it would add significant complexity to the existing draft (that I'm trying to keep simple) for a particular scenario that I'm not sure is very common.  But maybe I'm wrong.  Is this something
that others anticipate needing?   If so, does it belong here?

On Mon, Aug 2, 2010 at 4:26 PM, Anthony Nadalin <[email-masked]> wrote:
>> 2.0 bearer assertion in requesting an access token using the 
>> assertion grant_type.   I've been working with Chuck at 
>> Salesforce.com on this and the primary goal is to have some 
>> documentation or specification that is sufficient to facilitate 
>> interoperability between independently developed implementations or products.    This, of course, wouldn't preclude using SAML in other ways - it would only provide one concrete definition to implement against.
>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 3 Aug 2010 22:21:47 -0700

The single assertion use case is well defined. If you need to support multiple assertions in a single request, you will need to define a way to group them together and include them using the single assertion parameter or define an extension for additional assertions. Either way, this sounds like something that belongs in its own spec.

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Anthony Nadalin
> Sent: Tuesday, August 03, 2010 3:29 PM
> To: Brian Campbell
> Cc: oauth
> This is a use case we are seeing from the various government agencies (UK,
> USA, BC), I agree it add complexity but with having to satisfy several claims
> (i.e. over 21 and being a resident of sate) this seems to be pretty common
> these days.
> 
> assertion, off the top of my head, would necessitate some major changes to
> this profile:
> 
> * Define how multiple assertions are encoded into the single "assertion"
> form control (samlp:Response, concatenated, something
> else?)
> That seems like it would add significant complexity to the existing draft (that
> I'm trying to keep simple) for a particular scenario that I'm not sure is very
> common.  But maybe I'm wrong.  Is this something
> > So the scenario we have is where there are multiple tokens from attribute
> and identity providers need to be delivered to an OAuth authorization server
> to satisfy the resource owner's policy of required claims. So this is a case
> where a single SAML token/assertion is not enough to satisfy the claim, we
> still expect that the signature verification is out of scope.
> >
> > profile I was specifically looking to avoid the complexity that exists in SAML
> Web SSO by allowing for multiple assertions and multiple subject
> confirmations.
> >
> >> There are many cases where we need to have more than 1 SAML
> assertion be used to represent the authorization token, so would want a
> provision for multiple SAML tokens and not sure it makes sense to have a
> separate profile for that or add it as an option here.
> >>
> >> interoperability between independently developed implementations or
> products.    This, of course, wouldn't preclude using SAML in other ways - it
> would only provide one concrete definition to implement against.
> >>
> >>  Any feedback from this group would be appreciated as well as thoughts
> about this eventually becoming a working group draft.
> >>
> >> Thanks,
> >> Brian Campbell
> >>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 4 Aug 2010 10:54:34 +0200

+1

Brian's profile serves a distinct purpose. I don't see a problem with different assertion profiles for using SAML with OAuth, especcially given the wide usage of SAML.

Regards,
Torsten.

Am 04.08.2010 um 07:21 schrieb Eran Hammer-Lahav <[email-masked]>:

>>> Of Brian Campbell

---

From: Prateek Mishra <[email-masked]>
Date: Wed, 04 Aug 2010 11:08:32 -0400

Brian,

it would probably help to clarify that you are proposing this as a 
additional or follow-on step to SSO implemented via the SAML web browser 
profiles (right?).

Maybe some text could be added to the draft to make that explicit. This 
is in contrast to more general token exchange scenarios - here
are bunch of SAML /XYZ tokens, now give me an OAuth token for for a 
certain purpose. I agree with you that the latter would require quite a 
bit of additional work.

Here is my understanding of the current use-case -

The user delivers a SAML bearer token (issued at an IdP) via a browser 
profile to an SP. The SP, performs some business service for the user 
and at some point
requires access to user resources at the IdP or at some third-party 
site. Switching to OAuth terminology, the Client (SP) exchanges the said 
SAML bearer token to the Authorization server (could be at the IdP - 
this would be a common case I think) for an OAuth token. This is the 
exchange you are describing in your draft.

Once the client obtains the OAuth token, it can bind it to a request for 
the user resource.

I have some mild SAMology concerns about this - historically the SAML 
bearer token has been constrained to have a short life-time and the 
general advice is not to forward it beyond the SP. I am aware that in 
practice this isnt the case - often the token is bound to some 
subsequent flows - somewhat along the lines you are proposing. I will 
follow up with these concerns on the SAML list.

- prateek

---

From: Paul Madsen <[email-masked]>
Date: Wed, 04 Aug 2010 11:14:15 -0400

Prateek, I believe that here it is the SAML IdP that acts as OAuth 
Client, not SAML SP - the point of the flow is to get the Assertion 
(that the IDP would normally send through the browser) over to the SP 
through an OAuth request/response exchange (in order to get an OAuth token)

paul

On 04/08/2010 11:08 AM, Prateek Mishra wrote:
> additional or follow-on step to SSO implemented via the SAML web 
> browser profiles (right?).
>
> Maybe some text could be added to the draft to make that explicit. 
> This is in contrast to more general token exchange scenarios - here
> certain purpose. I agree with you that the latter would require quite 
> a bit of additional work.
>
> site. Switching to OAuth terminology, the Client (SP) exchanges the 
> said SAML bearer token to the Authorization server (could be at the 
> IdP - this would be a common case I think) for an OAuth token. This is 
> the exchange you are describing in your draft.
>
> Once the client obtains the OAuth token, it can bind it to a request 
> for the user resource.
>
>>> So the scenario we have is where there are multiple tokens from 
>>> attribute and identity providers need to be delivered to an OAuth 
>>> authorization server to satisfy the resource owner's policy of 
>>> required claims. So this is a case where a single SAML 
>>> token/assertion is not enough to satisfy the claim, we still expect 
>>> that the signature verification is out of scope.
>>>
>>> profile I was specifically looking to avoid the complexity that 
>>> exists in SAML Web SSO by allowing for multiple assertions and 
>>> multiple subject confirmations.
>>>
>>>> assertion be used to represent the authorization token, so would 
>>>> want a provision for multiple SAML tokens and not sure it makes 
>>>> sense to have a separate profile for that or add it as an option here.
>>>>
>>>> course, wouldn't preclude using SAML in other ways - it would only 
>>>> provide one concrete definition to implement against.
>>>>
>>>>  Any feedback from this group would be appreciated as well as 
>>>> thoughts about this eventually becoming a working group draft.
>>>>
>>>> Thanks,
>>>> Brian Campbell
>>>>

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 4 Aug 2010 08:43:52 -0700

Hi Prateek

The use-case we were going for here is really more like a classic 2-legged oauth scenario.    A company has an existing SAML web federation established with a service provider which is providing SSO to it's users.    They now want to perform API based integration with the service provider to perform some data integration on-behalf of the user, for instance sync their calendar.   This function needs to execute as that user account, and the company does not wish to establish or use passwords at the service provider.   They have 10000 users, and do not wish for each of them to go through a classic 3 legged delegation flow; there are too many users to coordinate and 1 single trust decision by a privileged admin will suffice.    So - the company / service provider decide to reuse their existing SAML configuration for API federation.  (note that nothing about the profile dictates you need to have web sso in place, nor reuse the metadata exchange...just and example )   

The company acts as both the IDP and OAuth2 client.   Their integration client obtains the assertion and posts it to the token endpoint.   The token endpoint generates an access token for the subject of the SAML assertion and the integration client can now execute as that user.   The assertion is discarded.

So - this is intended to be very much like web sso and use short lived bearer assertions that are exchanged for API sessions.

Hope that helps clarify.

-cmort

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Prateek Mishra [[email-masked]]
Sent: Wednesday, August 04, 2010 8:08 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft

Brian,

- prateek

---

From: Brian Campbell <[email-masked]>
Date: Wed, 4 Aug 2010 09:44:54 -0600

> additional or follow-on step to SSO implemented via the SAML web browser

Actually no.

The similarities to SSO are mostly in the assertion format and general
processing rules.  And I did that in hopes of leveraging the thinking
that went into that as well as hopefully facilitating some reuse of
concepts, patterns and maybe even code/infrastructure.

> Maybe some text could be added to the draft to make that explicit. This is
> in contrast to more general token exchange scenarios - here
> are bunch of SAML /XYZ tokens, now give me an OAuth token for for a certain
> purpose. I agree with you that the latter would require quite a bit of
> additional work.

This is indented to be a general token exchange.  Where the inbound
token is a SAML token with bearer semantics and the outbound token is
an OAuth access token.

I'd constrained the inbound token to be a single SAML assertion and I
believe Anthony was asking if it would be possible/reasonable to relax
that constraint and allow for multiple SAML tokens inbound.  I was
initially pretty against the idea but I'm thinking maybe it could be
accommodated without introducing as much complexity as I first
thought.   More on that later in a different email.

> profile to an SP. The SP, performs some business service for the user and at
> some point
> requires access to user resources at the IdP or at some third-party site.
> Switching to OAuth terminology, the Client (SP) exchanges the said SAML
> bearer token to the Authorization server (could be at the IdP - this would
> be a common case I think) for an OAuth token. This is the exchange you are
> describing in your draft.

That's a very different exchange than what I'm describing.   Paul
describes this use case well in a follow up email to this thread: "I
believe that here it is the SAML IdP that acts as OAuth Client, not
SAML SP - the point of the flow is to get the Assertion (that the IDP
would normally send through the browser) over to the SP through an
OAuth request/response exchange (in order to get an OAuth token)."
Exactly *how* that client gets the assertion in the first place is
undefined but likely involves some kind of STS style exchange between
the client (at the IdP) and whatever SAML infrastructure the IdP has
in place.  Though, of course, it's not limited to that - I just
envision that as a common pattern.

For the case you are describing, if the restriction on a single
SubjectConfirmation were relaxed, this flow could perhaps be used in
the case where the Web SSO assertion is used by the SP to request an
access token from a 3rd party (the assertion would need at least two
SubjectConfirmations - one targeted for the SP via web SSO and one
targted for the authz server at the 3rd party.    Relaxing the single
SubjectConfirmation constraint was something that Scott suggested on
the SAML SSTC list and another item I'm considering - I'll follow up
with a separate thread about that as well.

In the case of wanting to make some service call back to the IdP after
SSO there is some thinking/work being done that would simplify things
by embedding the access token or authorization code in the SSO
assertion (likely as a specifically named attribute).

> I have some mild SAMology concerns about this - historically the SAML bearer
> token has been constrained to have a short life-time and the general advice
> is not to forward it beyond the SP. I am aware that in practice this isnt
> the case - often the token is bound to some subsequent flows - somewhat
> along the lines you are proposing. I will follow up with these concerns on
> the SAML list.

By all means, raise any concerns you have here or with the SSTC or
both.   But let's make sure we are talking about the same things first
:)

---

From: Brian Campbell <[email-masked]>
Date: Wed, 4 Aug 2010 09:48:28 -0600

Good explanation, thanks Chuck.

---

From: Prateek Mishra <[email-masked]>
Date: Wed, 04 Aug 2010 17:00:44 -0400

Thanks for the clarification (Paul, Chuck and Brian), re-reading the 
most recent draft makes the use-case pretty clear, not sure how I came 
up with my own personal use-case in this instance (not enough coffee 
probably...)

To me it seems that this is an instance of a SAML --> OAuth token 
mapping service, which seems a pretty useful service. One question is 
whether there needs to be a general framework for its use; I guess this 
was the substance of interaction between Brian and Tony earlier in the 
thread. I guess I need to research the issue some more before joining 
that discussion.

Here is a simpler question: is there a requirement that the Client/IdP 
authenticate to the Authorization server when presenting the SAML bearer 
token? I didnt see it in the current draft - or is that taken care of in 
the base OAuth 2.0 protocol?

- prateek

---

From: Brian Campbell <[email-masked]>
Date: Thu, 5 Aug 2010 07:22:17 -0600

On Wed, Aug 4, 2010 at 3:00 PM, Prateek Mishra
<[email-masked]> wrote:
> Thanks for the clarification (Paul, Chuck and Brian), re-reading the most
> recent draft makes the use-case pretty clear, not sure how I came up with my
> own personal use-case in this instance (not enough coffee probably...)

If you think there's anything that could be added or removed to make
it more clear, please let me know and I'll try and incorporate it.

> To me it seems that this is an instance of a SAML --> OAuth token mapping
> service, which seems a pretty useful service. One question is whether there
> needs to be a general framework for its use; I guess this was the substance
> of interaction between Brian and Tony earlier in the thread. I guess I need
> to research the issue some more before joining that discussion.

I'm not sure there was that much substance to Tony and I's interaction
- we were just discussing the merits of allowing for more than one
assertion in this profile.  I guess that does generalize it somewhat
but I don't know that it makes it a 'general framework its use.'
Honestly, I'm not even sure what that would involve.  To some extent,
the assertion grant type in OAuth is the general framework for
exchanging a token/assertion for a OAuth access token.   And, as you
point out, this profile is an instance of that that does SAML -->
OAuth.  Do you think there needs to be something more generalized
somewhere?

> token? I didnt see it in the current draft - or is that taken care of in the
> base OAuth 2.0 protocol?

Client authentication is in the core OAuth spec but it is optional.
So I'd imagine it will end up as a policy decision at deployment time.

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 10 Aug 2010 15:48:08 -0400

Strongly agree.

Igor

Eran Hammer-Lahav wrote:
>>> On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin
>>>       
>> <[email-masked]> wrote:
>>