RE: saslAuthz{To|From}

["Howard Chu" <hyc@highlandsun.com>]

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

> > Well... specifying the realm is irrelevant
>
> I would agree in principle, but, as appeared in ITS#2871,
> someone might want to use that field to map the incoming
> ID from a regular auth with a mech that uses thr realm,
> and use the same rule for proxyAuthz control.  If we allow
> to specify the realm (but not the mech) we give more freedom
> in writing sasl-regexp rules.  If we find out this freedom
> is too much, or has side effects that adversely impact
> security, then of course we need to limit it.  I'm open
> to any solution that resolves ITS#2871 without affecting
> security.

The realm field we're talking about here is useless. Only the DIGEST-MD5 mech
uses it, and the SASL library only allows it to have a single value. As such,
it is effectively a constant. A user cannot specify any other value for it,
so there is never an occasion to map one realm vs another.

> > This raises another point, which is vaguely related to the
> problem of
> > authorizing use of controls in the first place. I think it
> would be useful to
> > restrict the proxyAuthz control based on the LDAP
> Operation. E.g., I may only
> > want to authorize someone to proxy as me for Add
> operations, and nothing
> > else. This is not quite the same as the ACLs, nor do we
> need to duplicate ACL
> > functionality here. But it's something to consider.
>
> This sounds quite interesting.  A mech to do this could be
> to add the operation to the incoming ID, so that the
> sasl-regexp rule can take care of allowing/denying operations.

Yes, that was kind of my thought as well.

> One thing that s*cks is that the auth ID uses "cn" for every
> part; if we could use different attributes, or at least
> option modifiers, to clearly mark different parts ... e.g.

Yes, I think that's a pain too. How about this:
	uid=<user>,o=<mech>,cn=auth

Remember that mechs like Kerberos/GSSAPI keep their realm in the <user>
field, so we're not losing anything by dropping the xx=<realm> component.

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