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
