OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  CD-1 issue #10: denied access to internal nodes in hierarchy

    Posted 09-11-2009 13:11
    The issue number refers to the XLS-sheet found in this email:
    http://lists.oasis-open.org/archives/xacml/200909/msg00013.html
    
    The commenter notes that if access is denied to an interior node and 
    access is allowed to descendants of the denied node, then the 
    reassembled allowed nodes do not correspond to the original schema 
    anymore. The commenter proposes that the specification is changed so 
    that denying an internal node also means deny to all descendant nodes.
    
    The problem is actually wider than that. Denying (and thus removing) any 
    single leaf node could invalidate the schema since the node might be 
    required by the schema. So the proposed change would not fix the 
    identified problem. The problem is inherent in doing access control on 
    XML documents.
    
    Also, in a more general case, it is useful to have the current model. 
    For instance, in a medical application it could be the case that a 
    researcher is allowed to see selected diagnostics information contained 
    in a patient record, but the rest of the record, such as patient 
    identifying data, is denied to him.
    
    I propose that we make no change.
    
    Best regards,
    Erik
    


  • 2.  RE: [xacml] CD-1 issue #10: denied access to internal nodes in hierarchy

    Posted 09-11-2009 13:22
    I agree that no change is required, but for a different reason.  The
    issue is, what does an application do with an XML instance after getting
    decisions?  That is not in the domain of XACML.  In this case, the
    application wants simply to delete denied nodes of a document, which of
    course can violate the schema.  There are other solutions to this
    problem that have nothing to do with XACML.
    
    It is important for many other applications to have complete
    independence of decisions for all nodes of a hierarchy.  XACML should
    make no presumption about the meaning of hierarchy for determining
    access.
    
    --Paul
    
    >