OASIS eXtensible Access Control Markup Language (XACML) TC

Re: [xacml] clarifications/questions for worklist items 26, 29 and32

  • 1.  Re: [xacml] clarifications/questions for worklist items 26, 29 and32

    Posted 10-16-2003 16:35
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: Re: [xacml] clarifications/questions for worklist items 26, 29 and32


    Polar Humenn wrote:
    > ...
    >>>29. Policy Authority Delegation
    >>>
    >>>  We had a number of questions about this.  It needs
    >>>  clarification.  Issues:
    >>>
    >>>  a. Define "domain".  What does it correspond to?
    >>>  b. Could this be solved using a subject-domain or
    >>>     resource-domain attribute that the PEP should include in its
    >>>     Request, and that policies could match on?
    >>>
    >>>  Wait for Frank to provide clarification before putting on F2F
    >>>  agenda.
    >>>
    >>>  F2F: not until/unless Frank clarifies, but then possibly
    >>
    >>I have the feeling that all the "delegation" related items will be solved when
    >>we tackle the "right of a subject to administer policy for a certain target".
    >>
    >>I reworded the description in item#29:
    >>
    >>29. Policy Authority Delegation
    >>    The ability to express in a policy rule that a certain authorization
    >>authority is allowed to administer access control policy for a certain target.
    > 
    > 
    > Isn't this just straightforward application of XACML policy to a
    > "administer access control policy" action for a certain target?
    
    
    More or less ... but we don't seem to have a placeholder for policy issuer: if I 
    want to express that John can administer the action=read on resource=abc for 
    Subject=Mary, then what is "John", and where do I match on "John"?
    
    I have the feeling that we may need a specific policy-set/policy/rule issuer...
    
    
    > Sorry Frank, but I'm having a hard time parsing the following description.
    > 
    > 
    >>The evaluation for a certain target should probably yield "Indeterminate" or
    >>"Not Applicable" (?) according to the local policy,
    > 
    > 
    > Why *should* it yeild Indeterminate or Not Applicable?
    > 
    >>it should yield "Permit" for the right of an authorization authority to
    >>administer the policy for that target, and either the authorization
    >>query to that authorization authority's PDP should yield "Permit" or the
    >>evaluation of the pushed access control assertion by that authorization
    >>authority should yield "Permit". If the local policy yield either
    >>"Permit" or "Deny", the foreign authorization authority doesn't have to
    >>be considered.(?)
    > 
    > Okay now I am afraid, I'm lost.  Do you have a specific use case for this
    > one that we can see what your requirements are?
    
    Sorry, my wording may have been a bit terse.
    I was trying to point out the consequences of having multiple authorization 
    authorities (AA), and what kind of combinators you would need to resolve any 
    ambiguity.
    
    The rules that seem most straight forward are that if you have a number of AAs 
    on the same level, then you should have a deny-overwrites combinator as you 
    "value" each of the AA's equally, and taking the safe route makes sense.
    
    If you delegate admin rights to an other AA, then giving the ability of this 
    second-level AA to overwrite explicit access control policy doesn't feel right. 
    So, if the authorization decision of the AAs on the same level yields an 
    explicit permit or deny, we do not have to consider the policy of any further 
    delegated admin rights.
    As a consequence, the policy of an AA would only become important if the lower 
    level AAs indicate that they do not want or can not make explicit authorization 
    decisions on the target under consideration: only after the combined policy 
    evaluation on the same level yields Indeterminate or Not Applicable, the next 
    level of AAs should be considered.
    In short, it comes from the observation that you do not want to give anyone else 
    the right to over-rule your own explicit policy.
    
    For example, if Marc's local/default/preferred policy states that John is 
    allowed to administer the action=read for subject=Mary and resource=abc, and 
    Marc's own policy explicitly denies or permits Mary read-access to abc, then it 
    doesn't matter what John's policy evaluates to.
    However, if Marc's own policy doesn't evaluate to any explicit permission for 
    the mary/abc/read target, then it becomes important what John has to say about 
    that target.
    
    Hopefully this clarifies some... a white board and the upcoming F2f may help.
    
    Regards, Frank.
    
    
    -- 
    Frank Siebenlist               franks@mcs.anl.gov
    The Globus Alliance - Argonne National Laboratory
    
    


    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]