OASIS eXtensible Access Control Markup Language (XACML) TC

Expand all | Collapse all

RE: [xacml] Draft BTG Profile

John Davis

John Davis12-09-2010 06:16

  • 1.  RE: [xacml] Draft BTG Profile

    Posted 12-09-2010 06:16



  • 2.  RE: [xacml] Draft BTG Profile

    Posted 12-16-2010 17:12



  • 3.  Re: [xacml] Draft BTG Profile

    Posted 12-16-2010 19:26
    Hi Hal
    
    On 16/12/2010 17:03, Hal Lockhart wrote:
    > We seem to have made some progress, but it seems to me that there are a
    > number of undefined requirements.
    > 1. The usecases mentioned seem to include the possibility that a BTG
    > condition can be associated with 1) a patient, 2) the Access Subject
    > (party making the request), 3) Medical Application, 4) Medical facility
    > or perhaps other scopes. If this is the case, how and to whom would the
    > scope of a given BTG be specified?
    
    In our implementation this is encoded into the BTG attribute type (that 
    shows whether the glass has been broken or not). So rather than having a 
    simple single BTG attribute, with values true and false, there are a 
    potentially infinite number of BTG attributes ie. we have changed the 
    scalar into a vector. You can regard the BTG attribute as a 
    multi-dimensional table in which each cell can be set to true or false. 
    The setting of the dimensions of the BTG attribute is a policy issue and 
    will vary from application to application.
    
    Important Note. In the BTG profile we wrote, nothing is said about how 
    the BTG state attribute is encoded or specified. It was not planned to 
    standardise this attribute type since every implementation will have its 
    own preferred set of attributes.
    
    
    > 2. This in affects the lifecycle of the BTG state, which has been
    > discussed to some extent. Specifically, most of these scopes imply that
    > once set, a particular BTG is in effect until it is turned off, whether
    > manually or by some automated criterion.
    
    this again is correct. In our implementation we have defined a ResetBTG 
    operation which allows an administrator to set a BTG attribute value 
    from True to False - the equivalent of replacing the glass in the fire 
    alarm. But we also (through obligations, specify an automated way for 
    the system to reset the state after a particular time has elapsed).
    
    
    > 3. On the last call David described a 3 step model. 1) a request is made
    > and denied and in some way it is reported that potentially a BTG state
    > might permit the access 2) a request is made to assert BTG, which is
    > authorization checked, assuming it is permitted, the new BTG state is
    > somehow propagated. 3) The original request is repeated with the
    > addition of the BTG assertion, which may result in the request being
    > granted. I believe others proposed that steps 2 & 3 could be rolled into
    > one. Is there any consensus on this point?
    
    If you review what I said previously, I support both models ie. the PEP 
    can set the state independently of the PDP, in which case you do not 
    need a BTG operation (2 above) nor a ResetBTG operation since the whole 
    BTG state is handled within application specific code. However, if you 
    want to remove the burden from applications and place it in the context 
    handler, then you do need a standard BTG operation (and resetBTG 
    operation) in order to tell the context handler when to set the state 
    and reset the state.
    
    
    
    > 3. No attention seems to have been paid to how a PDP would actually
    > figure out that a denied request might (would definitely) succeed if BTG
    > was asserted.
    
    Good question. In fact this has to be left up to the policy writer to 
    ensure that rules 2a and 2b (reproduced below for ease of reference) are 
    completely in sync. If you screw up your policy then the PDP could tell 
    a user he needs to break the glass, then reject his request.
    
    2a Kent. Grant Initiator access to Domain A objects with Target
    sensitivity attribute=”X” IFF Initiator role=”Y” and BTG State =”Glass 
    Broken”.
    
    2b Kent. Grant Initiator BTG access to Domain A objects with Target
    sensitivity attribute=”X” IFF Initiator role=”Y” On grant return 
    obligations "notify manager, write to audit trail etc as determined by 
    application".
    
    Of course software implementors could provide a policy user interface 
    that only allows the overall BTG conditions to be entered once and from 
    this both of the above rules are generated in XACML. So there are ways 
    to solve this problem.
    
    
      The currently analogous case, missing attributes can be
    > determined easily because it involves specific processing step. (If an
    > attribute reference by a policy is missing and is marked in the policy
    > as must be present, then report missing attributes.) It seems to me that
    > assuming several applicable policies for a request, that determining if
    > BTG would help in the general case could be quite difficult. I am
    > interested in how this is being done currently in XACML PDPs. (David's
    > policy language is different and I am not familiar with its capabilities.)
    
    the policy language is not actually an issue, since rules 2a and 2b 
    above can presumably to translated into any access control policy 
    machine language. What our implementation has done is provide the 
    context handling wrapper that holds the BTG state. It can wrap any type 
    of PDP that supports the XACML interface.
    
    regards
    
    David
    
    > Hal
    >
    >