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

RE: saslAuthz{To|From}

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Pierangelo Masarati

> Kurt D. Zeilenga wrote:
> > At 07:58 AM 12/13/2003, Randall S. Winchester wrote:
> >>My comment would be that for a multi-domain site, a uid can
> >>include a FQDN, like u:jane@janedoe.com.
> >
> >
> > Which is precisely why using @ as a realm separator is a bad idea.
> > We need to support the userid "jane@janedoe.com" existing
> > in multiple realms.

As noted, this is already a problem with current SASL behavior. We can't
really fix this without introducing a new incompatibility here.

> Yes.  I'm going to fix the slap_sasl_getdn() code as well,
> and we need to figure out a syntax to specify realm (and
> possibly mechanism) in "u:<user>" form.  What about:
> "u.realm;mech:<user>"

I think adding a mech specifier is a really bad idea. You might regard this
as policy that should be left up to the administrator, but there are very few
good reasons to do this, and one very bad reason - different mechs have
different security properties. You really *don't* want a user bound with (a
lesser mech) to be able to proxyAuth as a user with (a stronger mech's)
identity. I strongly vote against supporting a mech specifier here. The proxy
should use the mech name that's already associated with the current session.
If there is no SASL mech associated, I suggest we use "cn=simple" and leave
it at that.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support