Francisco, While a proper profiling of subject confirmation is generally needed for a secure/interoperable SAML exchange, it's worth noting that assertions as used in OAuth (client assertions or URI/assertion grant types) are not necessarily SAML assertions. The term assertion is used more generally. To be honest, I think token might have been be a less confusing term to use in place of assertion in the framework spec. But token is widely used in other contexts thought out the framework spec too. So I dunno, maybe that would be even more confusing.
If you are interested/knowledgeable about SAML subject confirmation, please feel free to review and comment on the SAML Bearer Assertion Grant Type Profile: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-00 :) -Brian On Tue, Jan 18, 2011 at 1:26 PM, Francisco Corella <[email protected]>wrote: > Mike, > > As assertion use is described in the spec, a client assertion does not > provide any security whatsoever. How do you handle subject confirmation in > your implementation? (See section 2.4.1.1 of the SAML > specification<http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.) > In other words, how does the authorization server know that the client > sending the assertion is actually the subject of the assertion? > > Francisco > > --- On *Tue, 1/18/11, Mike Jones <[email protected]>* wrote: > > > From: Mike Jones <[email protected]> > Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and > OAuth2 HTTP Authentication Scheme > To: "Eran Hammer-Lahav" <[email protected]> > Cc: "[email protected]" <[email protected]> > Date: Tuesday, January 18, 2011, 5:35 PM > > > Having spoken to a number of people implementing the spec here, I’ve > encountered strong objections to removing Client Assertion Credentials and > the OAuth2 HTTP Authentication Scheme. It’s also not clear to me why we > would make substantial breaking changes to the specification when it is > essentially ready for approval. I’ve summarized the reasons I believe we > should keep these two features below. > > *Client Assertion Credentials:* Many of the scenarios we care about > require this capability. They were key motivators for the Assertion Profile > in WRAP (see § 5.2), have been part of OAuth 2 for quite a while, and we > have running code that requires this support. For example, the Azure Access > Control Service is a cloud Authorization server that supports several > protocols, including parts of OAuth 2.0 draft 10 (autonomous and web server > profiles). We are happy to update our implementation to subsequent drafts & > agree that the spec leaves a lot of ambiguity. > > In our implementation of the autonomous and web server profiles, ACS allows > clients to authenticate using a signed assertion as well as with a > username/password. The username/pwd option is for clients that don’t mind > sending credentials over the wire, while the signed assertion mechanism is > for clients that are more reticent to send raw credentials and for scenarios > where it isn’t possible. To illustrate an example where username/pwd isn’t > viable, consider the case of a client that needs to use an enterprise > identity to gain access to a cloud service. In many cases, corporate policy > demands that a client use an identity managed by the organization. This > means that the client should obtain an assertion from an enterprise identity > provider (Active Directory, Tivoli, etc.) and use that assertion to obtain > an access token which grants access to various web service APIs. Many of our > key MSFT customers and internal partner teams rely on this mechanism and > reverting exclusively to username/pwd isn’t an option for us. > > > > *'OAuth2' HTTP Authentication Scheme:* Simply put, dropping this seems > like a huge step away from interoperability. As one data point, Microsoft > implements this in our WIF OAuth2 protected resource code. All up, clients > need a way to authenticate to the protected resource. Also, existing WRAP > implementations need this functionality to migrate to OAuth2. For all > these reasons, we support retaining this functionality in OAuth2. > > > > Thanks, > > -- Mike > > > > -----Inline Attachment Follows----- > > _______________________________________________ > OAuth mailing list > [email protected] <http://mc/[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
