On Wed, Aug 4, 2010 at 9:08 AM, Prateek Mishra <prateek.mis...@oracle.com> 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?).
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. > 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. 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 :) _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
