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

Re: saslAuthz{To|From}

Kurt D. Zeilenga wrote:
At 06:11 AM 12/13/2003, Pierangelo Masarati wrote:

Pierangelo Masarati wrote:

now supports IDs in the form
- exact is trivial
- subtree means exact or children
- children means children but not exact
- regex uses regcomp/regexec to test
An unqualified ID of the form "dn:" is now
treated as exact.  I suggest using saslauthz.c 1.100
for the next releases, and move to 1.101 carefully
because this last change could break some configuration,
so be warned ...
IDs in the form "u:" are coming ...

I'm playing with "u:" form IDs, but they don't seem to be of much use; in fact, if a user in this form is found, it must be trnsformed in "dn:" form via slap_sasl2dn, which uses sal_parseURI after applying the sasl-regexp rules.

The intent of the u: is to free the user and administrator
from having to know/recall what DN(s) are associated with
the user.  The user Joe (joe) should be able to assume
Jane's identity (jane) without having to recall the DN
associated with Jane.


To request this with SASL, Joe can do this simply by asking to assume "u:jane". This should get mapped to a DN for the proxy authorization checks as well as subsequent access control/limit/etc. checks. Here, the authentication mechanism Joe used applies in the expansion of asserted authzid ("u:jane").

To request this with proxy authz control, Joe asserts
"u:jane".  It could be argued that this should be mapped
in the same manner above, e.g., with the mech name used
by Joe.

I was not sure using the same mech would be acceptable or not; this makes things fairly easy, 'cause I can use slap_sasl_getdn().

The next question is how to represent these identities in the policy statements. Is "u:jane" w/ MECH1 the same as "u:jane" w/ MECH2? I think generally yes but not necessarily. So, I think "u:jane" should be mapped based on a pseudo mechanism "authz". That is, u:jane in a to/from policy would become "uid=jane,cn=authz,cn=sasl" to support the general case. To support the not-necessarily case, we could have add qualifiers, e.g. "u.mech:jane", which would get mapped to "uid=jane,cn=mech,cn=sasl".

OK, so slap_sasl_getdn() with an appropriately crafted c_sasl_bind_mech field would do the job.

To deal with realms, I think one can just use u.mech-realm:jane and then use regexes to map it to the right DN... but if we want, we could add a u.mech.realm:jane feature.

dealing with realms is already supported: "u:jane@realm" (unless we accept "@" as a valid char in a userid, but this would lead to endless discussion, and it's already done somewhere else in the code :)

For the mech, I'd rather add another operator, to do


I would rather leave the <style> modifier to further
additions ...

Of course, cn=sasl DNs are subject to additional mapping before they are actually matched.

This is already present in slap_sasl_getdn()


Dr. Pierangelo Masarati         mailto:pierangelo.masarati@sys-net.it
LDAP Architect, SysNet s.n.c.   http://www.sys-net.it
|   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax:+390382476497    |