|
I still feel that having two parallel groups of authentication mechanisms — one group for “direct” credentials, one group for “delegated” credential — is
a very poor architectural choice. If it is required, I suggest the schemes for delegated credentials should add “Delegate-“ to the direct scheme name and otherwise be identical. So a request
signing spec would specify, say, a direct “MAC” scheme. Another spec would define the “Delegate-“ prefix that can apply to any scheme. Then we could use: Authorization: BASIC adghashjdgasdj — for users with browsers Authorization: Delegate-BASIC adghashjdgasdj — for clients with delegation token/secrets over HTTPS Authorization: Delegate-MAC …signature=”dfjghfa” — for clients with delegation token/secrets over HTTP Authorization: MAC …signature=”dfjghfa” — for clients with app credentials (eg 2-legged) over HTTP Authorization: Delegate-Id <token> — for clients acting as a delegate over a separately-authenticated channel (HTTPS with client & server auth; VPN…) > Both will use the same method(s) Does this means the “Delegated” and “Direct” schemes
are supposed to include PLAIN and HMAC (and RSA?) methods (eg “Delegated PLAIN” (like the “TOKEN PLAIN” idea)? If so, yuck! Burying the actual mechanism (PLAIN/HMAC/…) a layer down will not work well with existing libraries where one part chooses a mechanism
based solely on the scheme. I also don’t think it matches the allowed syntax for the WWW-Authenticate header: everything after the scheme has to be in name=value syntax. [RFC 2617, §1.2] challenge = auth-scheme 1*SP 1#auth-param auth-scheme = token auth-param = token "=" ( token | quoted-string ) [Aside: regardless of prefix, stick with “BASIC base64(utf8(token) ‘:’ utf8(secret))” syntax instead of “Plain <token> <secret>”. The only restriction the
former imposes is that a token cannot include a colon. The latter implies all sort of restrictions on token and secret: only ASCII, no commas, no newlines, no space, quotes (nor sure), other punctuation (not sure). It is far from clear what exactly the restrictions
are as I believe the HTTP header parsing rules are quite messy — avoid this issue (and the whole debate) by sticking with the BASIC syntax.] I did a few tests to see how Java (Sun’s v6) handled multiple WWW-Auth headers in a response. I had hoped it would pass each to the configured java.net.Authenticator
until some non-null credentials were found. It does not do this. It picks one header based on a (configurable) prioritized list of schemes (by default Negotiate, Kerberos, Digest, NTLM, then BASIC). If a scheme appears multiple times it picks the last occurrence
(in contrast to browsers that pick the first). I believe (Apache) HttpClient does a similar thing: new authentication mechanisms can be added, but only the scheme is consulted when choosing them. This means returning multiple “WWW-Auth.: BASIC …” headers with different realms (one for users, one for apps with delegation tokens) would be more awkward
than I hoped. I will not pursue that idea. It also means “Token <sub-scheme>”, “Delegated <sub-scheme>” or “Direct <sub-scheme>” will not work well with existing code bases. Existing Java HTTP internals
could pick the last “Delegated ” header, but could not be configured to pick, say, HMAC over PLAIN, or RSA over HMAC. Perhaps we need some clarification over the problem the Delegated/Direct/Token idea is addressing. Eran’s original statement was: > “It is important to make sure a server can reply to a protected resource request with more than one auth header to indicate that both usernames and tokens
are welcomed.” Eran, are you most concerned about allowing users with browsers and apps with delegated credentials to access the same URIs? Or is it apps with their own
(direct) credentials and with delegated credentials needing to choose between these? Supporting either (or both) would be nice, but I am not yet convinced that this problem is that critical (ie worth a architectural compromise). Few sites use BASIC for users — it just doesn’t offer enough flexibility in the user interface (forgotten password links etc). Few sites use the same URIs for users and apps — many seem to have a
www.example.net and api.example.net split, for instance. Users typically want HTML; apps typically want JSON or XML…. The extremely common FORM-based user auth does not play well with any WWW-Auth header as it is never(?) delivered with a 401 error code. Finally, we have concentrated on WWW-Auth-based discovery for the authentication part, ignoring the delegation flow part for now. It seems quite reasonable/sensible/likely/possible
that the delegation flow should indicate which protected resources the delegation can be used at. In which case, the delegation credentials can be sent proactively when requesting those resources, without any need for a WWW-Auth header (making the Delegate-specific
WWW-Auth schemes unnecessary). James Manger
|
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.