SAML assertions routinely run into the 10s and even 100s of K. This exceeds the practical limit that most HTTP servers and proxies put on the size of the HTTP request headers they are willing to accept. So we cannot rely on the HTTP authorization header as a means of transporting SAML assertions. We are thus, as a practical matter, forced into using the request body.
From: Manger, James H [mailto:james.h.man...@team.telstra.com] Sent: Monday, June 28, 2010 9:38 PM To: Yaron Goland; oauth@ietf.org Subject: RE: Proposal for text for section 2 Yaron, "Assertion Client Credentials" is too much of a hack. It only works for POSTs, and only when the body is form-encoded. It could not be used, for instance, to delete a token with an HTTP DELETE request to a token URI. Though that specific idea has not been accepted yet, it is a reasonable possibility. We shouldn't introduce a client authentication mechanisms incapable of working with such ideas. The 1st and 2nd proposed paragraphs are not specific to OAuth at all. The 3rd paragraph mentions authorization codes and refresh tokens, but the client assertion is independent of those. I would prefer to see a standalone description of how to authenticate any HTTP request with a client SAML assertion - then that could apply to the OAuth2 token management API, just as easily as it applies to any other API, and just as easily as any client auth mechanism works with OAuth2. For instance, why not define a SAML HTTP authentication mechanism: Authorization: SAML a=<base64url-encoded SAML assertion> It is obvious how it can be used to authenticate/authorize client requests to an OAuth2 token endpoint. It works with GET, HEAD, POST, PUT, DELETE.... It works with XML, JSON, form-encoded... messages. You don't need special rules about avoiding duplicate authentication mechanisms. There is a standard way to do discovery: return WWW-Authenticate: SAML realm="Token Management". Finally, the proposal keeps client_id as a separate parameter. However, I guess that a SAML assertion would often include a client id inside the assertion. This means we have two client ids. At best it is slightly inefficient; it introduces more code paths (eg if they mismatch); at worst it causes security bugs when the "wrong" client id is used at different points in systems. -- James Manger From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Yaron Goland Sent: Tuesday, 29 June 2010 7:56 AM To: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Proposal for text for section 2 The following is proposed language for a new section, 2.2, in the spec. This is part of the spec that deals with client authentication. This proposal is completely orthogonal to anything in section 4 such as grant types. At Eran's suggestion I added in an example into the text to help readers understand both what the feature is for and how it is used. Eran also suggested that we should probably introduce a client_cred_type parameter (since we are explicitly support multiple types of client parameters) just to be consistent with grant_type. I don't have strong feelings on the subject and am happy to go with whatever the group wants. Thoughts? Thanks, Yaron 2.2 Assertion Client Credentials In scenarios where security is at a premium one wants to avoid sending secrets across the Internet, even on encrypted connections. Instead one wants to send values derived from the secret that prove to the receiver that the sender is in possession of the secret without actually sending the secret. Typically the way derived values are created is by generating an assertion that is then either HMAC'd or digitally signed using an agreed upon secret. By validating the HMAC or digital signature on the assertion the receiver of the assertion can prove to themselves that the entity that generated the assertion was in possession of the secret without actually communicating the secret directly. So, for example, a client can establish a secret using an out of band mechanism with a resource server. As part of this out of band communication the client and resource server agree that the client will authenticate itself using a SAML assertion with agreed upon parameters that will be signed by the provisioned secret. Later on the client interacts with an end-user and uses the end-user authorization process with the resource server to get an authorization code. The client then sends an access token request to the token endpoint for the resource server and includes, along with the authorization code, a SAML assertion it signed with the previously agreed key and parameters. The SAML assertion proves to the token endpoint the identity of the client and the authorization code provides the link to the end-user authorization. If the access token request comes back with a refresh token then in the future the client can get new access tokens by submitting an access token request containing both a properly signed and formatted SAML assertion as well as the refresh token. The following defines how to send an assertion as client credentials. If the assertion client credentials are used then the client MUST include the credentials using the following request parameters: client_id REQUIRED. The client identifier. client_assertion_type REQUIRED. The format of the assertion as defined by the authorization server. The value MUST be an absolute URI. client_assertion REQUIRED. The client assertion. For example (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&client_id=s6BhdRkqt3& client_assertion=PHNhbWxwOl...[omitted for brevity]...ZT4%3D& client_assertion_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& refresh_token=n4E90119d The client MUST NOT include the client credentials using more than one mechanism. If more than one mechanism is used regardless whether the credentials are identical or valid, the server MUST reply with an HTTP 400 status code (Bad Request) and include the "multiple_credentials" error code. Token endpoints can differentiate between client assertion credentials and other client credential types by looking for the presence of the client_assertion and client_assertion_type attributes which will only be present with client assertion credentials.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
