Re: saslAuthz{To|From}

[Pierangelo Masarati <ando@sys-net.it>]

Howard Chu wrote:
> > -----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.

I agree in eliminating any concern about the realm part
(see a previous posting), and, consequently, in reverting
"u:" auth ID specification to its original form.

> > > 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

At this point, we may allow a template :)

authID-template "uid=$UID,ou=$OP,o=$MECH,cn=auth"

with OP in {add,bind,compare,delete,extended,modify,modrdn,search}

Ando.

> 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.



--
Dr. Pierangelo Masarati         mailto:pierangelo.masarati@sys-net.it
LDAP Architect, SysNet s.n.c.   http://www.sys-net.it

+----------------------------------------------------------------------------+
|                                                                            |
|                     Buon Natale e felice Anno Nuovo                        |
|                                                                            |
|   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497   |
+----------------------------------------------------------------------------+