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
