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

[Paul Madsen <[e-mail]>]

  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:
> 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
>> 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 
>> <[e-mail]> wrote:
>>> 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: [e-mail] [mailto:[e-mail]] 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 
>>> <[e-mail]> wrote:
>>>> 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: [e-mail] [mailto:[e-mail]] 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
>>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>