HTTP Authentication - WWW-Authenticate header - multiple realms

Does anyone have any experience of supporting multiple开发者_如何学Go realms in HTTP Authentication?

The Microsoft website states:

Each authenticate response header contains an available authentication scheme and a realm. If multiple authentication schemes are supported, the server returns multiple authenticate response headers. The realm value is case-sensitive and defines a protection space on the proxy or server. For example, the header "WWW-Authenticate: Basic Realm="example"" would be an example of a header returned when server authentication is required.

This suggests that different areas of a website can be secured using different authentication methods. What we are confused about is how to determine what realm should be stated in the server response to a client request.

Does anyone have any examples of how multiple realms work?

The HTTP specification allows for multiple WWW-Authenticate challenges to be present in a response, either within the same WWW-Authenticate header or using multiple WWW-Authenticate headers within the same response.

There are problems associated with this, as described in RFC 2617, section 4.6. In theory, the client must choose the strongest authentication mechanism available, however, defining which one is the strongest is not always obvious.

I've never tried with multiple realms (and the same scheme, for example Basic), but I'm not aware of anything disallowing it. The main problem with multiple realms and the same scheme is that the browser is likely to be confused in terms of user-interface, in particular which realm it challenges the user with.

I have one good example using multiple authenticate headers when using a sharepoint site. The Sharepoint offer both Negotiate and NTLM when connecting first.

Firefox chooses NTLM but Chrome chooses Negotiate.

It is also a consequence that Chrome will always send the Authorization header along with the other requests but Firefox only at the beginning because of the NTLM challange-response protocol. See here more explanation http://www.innovation.ch/personal/ronald/ntlm.html