[Date Prev][Date Next]
There has been some confusion on how this all really should work.
This is meant to clarify how I think it needs to work.
A normal SASL bind should have an empty authorization identity.
If the server accepts the authentication, the authorization identity
is derived from the authentication identity.
A "proxy" SASL bind should have a non-empty authorization identity.
The identity asserted can be in any number of forms.
The resulting authorization identity is mapped to a SubjectDN for
purposes of authorization approval and access controls. Also, the
authentication identity needs to be mapped to a DN for purposes of
authorization approval. The mapping processes are similiar.
Even where there is no proxy policy, a number of mappings need
The authentication identity <foo> needs to be mapped
into a uAuthzID <u:foo> and then mapped to a dnAuthzId <dn:uid=foo,[cn=realm,]cn=mech,cn=authzid> and then regexed
(if provided) per regex <dn:uid=foo,dc=example,dc=net>.
Also, if authorization identity is:
c) dn:uid=foo,[cn=realm,]cn=mech,cn=authzid (optional)
the authorization is accepted and, in all of the above cases,
the subject DN becomes <uid=foo,dc=example,dc=net>. The
key is that equivalent authorization identities result in
the same subject DN.
a) authentication identity <foo> implies the authorization
<u:foo> by hard code,
b) the authorization identity <u:foo> implies the authorization
identity <dn:uid=foo,[cn=realm,]cn=mech,cn=authzid> by hard
c) the authorization identity <dn:uid=foo,[cn=realm,]cn=mech,cn=authzid>
implies the authorization identity <dn:uid=foo,dc=example,dc=net>
d) The authorization identity <dn:uid=foo,dc=example,dc=net> implies
the SubjectDN <uid=foo,dc=example,dc=net> by hard code.
The proxy policy code must apply similar mappings to both
the asserted authentication identity and authorization identity.
The authentication identity mapping requires 4 steps.
The authorization identity mapping requires 1-4 steps
depending upon input.
The proxy policy should map both asserted authentication
identity and the asserted (or derived if empty) authorization
identity to form c and compare. If same, approve authorization
and assert c as the SASL username. If different, use in
directory information (which may require mapping each to d)
to approve. If approved, assert c as the SASL username.
The sasl bind routine then maps c to d to provide a consistent