[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [Use Case] RE: The Subject/Object Paradigm
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC