Brian Candler wrote:
Now, if my understanding of the user_realm parameter is correct, I think
there are two ways to make OpenLDAP's behaviour consistent with its
documentation.
(1) Stick more or less with the current behaviour, and change the
documentation to say that you'll get
uid=ursula/admin@foreign.realm,cn=gssapi,cn=auth
for foreign realms.
However, the odd thing about the current behaviour is that setting
olcSaslRealm always sticks a static value (...,cn=<olcSaslRealm>,...) into
the auth DN, regardless of whether it's local or foreign. That's not very
useful.
Note that it's not the OpenLDAP code that's sticking this in there; it's the
Cyrus code that's returning this realm in the callback. IMO our job is to
faithfully return what the Cyrus library gave us.
I think it would make more sense, if olcSaslRealm is present, to use it to
*qualify* usernames which don't have a realm.
That decision is made by the Cyrus library, not us.
uid=kurt,cn=gssapi,cn=auth
---> uid=kurt@<olcsaslrealm>,cn=gssapi,cn=auth
i.e. change the canonicalize function to append @user_realm if the username
doesn't contain '@'.
This would be useful if you want to undo the Cyrus SASL GSSAPI behaviour of
stripping off the default realm.
(2) Change the OpenLDAP behaviour so that it matches the documentation at
http://www.openldap.org/doc/admin24/sasl.html#GSSAPI
To do this, the canonicalize function would have to parse the username,
splitting it on '@' to separate username from realm, so that you would get
uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth
If the username doesn't contain '@', but olcSaslRealm is set, then I suggest
you insert that instead:
uid=kurt,cn=<olcsaslrealm>,cn=gssapi,cn=auth
And if there's no '@' and no olcSaslRealm, then just leave it alone:
uid=kurt,cn=gssapi,cn=auth
This has been discussed at great length, read the -devel archives from 9 or 10
years ago. The fact is that the SASL specification doesn't reserve '@' as a
special character and there is no guarantee that this is actually a realm
separator. There are plenty of authentication mechanisms where '@' is an
integral part of the username. This suggestion simply won't fly.
I don't believe we have any freedom to make any code changes here; feel free
to suggest verbiage changes for the documentation.
--
-- Howard Chu
CTO, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/