[Date Prev][Date Next] [Chronological] [Thread] [Top]

SASL authcid/authzid



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
to occur.

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:
	a) empty,
	b) u:foo,
	c) dn:uid=foo,[cn=realm,]cn=mech,cn=authzid  (optional)
	d) dn:uid=foo,dc=example,dc=net
	
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. 

This means:

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
   code,
c) the authorization identity <dn:uid=foo,[cn=realm,]cn=mech,cn=authzid>
   implies the authorization identity <dn:uid=foo,dc=example,dc=net>
   by regex,
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
subject DN.