Re: saslAuthz{To|From}

["Randall S. Winchester" <rsw@sendmail.com>]

My comment would be that for a multi-domain site, a uid can include a
FQDN, like u:jane@janedoe.com.
Using this form could limit some of the extra mappings.

This should not be a problem, correct?

Randall

On Sat, 13 Dec 2003, Kurt D. Zeilenga wrote:

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