MHonArc v2.5.2 -->
xacml message
[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