[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] bags and targets. Forwarded message from Seth Proctor .
Let me clarify a bit. The way I see the indexing working: Policy is analysed and, for example, rules requiring attribute "foo" to match are present. Rules are indexed by the value of "foo" required to match. Rules are indexed by each attribute required to match - so, yes it is expensive to have rules requiring many different attributes - but there is no way around this anyway. If a request, with an attribute "foo" comes in - rules are looked up - constant time per each attribute. It is known in advance that rules requiring "foo" are needed, so if it is not present, automatically, the whole table of rules indexed by "foo" are getting Indeterminate result in match - in constant time, that's what happens. What to do with all this rules - that's a different thing, but as long as we MAY have missing attributes in match (they are (non)received with a request), this can happen and it does scale well. So it does scale as long as it is an match that can be hashed. -----Original Message----- From: Polar Humenn [mailto:polar@syr.edu] Sent: Sunday, October 20, 2002 7:52 PM To: Daniel Engovatov Cc: '''Anne.Anderson@Sun.com' ' '; ''XACML TC ' ' Subject: RE: [xacml] bags and targets. Forwarded message from Seth Proctor . On Sat, 19 Oct 2002, Daniel Engovatov wrote: > >If you are allowed to have a single policy with a TARGET that says "if > >you don't have an attribute of "subject-id" throw an Indeterminate". That > >forces the PDP to evaluate each and every target, all 100,000 of them > >for each request, to make sure that the attributes are there. > > Absoutely not. The time to look up "John" in a hash map is the same whether > "John" is present or not. It is O(1) for any case when it can be reduced to > an equality operation and indexed in advance - is not it? I think you mean, the time to look up subject-id "John" in the hash map is the same as looking up whether the subject-id is present or not. It's one thing to *have* a subject id with "John" and look up applicable policies. Its an entirely different thing to NOT have a bunch of ???? attributes and find out if there are any policies that want it. Let's say you have a FirstApplicable combining Algorithm on the the policy set. The first Target wants a "subject-id" match to "John". The second wants a "weight" attribute of "100lbs". If you have a request with a "subject-id" of "John" and no "weight" attribute. What happens? What happens if you have a "weight" attribute of "100lbs", but no "subject-id" attribute? What happens. I know it's a seemingly simple case, but now expand that with many policies, many targets, and also consider the recursive nature of the policy set composition. You end up having to encode the logic of the combining algorithms into your missing attribute discovery. Also, think of the Subject section which has complex logic for dealing with different subjects. That evaluation is of greater complexity of just looking up policies against attributes you already have. The Target should determine the applicability of the policy or rule, and nothing else. The complex logic goes in the condition. Indeterminate is an error condition, it should not be relied upon for policy decisions. That is an abuse of the intent. Use the right logic, and determine the proper effect. -Polar
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC