[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: [JunkMail] Re: Bug in LDAP_CONTROL_PROXY_AUTHZ (ITS#2871)

Well, regardless of what Cyrus SASL does or doesn't do, I don't think
we should a) attempt to parse authcid or realm values b) combine
authcid and realm strings into one value.  Beyond that, I don't mind
providing both values for mapping purposes EVEN IF that produces auth
DNs like:

It's easy enough to map these as needed.  (Or, to put another way,
we should use values "as provided".  Those who don't like how they
are provided can take it up with Cyrus SASL developers.)


At 12:19 PM 12/18/2003, Howard Chu wrote:
>> -----Original Message-----
>> From: owner-openldap-bugs@OpenLDAP.org
>> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of igor@ipass.net
>> Thanks.
>> Is this patch going to be backported to 2.1.x?
>I think the <absent mech> patch should be backported. I don't think we've
>resolved the realm handling satisfactorily yet.
>The client "-R" option can only ever affect the DIGEST-MD5 mech, it's not
>used anywhere else. It can only have any effect if the server supplies more
>than one realm in the DIGEST-MD5 challenge. The Cyrus DIGEST-MD5 mech never
>supplies more than one realm. I don't know if anyone else's SASL
>implementation behaves differently, but my tendency is to completely ignore
>this realm in any further thinking, as the Cyrus code already ignores it.
>The realm-embedded-in-the-authID trick that Cyrus uses is not documented by
>any of the SASL mechanism RFCs. I think we should ignore this as well, and
>never do any parsing of the provided authIDs. Even for Kerberos, which has
>explicit realms, Cyrus leaves the realm part in the username when it's a
>non-default realm.
>So, our SASL DNs should only ever be of the form:
>        uid=<username>,cn=<mech>,cn=auth
>Any objections?
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support