What would be ideal is a standardized authentication mechanism that supports federation. The obvious candidate is HTTP Digest Authentication (the specification isn't the easiest read, I have to admit, so you might find the wikipedia entry more understandable). Granted, it doesn't have a pretty logo. But it is supported by every user agent that I know of that is HTTP-aware. What isn't clear, however, is if it can be federated to permit user agents to employ a separate Identity Provider, reducing the need for multiple online identities.
This is an itch that I have been scratching in my mind for a while and I brought it up in conversation with Steve Bjorg yesterday. This gives me a reason/excuse to post where my thoughts are on the subject right now. Please note that these thoughts may well change and I do not consider myself a security expert.
The following diagram outlines the sequence diagram that I have in mind. Important: There is a precondition that the Server already has knowledge of the location of the Identity Provider for the user. This would probably be achieved manually in the same way that OpenID does, including an 'allow access' screen.
This is what the HTTP messages might look like:
The Client makes an ordinary GET request to a resource that happens to be protected.
The Client crafts an Authorization header by hashing the user credentials with the parameters of the WWW-Authenticate header in the normal fashion and resends the original request.
Here is the cunning part. The Authorization header contains enough information that a hash comparison can be carried out by anyone who has the correct credentials at hand. It doesn't have to be the Server. Therefore, the Server passes the Authorization header to a previously stored Identity Provider URI for validation (in this case, on http://example.org).
The Identity Provider retrieves the password of the user and performs the hash comparison. If validation fails, a 401 Unauthorized is returned to the Server. If it succeeds, a 200 OK is returned.
The user is now authenticated. The Server can check permissions and respond with the representation requested, if permitted. A 403 Forbidden would be sent if the authenticated user is not permitted.
There are some optimizations that could be employed. The Identity Provider could issue validation for a given period by setting the Expires header on the validation response, indicating that the Server can cache the authentication for a period. Similarly, the other conditional HTTP headers could be employed for more complex caching.
The communication between Client and Server and between Server and Identity Provider does not need to be encrypted because the credentials are always hashed on the wire, mitigating a man-in-the-middle attack.
The Client does not need to know anything about the Identity Provider. So far as the Client is concerned, this is a perfectly ordinary HTTP Digest Authentication mechanism which gives two benefits:
- There is no need for a complex set of Client HTTP requests to achieve authentication.
- The REST Layered System constraint is not violated.
I am interested to hear feedback from my audience if this is an authentication model that would be useful. As I said at the top, I am not a security expert so there may be flaws in my thinking.