[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
dn[.{exact|subtree|children|regex}]:
where
- 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.


Agree.


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

"u:jane@realm/mech"

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

Ando.

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