[Date Prev][Date Next]
My comment would be that for a multi-domain site, a uid can include a
FQDN, like u:email@example.com.
Using this form could limit some of the extra mappings.
This should not be a problem, correct?
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.