[Date Prev][Date Next]
Re: (ITS#6757) SASL canonicalize doesn't work as documented
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6757) SASL canonicalize doesn't work as documented
- From: email@example.com
- Date: Mon, 3 Jan 2011 03:40:56 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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
> (1) Stick more or less with the current behaviour, and change the
> documentation to say that you'll get
> 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
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@<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
> 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
> If the username doesn't contain '@', but olcSaslRealm is set, then I suggest
> you insert that instead:
> And if there's no '@' and no olcSaslRealm, then just leave it alone:
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/