Remko Tronçon schrieb:
I would guess that it's to avoid the case where a server
implementation always rejects any request for an authzid.
Well, I have this problem with an XMPP server, but in XMPP, the
authzid for a user is different from its authid, so the check doesn't
help. Luckily, an authzid in XMPP can never be used as an authid, so
we don't have a problem with the equality check.
But it matters on the server-side of an XMPP implementation.
In the DIGEST-MD5 server implementation does set the authorization id to
the authentication id, if no or an empty authorization id has been sent
by the client. This does not match what is needed by XMPP.
Let me show an example:
User sends: authid=mawis, realm=example.com, no authzid
With XMPP this means: client wants to authorize as "mawis@xxxxxxxxxxx"
But Cyrus passes to the application: client wants to authorize as "mawis"
The problem here is that in XMPP "mawis" is a valid (but different!)
authorization id as well.
So in the context of XMPP the following two things are different:
authid=example.com, realm=example.com, no authzid
authid=example.com, realm=example.com, authzid=example.com
... but Cyrus passes the same authzid to the application for both cases.
Cyrus SASL really seems to be broken here, as RFC 4422, section 3.4.1
states that for an absent or empty authorization identity string the
authorization id is the one, that the server associates with the
client's credentials. This isn't something a SASL library can do by just
copying the authentication id.
Tot kijk
Matthias
--
Matthias Wimmer Fon +49-700 77 00 77 70
Züricher Str. 243 Fax +49-89 95 89 91 56
81476 München http://ma.tthias.eu/
