The Subject/Object Paradigm

[Hal Lockhart <hal.lockhart@entegrity.com>]

At the last concall, I briefly mentioned that I considered the
subject/object paradigm for access control to be obsolete. Eve mentioned
this in the minutes, so I guess I should explain what I mean and why I am
NOT raising this as an issue at the current time.

The idea that Access Control decisions are structured around subject/object
was the basis of the earliest formal models of access control. It is a
feature of the Lattice, Bell-LaPadula, Biba and Clark-Wilson models. (Object
in this context is roughly equivalent to Resource.) This view can be
characterized as "Who are you and therefore what are you allowed to do?"

A more recent view of the same problem takes the access control decision as
a starting point and asks "Under what conditions should this request be
allowed?" In this resource-centric view, many different inputs may be
combined to make the decision, not just user identity.

The views are obviously not totally incompatable and in many common cases,
no difference will be seen. Certainly the identity and properties of the
user making the request will often be a factor in the decision under the
resource-centric view. Common implementations of the subject/object
paradigm, such as permission bits and ACLs are resource-centric in the sense
that policy information is organized by associating it with the resource
being protected.

However, I believe that the resource-centric model it a more useful way to
look at the problem in light of requirements for richer information
policies. The key elements in this view are 1) the resource that is the
subject of the request, which includes, implicitly or explicitly the
operation, 2) the policies which describe the conditions under which the
access will be allowed and 3) the runtime inputs to these policies. Policies
may consider not only user properties; but also the properties of
intermediaries to the request; environmental information such as the
date/time or location the request is being made from; application-specific
information, such as the transaction amount; and properties of the resource,
such as whose medical record it is.

The assertion structure proposed in the current SAML draft clearly reflects
the subject/object paradigm. However, I do NOT wish to raise this as an
issue at this time, for two reasons. The first is that I do not wish to make
make an objection on purely abstract grounds. If the design does all the
things I need, I am not that concerned about how the elements are named and
structured. Therefore I propose to simply comment on the specifics, which I
have done recently in a separate message.

The second reason is that there is a difficulty in the implementation of a
rich, resource-centric policy model. The problem is that there is generally
some overhead in obtaining the runtime inputs required for policy
evaluation. In most cases, it is the PEP that is in the best position to
collect these inputs. Further, it is generally undesirable to provide extra
inputs not required by current policy. Unfortunately, if the PDP is
encapsulated, the PEP will be unaware of the inputs required for a decision
about a particular resource.

The alternative of providing the ability for the PDP to request additional
information that it lacks, may be even more inefficient and at least
increases protocol complexity. This is worthwhile for the case of
encouraging the user to reauthenticate by a stronger means, but probably not
in general. 

The matter is greatly simplified when the PDP and PEP are closely coupled.
(This is the approach we have taken in our product.) But there is a question
in my mind as to how well a decoupled PEP/PDP architecture can ever support
this approach, therefore it seems wrong to object to the use of the simpler
model.

Hal