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

Re: saslAuthz{To|From}

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:

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}


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   |