OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

RE: [xacml] bags and targets. Forwarded message from Seth Proctor .

  • 1.  RE: [xacml] bags and targets. Forwarded message from Seth Proctor .

    Posted 10-19-2002 16:37
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

    [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 .


    On Sat, 19 Oct 2002, Daniel Engovatov wrote:
    
    > Not sure what exactly is being broken -  the evaluation performed is exactly
    > the same - the only difference is the "automatic" type convertion function
    > application for this very narrow and well defined case.
    
    That's not what I am talking about.
    
    I am talking about taking you match statements and evaluating the request
    context against them.
    
    If you have 100,000 policies all of which only 3 apply to a subject-id of
    "john".
    
    You can take the information in the request context, i.e. subject-id of
    John, and find those three policies by indexing, of which now, you apply
    the combining algorithm against their evaluations.
    
    Now, if you didn't have a request context with a subject-id attribute?
    
    You might get other policies that apply on some other criteria, but you
    would be forced to throw an Indeterminate? How would you even find those
    policies to begin with?
    
    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.
    
    Remember, the combining algorithms do funky things with indeterminates,
    like make them disappear, in favor of Deny or Permit, up the evaluation
    chain. So you would indeed have to evaluate each and every target of every
    policy for each request, all 100,000 of them!
    
    That is not what Targeting is for. It is supposed to aid in simple
    indexing and finding of applicable policies.
    Hal wouldn't you agree?
    
    Otherwise, we might as well just get rid of target alltogether and leave
    everything into a condition.
    
    Targeting allows you to place simple critera for discovering the
    applicability of a policy, and nothing else. If an attribute is needed and
    it is not there, that logic should reside in the <Condition>, which MUST
    be evaluated once the policy/rule is considered applicable.
    
    -Polar
    
    > Matching (member-of "blah" <designator>)  and (string-equal "blah" <implicit
    > string-one-and-only<designator> >)  is the same - you can compile and make
    > sure the type safety is satisfied just as well.  It is only a syntax issue
    > to allow easier use of designators/selector in target without opening up the
    > syntax to a full blown <apply> tree.
    >
    > If you have your context precompiled and verified you index the target in
    > just the same way - you just write it down in a little bit diferent manner..
    >
    > But I do agree that everything complicated sould go into condition - but we
    > already have our target structure.
    >
    > Daniel;
    >
    >
    >