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
Good explanation, thanks Chuck.
On Wed, Aug 4, 2010 at 9:43 AM, Chuck Mortimore
<cmortim...@salesforce.com> wrote:
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: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Prateek
Mishra [prateek.mis...@oracle.com]
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,
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 <tony...@microsoft.com> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 <tony...@microsoft.com> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
