-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've been looking at the way that SASL realms are implemented in
jabberd2 - in part, because of bug #17.
The SASL 'realm' isn't part of the published specification, but is a
server side feature to allow the seperation of user databases between
multiple services. In the Cyrus implementation, it's only supported
by certain authentication mechanisms - but used throughout the code.
In particular, any 'bare' authentication identifiers (those without
an '@') which pass through the SASL layer will have the current realm
appended to them. This applies to both the authentication and
authorization identifiers.
With jabberd2, the realm defaults to being the same as the id of the
c2s host. I believe that this is the only configuration in which the
current SASL code will work correctly. When the realm is changed to
something else, it changes what the SASL layer appends to
authorization IDs. The c2s code expects the authorization ID returned
by the SASL layer to be a valid JID, and so won't allow a connection
where the domain doesn't match the ID of the server (which is what
forces realm == domain in order for things to work). However - when
we start doing s2s SASL, this model breaks. With s2s, the
authorization ID isn't a JID, but just the domain name of the
connecting server. So, the SASL layer can't always return a JID
format authorization identifier (or, in the case of GSASL, construct
one).
I'd like to propose an interface change/clarification to what the
SASL layer returns to callers. There are a few points at which this
is required:
In calls to the registered sx SASL callback (_c2s_sx_sasl_callback
and friends) :
*) cb_GET_REALM should return the configured SASL realm (_not_ the
domain of the server)
*) cb_GET_PASS, cb_CHECK_PASS
The creds structure should be populated as follows:
creds.authnid should be a bare authentication identity
(without the realm appended)
creds.realm should be the configured SASL realm
*) cb_CHECK_AUTHZID
creds structure as above, but with the addition that:
creds.authzid should be the authorization identity as provided
by the client. Where the authorization identity is derived from the
authentication identity, this may be a bare name (no @domain)
In the sx stream structure
.auth_id should be the authorization identity as provided by the
client (or derived from the authentication identity). It may be a
bare name, which callers will have to handle as appropriate.
The other option would be to provide an additional SASL callback
allowing callers to define their own canonicalization rules for
situations where the authzid is being derived from the authnid. In
this way the c2s code could append domain information, but the s2s
code wouldn't.
Aside: This is one area where the XMPP RFCs could do with some
clarification. 6.1.6 and 6.1.7 of RFC3920 are pretty much
contradictory. In the c2s case, they require that a client sets its
authnid to a 'simple username' (Just the node portion of the JID, in
effect), but require the authzid, if provided, be a full JID. It then
states that the client must not provide a authzid where it can be
derived from the authnid - without ever defining what that derivation
step is. If I authenticate as 'sxw' to a c2s instance for the domain
'inf.ed.ac.uk', my authzid should be '[EMAIL PROTECTED]'. But , can
that be 'derived', and so shouldn't be specified - or is it
underivable, in which case I MUST give [EMAIL PROTECTED] as the
authzid. In my experience, client authors don't know what to make of
this either - so you've got clients which always provide authzids and
some clients which never provide them.
Comments? My currently favoured solution (that I have code for) is to
make the interface changes as outlined above.
Simon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFGWXOHqWndc26pXmcRAjXFAKCwE4jSBuJ1xFrquUYuAZlLzFLAMwCfdtzA
zplpGe9IONBRhgS9X0+W1dw=
=V2rE
-----END PGP SIGNATURE-----
_______________________________________________
jabberd2 mailing list
[email protected]
http://lists.xiaoka.com/listinfo.cgi/jabberd2-xiaoka.com
