[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: saslAuthz{To|From}
> -----Original Message-----
> From: Luke Howard [mailto:lukeh@PADL.COM]
> >There's a bug in here somewhere. If the Cyrus library
> grabbed the name and
> >parsed a realm from it, then it should not have appeared
> redundantly when it
> >got to us. Either it was provided in an explicit realm
> parameter, or it was
>
> I'm using a fairly old version of Cyrus, and I should
> upgrade. But I don't
> think it's related to this issue: pre upgrading to OpenLDAP
> 2.2.3 things were
> working just fine.
>
> If my memory serves me correctly I was seeing the realm in
> the user name only
> for authorization identities that looked like
>
> u:foo/bar@REALM
>
> whereas
>
> u:foo@REALM
>
> was parsed as before, ie. the realm did _not_ appear in the
> user name. Perhaps
> there is some escaping issue? The forward slash character is
> used in Kerberos
> to represent multiple instances of a principal name.
Well the odd thing is that you're using the EXTERNAL mech, which doesn't do
any parsing (or anything else) at all.
Taking a quick tour thru the Cyrus code, I remember now what it does... The
client's -R realm is only checked if the server presents a list of multiple
realms to choose from. If the server only presents a single realm, the client
uses it implicitly and ignores anything the user might have specified
with -R. But on the server, the SASL plugins (except EXTERNAL) always parse
the provided username: strchr(input, '@') and split that into user & realm.
So there's a bunch of junk going on in Cyrus SASL that's going to prevent
this from ever working.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support