Re: saslAuthz{To|From}

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

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.

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.

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

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.

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

Comments?

Kurt





>So whenever one needs to write
>saslAuthz{To|From} values, "dn:" froms can be used with
>much more expressivity insetad of "u:" forms.
>
>I can leave it in place for completeness (I need to check
>if there's any chance of infinite loops, though)
>but we should not incourage their use.
>
>And, we need to clarify if we want to allow the
>"u:<username>" form, which, to be expanded to sasl form,
>needs some info that is not available (mech, realm and so)
>or directly in th more expressive sasl form
>"u:uid=<username>[,cn=<realm>][,cn=mech],cn=auth"
>
>to summarize:
>- "u:<username>" is impossible, we need to know mech and realm
>- "u:<sasl name>" is possible; it is run thru sasl-regexp
>  to compute the DN and then compared to the asserted DN
>
>Comments are welcome.
>
>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    |
>+----------------------------------------------------------------------------+