[Date Prev][Date Next]
> -----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
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:
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
Symas: Premier OpenSource Development and Support