Re: Identity mapping and more

Kurt,

Just a note to say that I agreee that standardizing these mappings would
be very useful.  So much so that I think it would be useful even without
the ACM or replication considerations.

Rob.

"Kurt D. Zeilenga" wrote:

> While I do not support addition of "new" work, I do concur
> that for a access control policy to be evaluated consistency
> across multiple replicas that these replicas need to use
> common mechanisms and policy for generating those access
> control factors which are derived from the LDAP association.
> In particular, access control policy commonly acts upon subjects
> which are derived from identity the server has associated with
> the client.
>
> Some background based upon my particular operational experience
> in this area:
>
> Authentication Identity
>   The authentication process may or may not be based on
>   information held in the directory. The process results
>   in some "authentication identity" being associated with
>   the user.  It is generally derived from the credential.
>   The characteristics of the credential are mechanism
>   specific.  In some cases, a credential can be associated
>   with multiple identities.
>
> Authorization Identity, no proxy
>   The client derives an authorization identity from the
>   authentication identity, possibly based upon
>   information held in the directory.  If the server
>   supports multiple authentication mechanisms, it is
>   desirable to map all the authentication identities
>   which are associated with the same user to one
>   authorization identity.
>
> Authorization Identity, proxy
>   The client asserts the desired identity to assume.
>   As in the no proxy case, the server need to map
>   the authorization identity associated with the
>   authentication identity as this generally a factor
>   in the proxy authorization policy decision.  The
>   desired identity may also need to be mapped into
>   an appropriate form needed to make the policy
>   decision.  The policy and other information may or
>   may not be held in the directory.
>
> Access Control Subject Identities
>   The access control system may use as factors identities
>   information derived from the authorization identity
>   associated with the authentication identity or the
>   the authorization identity associated with the assumed
>   authorization identity.  I refer this as the subject
>   identity namely to imply additional mapping which
>   might be involved.
>
> In order to provide consistent mapping of identities
> between replicas, the work needs to consider a variety
> of identity mappings requirements.  And, obviously,
> information supporting the authentication process itself
> as well as the mappings needs to be replicated.
>
> Also, note that I only discussed identities above.
> There is also other access control factors which
> come the authentication/authorization system which
> need to be considered.
>
> Solving this problem is a major undertaking.
>
> If this is included as a charter work item, it warrants
> specific mention in the description.
>    In order to support consistent evaluation of access controls
>    across replicas, the working will deliver a specification
>    suitable for the Standard Track detailing mechanisms
>    supporting consistent authentication/authorization services
>    in replicated environments based upon a requirements which
>    the WG will document in an Informational RFC.
>
> And what I consider to be ambitious milestones:
>    March 2002 Initial Authc/Authz Services Req't I-D submitted
>    June  2002 Authc/Authz Services Req't I-D progressed to IESG
>               for consideration as Informational
>    July  2002 Initial Authc/Authz Services TS I-D submitted
>    Dec   2002 Authc/Authz Services TS I-D progressed to IESG
>               for consideration as a Proposed Standard
>
> Again, I do not support adding any new work to the LDUP charter.
>
> Kurt