[Use Case] RE: The Subject/Object Paradigm

["Simon Y. Blackwell" <sblackwell@psoom.com>]

I am cross-posting this message from Hal Lockart because I think it is
particulalry germain to what we are doing. Although SAML may "punt" on this
issue for now, I feel we cannot. I strongly urge the use case folks to keep
this in mind when doing their initial work.

> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Friday, May 25, 2001 1:56 PM
> To: 'security-services@lists.oasis-open.org'
> Subject: The Subject/Object Paradigm
> 
> 
> 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
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-services-request@lists.oasis-open.org
>