[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PaceSecurityServices & Digest auth
I'd like to express support for specifying some authentication
method(s) for use with Atom, for interoperability--and also for the
Digest auth method. For our environment (Six Apart), it's preferable to
WSSE-style because in generic hosting environments, we don't want to
store the password in cleartext. For that reason, I don't think
WSSE-style auth should be required for Atom servers (I say +1 to the
current wording, "MUST support either... SHOULD support both").
I see three issues to be addressed with Digest:
(1) Some web-servers remove the WWW-Authenticate header before
passing it to a CGI program.
(2) We need an equivalent method for use within a SOAP message.
(3) The default HTTP Digest auth algorithm is based on MD5, and
requires the server to be able to form an MD5 hash based on the triple
(username, realm, password). If you don't store either the cleartext
password or that specific hash, you're out of luck.
To address (1), I propose this addition to the end of section K,kk. in
An Atom client MAY authenticate itself to an Atom server by sending an
X-Atom-Authenticate HTTP header, in the same form as for the
WWW-Authenticate header [RFC2617]. If an Atom client sends a
WWW-Authenticate header, it SHOULD have the same value as the
This is in line with some of the mechanisms that have been suggested,
for example in Joe Gregorio's post .
As to (2), I suggest that we simply tunnel the header fields of HTTP
Digest Auth within XML elements (the same way we've done with WSSE).
Using WSSE UsernameToken is attractive, except for requiring the server
to store the password in the clear. I'll be interested what others
think about this.
To address the third issue, I'd like to propose some alternative
"algorithms" (in the sense of RFC 2617) for Digest auth. In particular
I'd like to offer new functions to take the role of the H and KD
functions used in RFC 2617, sections 188.8.131.52 and 184.108.40.206. I'm happy to
propose these in a separate RFC, or help work them into the Atom spec.
I do believe that they would have usefulness outside of Atom, and yet
my immediate goal is to achieve interoperable Atom implementations.