[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Identity mapping and more
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
Some background based upon my particular operational experience
in this area:
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, 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.