[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