[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Portable Interoperable Policy: Issue on the ResourceId,ActionId, and SubjectId
Why should the "ResourceId" ResourceAttribute be required to be supplied and yet no attributes for any particular Subject are required to be present? If you are going to write a policy that is "guaranteed" to work on any PDP. It MUST be written on the lowest common denominator of PEP-PDP behavior. Writing policy on attributes that may or may not exist isn't really portable to different PEP-PDP implementations. If we mandate that in the RequestContext that every Subject must have a "SubjectId" attribute, a Resource must have a "ResourceId" attribute, and an Action just have a "ActionId" attribute, then we can write policy based solely on those attributes that is guaranteed to be executable the same way by every PEP-PDP implementation, because a minimal amount of information must be supplied in the RequestContext. Let's say I have a policy that is the following: Rule Combinator = FirstApplicable: ResourceId == "R1" ActionId == "A1" SubjectId =="George" -> Deny ResourceId == "R1" ActionId == "A1" SubjectId =="Paul" -> Deny ResourceId == "R1" ActionId == "A1" SubjectId =="Ringo" -> Permit AnyResource, AnySubject, AnyAction -> Deny If I place this policy on PEP-PDP 1, an implementation that supplies ResourceId, ActionId, SubjectId, but nothing else. RequestContext: Resource (Attribute "ResourceId" "R1") Action (Attribute "ActionId" "A1") Subject (Attribute "SubjectId" "Ringo") The answer is Permit. So, let's say I place this policy on a PEP-PDP 2 that is required to supply ResourceId, ActionId, but not SubjectId. However, it just happens to supply a whole bunch of other Subject attributes. RequestContext: Resource (Attribute "ResourceId" "R1") Action (Attribute "ActionId" "A1") Subject (Attribute "Group" "Beatles") (Attribute "Instrument" "Drums") The answer is Deny. So, I cannot write a policy that depends on "Group" or "Instrument" attributes being supplied, because that won't work on PEP-PDP 1. Also, I cannot write a policy that depends on "SubjectId" being supplied, because that won't work on PEP-PDP 2. I must KNOW EXACTLY which PEP-PDP implemenation/configuration that I am writing policy for. The basic upshot question is "Can I write a policy that will be guaranteed to be executed in the same way with the same result on any PEP-PDP implementation?" If you have mandatory attributes for each Resource, Action, and Subject construct, then the answer to that question is resounding YES. If you have just one of those constructs in which there are no mandatory attributes to be supplied, then the answer to that question is a resounding NO, unless you DO NOT consider that particular construct in the policy. Conclusion: ONLY IF you write policies that DO NOT concern Subject (i.e. they are based solely on Resource and Action) then policies you write will act the same way between these PEP-PDP implementations. However, without a Subject, access control doesn't really make sense. Cheers, -Polar
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC