OASIS eXtensible Access Control Markup Language (XACML) TC

Expand all | Collapse all

Issue: Hierarchical profile appears ambiguous and inconsistent

  • 1.  Issue: Hierarchical profile appears ambiguous and inconsistent

    Posted 01-15-2009 06:55
    I am finding the Hierarchical profile ambiguous and inconsistent and 
    therefore incomprehensible, which may, similarly to the Multi-Resource 
    profile be because there are essential contextual paradigms missing from 
    the specification.
    
    For the Multi-Resource profile, the missing contextual paradigms included:
    
        * It is necessary to pre-process the multi-resource request and
          submit individual requests to the PDP, and then to package up the
          responses into a single response.
        * The PDP, itself, can only process Request elements that in 2.0
          contain a single Resource element, single Action element, single
          Environment element, and multiple Subject elements, but each
          Subject element has to have a distinct SubjectCategory attribute,
          and in 3.0 there can be multiple Attributes elements, but each has
          to have a distinct Category attribute.
    
    Once the above paradigms are established, the Multi-Resource profiles 
    become comprehensible.
    
    I suspect something similar is going on w the Hierarchical profile also.
    
    Here is the background on the Hierarchical profile that I am trying to 
    work thru (each bullet represents a potential issue to resolve or 
    suggestion for improvement):
    
        * There needs to be a definition of "hierarchy". In particular, a
          "hierarchy" defn should state that the fundamental properties are
          that there must be a single root node with no parent, and that
          every other node in the hierarchy must have one and only one
          parent, and can have zero, one, or more children.
        * Section 3.2 is the biggest problem. To begin, the following needs
          confirmation: it appears that the key structural sentence for 3.2
          that explains what the four bullets that follow it are is lines
          314-315 (which is sandwiched between a negative statement on
          ResourceContent and subsequent 3 sentence "note") that state:
              o "The request context 


  • 2.  Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent

    Posted 01-15-2009 07:24
    On Jan 14, 2009, at 10:54 PM, Rich.Levinson wrote:
    
    >    * There needs to be a definition of "hierarchy". In particular, a
    >      "hierarchy" defn should state that the fundamental properties are
    >      that there must be a single root node with no parent, and that
    >      every other node in the hierarchy must have one and only one
    >      parent, and can have zero, one, or more children.
    
    I am not sure why do you think this is a requirement.   It is a  
    normal use case to inherit policy from more then one parent, and  
    "ancestors" attribute approach allows such models without undue  
    restrictions.
    
    >    in order to submit a request  one has to somehow identify all  
    > the hierarchies the given node
    >      belongs to, all the hierarchies the node's parent(s) and  
    > ancestors to, and include an Attribute element for each.
    
    And why is that a problem?   Yes, if one wants "inheritance", graph  
    needs to be defined, and attributes is a natural way to define it.
    
    >  I suspect that at most one would need to collect all the normative  
    > representations of only the resource-id node (i.e. identify all the  
    > hierarchies it belongs to), then for each hierarchy, one would  
    > evaluate the policies that apply to that hierarchy.
    >
    
    Policy evaluation does not need to know anything about hierarchies  
    that are represented with an "ancestor" attribute.
    
    Daniel;
    


  • 3.  Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent

    Posted 01-15-2009 14:43
    
    
      
      
    
    
    Hi Daniel,

    Thanks for the feedback. Let me try to clarify a bit.
    My first objective is to understand what the spec currently says, and I am finding that the terminology is inherently ambiguous, and as a result, to me at least, that makes the details of the spec impossible to understand. So, what I did was try to disambiguate by defining "hierarchy". Let me be more explicit:

    Lines 73-77 state the following:
    In this Profile, a resource organized as a hierarchy may be a “tree” (a hierarchy with a single root) or a “forest” (a hierarchy with multiple roots), but the hierarchy may not have cycles. Another term for these two types of hierarchy is “Directed Acyclic Graph” or “DAG”. All such resources are called hierarchical resources in this Profile. An XML document is always structured as a “tree”. Other types of hierarchical resources, such as files in a file system that supports links, may be structured as “forests”.
    This is an inherently self-contradictory definition. A hierarchy has a single root. It is an "ordered set", where each entity in the set has a defined relationship to every other entity. A "forest" is not a hierarchy. It is multiple hierarchies. The "definition" above is not meaningful because it equates the singular and plural.

    As a result of this self-contradiction, the spec then goes to introduce what, to me are meaningless concepts, such as lines 315-316:
    Note that a node in a hierarchical resource that is not represented as an XML document MAY have multiple parents.
    Therefore, in order to understand what the spec says, I first found it necessary to come up with an unambiguous term for "hierarchy", which allows sentences such as the above to be restated in a "meaningful" way, such as:
    Note that a node in a hierarchical resource that is not represented as an XML document MAY belong to multiple hierarchies and have a parent associated with each one.
    I am not saying anything so far is "wrong", simply that it is not understandable without firming up the definitions.

    wrt to the "somehow identify all the hierarchies a node belongs to" comment, I was not saying it was a problem, but simply observing that that was what the spec was saying in terms of specific defn of the term "hierarchy".

    Finally, I do not understand your comment that says:
    Policy evaluation does not need to know anything about hierarchies that are represented with an "ancestor" attribute.
    I am trying to understand what policies are supposed to do with the definitions in the spec. i.e. it is the spec that says in section 3.2 that all the parent and ancestor nodes need to be assembled in the request context. What "policy evaluation" are you referring to? Are you saying what I indicated in original email that a policy does not need to know anything about hierarchies that the resource-id node does not belong to?

        Thanks,
        Rich



    Daniel Engovatov wrote:
    1448A6CC-1532-40B4-BFC0-DC9D0413097E@streamdynamics.com" type="cite">
    On Jan 14, 2009, at 10:54 PM, Rich.Levinson wrote:

       * There needs to be a definition of "hierarchy". In particular, a
         "hierarchy" defn should state that the fundamental properties are
         that there must be a single root node with no parent, and that
         every other node in the hierarchy must have one and only one
         parent, and can have zero, one, or more children.

    I am not sure why do you think this is a requirement.   It is a normal use case to inherit policy from more then one parent, and "ancestors" attribute approach allows such models without undue restrictions.

       in order to submit a request  one has to somehow identify all the hierarchies the given node
         belongs to, all the hierarchies the node's parent(s) and ancestors to, and include an Attribute element for each.

    And why is that a problem?   Yes, if one wants "inheritance", graph needs to be defined, and attributes is a natural way to define it.

     I suspect that at most one would need to collect all the normative representations of only the resource-id node (i.e. identify all the hierarchies it belongs to), then for each hierarchy, one would evaluate the policies that apply to that hierarchy.


    Policy evaluation does not need to know anything about hierarchies that are represented with an "ancestor" attribute.

    Daniel;

    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


  • 4.  Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent

    Posted 01-15-2009 14:53
    Rich.Levinson wrote:
    > I am trying to understand what policies are supposed to do with the 
    > definitions in the spec. i.e. it is the spec that says in section 3.2 
    > that all the parent and ancestor nodes need to be assembled in the 
    > request context. What "policy evaluation" are you referring to? Are 
    > you saying what I indicated in original email that a policy does not 
    > need to know anything about hierarchies that the resource-id node does 
    > not belong to?
    
    Hi Rich,
    
    I don't understand all the questions you have, but here's the basic 
    approach of the profile in a simple example.
    
    Assume the following simple hierarchy:
    
    A <- B <- C
    
    If someone requests access to C, the request will contain these 
    attributes. this is from the top of my head, so it might be slightly 
    inaccurate and I might have forgotten some of the attributes, but 
    hopefully you get the idea.
    
    
    
    All these attributes are there so it is possible to write policies which 
    apply to parts of the hierarchy, not just individual nodes.
    
    For example:
    
    
    
    Matches only the resource C, nothing else.
    
    
    
    
    matches the immediate children of B. In the example this is C, but if C 
    had a sibling, it would also match.
    
    
    
    
    
    Matches B or any node below B. In this case also C.
    
    Best regards,
    Erik
    
    


  • 5.  Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent

    Posted 01-15-2009 16:38
    
    
      
    
    
    Hi Erik,

    Thanks for this feedback. Unfortunately I did not have time to process this email before today's meeting, but now that I have, it addresses one of my major concerns which was the motivational context. i.e. by seeing the actual example you provided, I can see that a Policy can now base decisions knowing that some node happens to be an ancestor of the requested node.

    In addition, for your example, I think it would be instructive to show when a node belongs to two or more hierarchies, that the collection of attributes should probably have a mechanism to indicate which hierarchy a node belongs to. For example, if C had an alias C', and parent B' and ancestors A'->D' where, while (C = C'), that in general (B != B') and (A != A') and obviously D' has no relation to the unprimed nodes at all. We would then have a request:
    <Resource>
     resource-id = C
     parent-id = B
     self-or-ancestor = C
     self-or-ancestor = B
     self-or-ancestor = A
     resource-id = C'
     parent-id = B'
     self-or-ancestor = C'
     self-or-ancestor = B'
     self-or-ancestor = A'
     self-or-ancestor = D'
    </Resource>
    It would seem to me that there needs to be a mechanism whereby one would be able to tell the primed from unprimed attributes. Possibly using Issuer

    In any event, it is useful information to have this additional context for understanding the current spec.

    As agreed at the meeting, I will try to find some cycles to say what I think needs to be done to make the spec easier to understand, which is possibly just including the above information (i.e. your email extended to multiple hierarchies with some example policy concepts, also such as you provided).

    Also, I think, as I mentioned at the end of the meeting that "scope" may also have a meaningful role to include in this profile as well. i.e. one can easily see that if policies are defined whereby certain conditions apply when a resource-id node is within scope (as defined by multi-resource spec) of some other node, that some if that ""other node" happens to be a parent or ancestor of the resource-id node, then those "certain conditions" would apply to the current resource-id being requested.

        Thanks,
        Rich




    Erik Rissanen wrote:
    496F4DC8.4030200@axiomatics.com" type="cite">Rich.Levinson wrote:
    I am trying to understand what policies are supposed to do with the definitions in the spec. i.e. it is the spec that says in section 3.2 that all the parent and ancestor nodes need to be assembled in the request context. What "policy evaluation" are you referring to? Are you saying what I indicated in original email that a policy does not need to know anything about hierarchies that the resource-id node does not belong to?

    Hi Rich,

    I don't understand all the questions you have, but here's the basic approach of the profile in a simple example.

    Assume the following simple hierarchy:

    A <- B <- C

    If someone requests access to C, the request will contain these attributes. this is from the top of my head, so it might be slightly inaccurate and I might have forgotten some of the attributes, but hopefully you get the idea.

    <Resource>
     resource-id = C
     parent-id = B
     self-or-ancestor = C
     self-or-ancestor = B
     self-or-ancestor = A
    </Resource>

    All these attributes are there so it is possible to write policies which apply to parts of the hierarchy, not just individual nodes.

    For example:

    <Target>
     resource-id = C
    </Target>

    Matches only the resource C, nothing else.


    <Target>
     parent-id = B
    </Target>

    matches the immediate children of B. In the example this is C, but if C had a sibling, it would also match.



    <Target>
     ancestor-or-self = B
    </Target>

    Matches B or any node below B. In this case also C.

    Best regards,
    Erik



  • 6.  Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent

    Posted 02-17-2009 00:26
    
    
      
      
    
    
    Hi All,

    I am choosing this point (in the email threads) to continue discussion of the issues with the Hierarchical profile as I think it contains the best context to start from.

    As indicated in the last couple of TC meetings, the update I proposed:
    http://lists.oasis-open.org/archives/xacml/200901/msg00079.html

    only goes part-way to addressing the problems I have found in the Hierarchical profile specification. The update only includes effectively a glossary with definitions of the terms that are currently used in the spec that make the rest of the spec comprehensible (at least from my perspective), and based on that glossary, the spec includes a few clarifying edits, which are primarily intended to make the statements in the spec consistent in terms of the definitions in the glossary.

    Primarily, the glossary simply defines "hierarchy" and "DAG" (Directed Acyclic Graph), where DAG is a collection of hierarchies that are mapped onto a flat collection of resources, where any resource can be a member of multiple hierarchies within the DAG.

    Based on this starting point and Erik's suggestion as to how the concepts might be applied in the real world, I did further investigation and have come to some additional preliminary conclusions on which I think the next step to address this spec should be based.

    1. The most significant conclusion I have reached is that the primary "problem" with the non-xml resources (section 3.2) is that the details here are solving a much more complicated problem than is necessary for most common use cases, which is that the resources are identified with URIs as described in section 2.2 and 4.3.

      In particular, this "more complicated problem" is one where the resource-id, itself, is not sufficient to describe the hierarchy of which it is a member. An example might be resources identified by serial number (a flat namespace), as opposed to resources identified by URI, which is an inherently hierarchical namespace (http://www.ietf.org/rfc/rfc2396.txt).

      With a hierarchical namespace there is no need to collect parent and ancestor nodes since they are already built in to the URI itself. In fact, there is an example document that I "found", that was produced as an artifact of the XACML 2.0 development effort, that appears to have gotten lost from the active XACML collection:
      http://www.oasis-open.org/committees/download.php/7315/xacml-profile-hierarchical-resources-nonXML-1.0-draft01.pdf

      that demonstrates this quite clearly: section 4.2 shows policies based on resource-ancestor and resource-parent attributes, and section 4.3 shows the same policies based on matching anyURI. i.e. if the resources are identified by URI there is no need to use resource-parent and resource-ancestor attributes either in the RequestContext or in the Policies.

      Based on this situation, my proposal is to enhance the existing Hierarchical spec using the URI representation in section 3.2 and indicating that this approach can be used instead of resource-parent and ancestor when the hierarchies are represented by nodes with URI resource-ids.

    2. A 2nd significant problem I believe I have found is that the algorithms defined in section 3.2 are incorrect in some significant ways, which I believe should be addressed (I will give an example below).

      My proposal here is to simply fix the algorithms.

    3. A 3rd significant problem I believe I have found is that there are important concepts that are either left out or not given sufficient emphasis in the spec, which, imo, cause conceptual ambiguities that make it effectively impossible to say what problem the specification is actually addressing.

      In particular, there is no explicit definition of "normative identity", which is a key term used in the algorithms defined in section 3.2.
      My proposal here is to assert that the normative identity may use either the recommended representation of URI described in section 2.2, or a functionally equivalent representation, such as can be constructed using resource-parent and resource-ancestor node collections.

      In particular, there is insufficient development of the concept of "consistent representations for identities" as mentioned in section 1, lines 68-72,  section 2, lines 175-178, section 3, lines 227-229. While the point is made that such consistent representations are necessary, the essential fact that in a DAG that a single node can have multiple normative identities AND that those identities each belong to a separate distinct hierarchy within the DAG is not established. The result is that it is conceptually ambiguous that when a node is said to have multiple parents, the essential fact is that the node must then have multiple normative identities, each of which is traceable to one and only one parent (or self, if the current node happens to be the top of one of the hierarchies within the DAG).
      My proposal here is to adjust the text to emphasize these notions accordingly.
    One final note: I appreciate the significant effort that went into the development of the Hierarchical specification. A review of the emails from April 2004 -> September 2004 will show anyone interested that a lot of work went into the development of this specification. My own interpretation of the problems I have had with this spec is that it was a relatively small, but considered to be important, part of XACML 2.0 and that while the ideas collected in this spec are generally properly targeted, it appears there was simply not sufficient time available for the TC to consolidate the findings of their studies of the hierarchy problem and to structurally sort the results into separable pieces that would have made the results easier to understand and apply.

    This effort is intended to build on the existing spec and emphasize aspects of it that currently are not, and to correct any problems that may be found in the process.

    As indicated above, I will give an example of what I consider to be an "error" in the algorithms of section 3.2:
    In section 3.2 the descriptions appear to be lterally "over-specified": for example, consider lines 324-327:
    " For each immediate parent of the node specified in the “resource-id” attribute or attributes, and for each normative representation of that parent node, an <Attribute> element with AttributeId “urn:oasis::names:tc:xacml:2.0:resource:resource-parent”. "
    This statement is indicating that the node "specified in the 'resource-id' attribute or attributes" can have multiple parents and that each of those parents themselves can have multiple normative representations.

    I claim that the quoted statement is incorrect because while the given node can have multiple parents, because the current node may belong to multiple hierarchies, there should be no concern for hierarchies that the parent belongs to that the current node does not belong to.

    The following example will show why this is doubly and actually triply specified and also why it is essential that the changes described in 1-3 above are needed.

    Consider 3 hierarchies:
    • /a1/b1/c1
    • /a2/b2/c2
    • /a3/b3/c3
    Let's say that a1, a2, and a3 are distinct roots and represent 3 separate nodes (or resources) in the overall collection.

    However, let us also say that b1 is a node that belongs to all 3 hierarchies and that, in fact, /a1/b1, /a2/b2, and /a3/b3 all represent normative identities of the same node.

    Now let us further assume that c1 and c2 represent the same physical node, but that c3 is a different node.

    Let's also assume that these physical nodes have serial numbers r*, which serve as alternate unique identifiers of the nodes. We can then see the relation as follows:
    • Let r1, r2, r3 be serial numbers of the 3 separate root nodes.
    • Let r4 be the serial number of the b1,b2,b3 node.
    • Let r5 be the serial number of the c1,c2 node.
    • Let r6 be the serial number of the c3 node.
    The logical and physical resources and hierarchies can now be represented together as follows:
    • /a1(r1)/b1(r4)/c1(r5)
    • /a2(r2)/b2(r4)/c2(r5)
    • /a3(r3)/b3(r4)/c3(r6)
    From the above, it is clear that if we are requesting access to, say node /a1/b1/c1, then to apply the rules quoted above for parents, we would need to first include:
    • /a1(r1)/b1(r4)/c1(r5)
    • /a2(r2)/b2(r4)/c2(r5)
    where the 2 parents of c1(r5) are
    • /a1/b1
    • /a2/b2
    i.e. c1, which is r5, which is then also c2, effectively has these 2 parents.

    However, the rule then requires us to collect all the normative identities of each of the parents.

    First of all in this case the parent rule requires us to collect the normative identities of r4 twice, once in its a1/b1 incarnation at which point it also picks up a2/b2, and once in its a2/b2 incarnation, where it picks up a1/b1 again. Therefore it is already "over-specified" because it requires collecting these identities twice resulting in 4 instead of 2 "normative parent identities".

    Furthermore, the algorithm also requires us to pick up /a3/b3, which is another "normative identity" of this parent node, which means we will have 3 copies of each normative identity of the "parents" of c1 for a total of 9 "normative parent identities", which are, of course triply redundant.

    In fact, we really only need /a1/b1 and /a2/b2 since r5 does not belong to the /a3/b3 hierarchy.

    Therefore this algorithm needs at least 2 corrections:
    1. Correct it so that it only includes one copy of each normative identity of each parent.
    2. Correct it so that it does not include normative identities of the parent which are part of hierarchies to which it does not belong, since policies on those hierarchies can have no bearing on this node because the normative representations within those hierarchies cannot refer to this node because it does not have a normative representation in those hierarchies to which it does not belong.
    Comments and suggestions are welcome. I will wait for feedback on emails and discussion at the next TC meeting before proceeding with the recommended changes.

        Thanks,
        Rich






    Rich.Levinson wrote:
    496F6636.9010801@oracle.com" type="cite">


  • 7.  Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent

    Posted 02-17-2009 00:57
    Based on this situation, my proposal is to enhance the existing Hierarchical spec using the URI representation in section 3.2 and indicating that this approach can be used instead of resource-parent and ancestor when the hierarchies are represented by nodes with URI resource-ids.

    Using URI is a very limited approach, and it can be trivially mapped into "ancestor" approach.    Requiring a unique URI for resources is often not feasible

    The following example will show why this is doubly and actually triply specified and also why it is essential that the changes described in 1-3 above are needed.

    Consider 3 hierarchies:
    • /a1/b1/c1
    • /a2/b2/c2
    • /a3/b3/c3
    Let's say that a1, a2, and a3 are distinct roots and represent 3 separate nodes (or resources) in the overall collection.

    I think you are confusing physical resources and policy resources.    Such mapping is outside of XACML.    There is no real hierarchy in XACML, we just provide a convenient normative way to represent them - only for the purpose of using it in a policy target.

    For the purpose of a single policy evaluation hierarchy that is used is uniquely defined by the provided "resource-ancestors" attribute.   The fact that there is some persistent identity that may participate in different hierarchies should be outside of the scope of this profile.

    Daniel;




  • 8.  Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent

    Posted 02-17-2009 01:41
    
    
      
    
    
    Hi Daniel,

    See replies inline:

    Daniel Engovatov wrote:
    daniel@streamdynamics.com,0E0925E7-45E3-468F-B4FF-08BC9" type="cite">
    Based on this situation, my proposal is to enhance the existing Hierarchical spec using the URI representation in section 3.2 and indicating that this approach can be used instead of resource-parent and ancestor when the hierarchies are represented by nodes with URI resource-ids.

    Using URI is a very limited approach, and it can be trivially mapped into "ancestor" approach.    Requiring a unique URI for resources is often not feasible
    I am not recommending removing or replacing what is there, but simply representing the URI approach and the manner in which it can be used in parallel. When the URI is present, there is no need to create the ancestors, and one may simply use the anyURI-regexp-match as specified in section 4.3 (which I notice now needs to be updated to be consistent w core). Also, as stands, 4.3 really should have corresponding description in 3.2, which it currently does not.
    I am not recommending requiring URI, but only making it available when convenient, which I think includes quite a broad range of use cases and I would not characterize it as "very limited" despite the fact that it may not be "universally applied".
    My objectives are usability of the policy language. Scoping based on URI  regular expression matching is a universal technique, which is much easier than parsing URIs into parents and ancestors and then using XPath-type referencing, which is the approach indicated by Erik's example.
    As you and others have indicated in the 2004 emails, there are use cases where URI is not readily available or desired, and the mechanisms from XPath are very useful there and I have no intention to remove them, but only to "correct" them, if need be, as indicated by the example I included in prev email.
    daniel@streamdynamics.com,0E0925E7-45E3-468F-B4FF-08BC9" type="cite">
    The following example will show why this is doubly and actually triply specified and also why it is essential that the changes described in 1-3 above are needed.

    Consider 3 hierarchies:
    /a1/b1/c1
    /a2/b2/c2
    /a3/b3/c3
    Let's say that a1, a2, and a3 are distinct roots and represent 3 separate nodes (or resources) in the overall collection.

    I think you are confusing physical resources and policy resources.    Such mapping is outside of XACML.    There is no real hierarchy in XACML, we just provide a convenient normative way to represent them - only for the purpose of using it in a policy target.
    I do not believe I am confusing the two. Physical resources are a fact of existence and in the case of XACML, the hierarchical identifiers are simply labels that the managers of those resources have applied to them. In the example I gave, it is the r* that represent the physical labels on the physical resources. They are an unordered flat collection. All the /a*/b*/c* are hierarchical representations of subsets of those resources. A given instance of "*" represents one hierarchy that is mapped onto the physical resources. All the policies deal with are the hierarchical representations. The physical is only mentioned to give people some context for understanding what is being discussed.
    For example, all the PCs in a company have serial numbers. When managers create policies, they have the physical resources in mind and may organize them hierarchically for various purposes. A department manager may label the PCs in his/her dept according to some hierarchical structure in the dept organization and assign policies accordingly. At the same time these PCs are company property and may be labeled independently by the IT dept in terms of who is responsible for maintenance on them.

    If someone wants to take one of these PCs out of the building, maybe there is a policy that says even if the employee's manager says it is ok, the facilities manager must also approve before permission is granted. This can be modeled with a dept hierarchy and a facilities hierarchy, and there are rules within the hierarchy producing a result and policy combining between the 2 hierarchies that can resolve conflicts such as described above.

    In the above example the /a1/b1/c1 might be the dept hierarchy and /a2/b2/c2 might be the facilities hierarchy.
    daniel@streamdynamics.com,0E0925E7-45E3-468F-B4FF-08BC9" type="cite">
    For the purpose of a single policy evaluation hierarchy that is used is uniquely defined by the provided "resource-ancestors" attribute.  
    It is also uniquely defined by a URI if a URI scheme has been applied to the same resources, since all the ancestors are readily identifiable within the URI.
    daniel@streamdynamics.com,0E0925E7-45E3-468F-B4FF-08BC9" type="cite">The fact that there is some persistent identity that may participate in different hierarchies should be outside of the scope of this profile.
    As indicated above and original email, the r* persistent identity is only used as contextual reference for humans to know what is being discussed. Within the policies themselves, there would generally be no need to include this attribute except possibly for reporting purposes.

        Thanks,
        Rich
    daniel@streamdynamics.com,0E0925E7-45E3-468F-B4FF-08BC9" type="cite">
    Daniel;





  • 9.  Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent

    Posted 02-17-2009 02:00
    > For example, all the PCs in a company have serial numbers. When  
    > managers create policies, they have the physical resources in mind  
    > and may organize them hierarchically for various purposes. A  
    > department manager may label the PCs in his/her dept according to  
    > some hierarchical structure in the dept organization and assign  
    > policies accordingly. At the same time these PCs are company  
    > property and may be labeled independently by the IT dept in terms  
    > of who is responsible for maintenance on them.
    >
    > If someone wants to take one of these PCs out of the building,  
    > maybe there is a policy that says even if the employee's manager  
    > says it is ok, the facilities manager must also approve before  
    > permission is granted. This can be modeled with a dept hierarchy  
    > and a facilities hierarchy, and there are rules within the  
    > hierarchy producing a result and policy combining between the 2  
    > hierarchies that can resolve conflicts such as described above.
    >
    > In the above example the /a1/b1/c1 might be the dept hierarchy and / 
    > a2/b2/c2 might be the facilities hierarchy.
    
    There is no need for separate hierarchies here if the "remove from  
    building" is a single access decision.  In your example, let's "PC"  
    be a resource, "DEPT" be a department, and "FACILITIES" be  
    facilities.     In this case resource-ancestors will be {"PC",  
    "DEPT", "FACILITIES"}    (or {"a1", "a2", "b1", "b2", "c"} )  There  
    is no need for two hierarchies.   That is the advantage of not being  
    pidgeonholed into a single inheritance URI-like scheme.
    
    > It is also uniquely defined by a URI if a URI scheme has been  
    > applied to the same resources, since all the ancestors are readily  
    > identifiable within the URI.
    
    That's a bit of a contorted way to represent a simple bag of strings.
    
    >  Within the policies themselves, there would generally be no need  
    > to include this attribute except possibly for reporting purposes.
    
    Then what exactly is the problem?   Policy, as specified, can be  
    evaluated deterministically.   The mapping of physical entities into  
    policy resources is outside of the scope of this profile.   I do not  
    see anything broken here.
    
    Daniel;
    


  • 10.  Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent

    Posted 02-17-2009 04:06
    
    
      
    
    
    Hi Daniel,

    I am not sure exactly what you are driving at here, but I include comments below:

    Daniel Engovatov wrote:
    daniel@streamdynamics.com,4BD684A8-1AF9-4E23-AB83-0EB76" type="cite">
    For example, all the PCs in a company have serial numbers. When managers create policies, they have the physical resources in mind and may organize them hierarchically for various purposes. A department manager may label the PCs in his/her dept according to some hierarchical structure in the dept organization and assign policies accordingly. At the same time these PCs are company property and may be labeled independently by the IT dept in terms of who is responsible for maintenance on them.

    If someone wants to take one of these PCs out of the building, maybe there is a policy that says even if the employee's manager says it is ok, the facilities manager must also approve before permission is granted. This can be modeled with a dept hierarchy and a facilities hierarchy, and there are rules within the hierarchy producing a result and policy combining between the 2 hierarchies that can resolve conflicts such as described above.

    In the above example the /a1/b1/c1 might be the dept hierarchy and /a2/b2/c2 might be the facilities hierarchy.

    There is no need for separate hierarchies here if the "remove from building" is a single access decision.  In your example, let's "PC" be a resource, "DEPT" be a department, and "FACILITIES" be facilities.     In this case resource-ancestors will be {"PC", "DEPT", "FACILITIES"}    (or {"a1", "a2", "b1", "b2", "c"} )  There is no need for two hierarchies.   That is the advantage of not being pidgeonholed into a single inheritance URI-like scheme.
    The hypothetical scenario I am describing is based on two sub-organizations within a larger organization which operate independently on the same set of physical resources. In general, the operations are independent, but in some cases there is need for both organizations to be brought into some kinds of decision. The dept manager has set up a hierarchy for controlling the PCs in his department, while the facilities manager has set up an independent hierarchy on the same set of PCs for controlling the maintenance on those PCs from within the facilities organization.

    The parent organization recognizes that there may be situations where the decisions of the two organizations may come into conflict and have set up combining algorithms above the two hierarchies to resolve differences.

    From what you are saying, and I do not follow your example, it sounds like it is possible to restructure the existing hierarchies into a new framework where somehow the existing hierarchies no longer need to exist. This may be useful as an academic exercise, but operationally, one would need to educate the company, the facilities and the department about this new uniform paradigm and explain to the people involved why they no longer need the hierarchical representations.

    However, I do not understand precisely what you are recommending:
    1. I do not understand how {"PC", "DEPT", "FACILITIES"} relates to the scenario I have described. I have specific PCs, in the example they have serial numbers r5, r6. One of these PCs, r5, is identified in the "dept" as /a1/b1/c1. In the facilities org the same pc is identified as /a2/b2/c2.
    2. The ancestor nodes of /a1/b1/c1 and /a2/b2/c2 are the same, namely {/a1, /a1/b1, /a2, /a2/b2}. I do not see how you can say {"a1", "a2", "b1", "b2", "c"}. "c" is not one of the terms. "a2" and "b2" by themselves are not normative identities.
    daniel@streamdynamics.com,4BD684A8-1AF9-4E23-AB83-0EB76" type="cite">
    It is also uniquely defined by a URI if a URI scheme has been applied to the same resources, since all the ancestors are readily identifiable within the URI.

    That's a bit of a contorted way to represent a simple bag of strings.
    URIs do not represent bags of strings. Possibly one might choose to represent a URI as a bag of strings, however, one loses the ordering in the process. If one wants to identify the specific set of nodes represented by a URI, it is a simple matter to sequentially strip one component at a time off the URI, and at each step one has the normative identity of the next node up the chain until one reaches the root.
    daniel@streamdynamics.com,4BD684A8-1AF9-4E23-AB83-0EB76" type="cite">
     Within the policies themselves, there would generally be no need to include this attribute except possibly for reporting purposes.

    Then what exactly is the problem?   Policy, as specified, can be evaluated deterministically.   The mapping of physical entities into policy resources is outside of the scope of this profile.   I do not see anything broken here.
    I was addressing the statement you made that you thought I had a problem confusing the physical and policy resources. I was showing that the physical mapping was simply an orthogonal property of the node which of necessity must include an identity for each of its purposes, in this case: one for the dept, one for the facilities, and one for the physical identifier. However, for policies, the physical identifier need not be used and may be regarded as a resource attribute on the node entity outside of the policy structures, but available to be included if necessary.

    At this point I fail to understand the purpose of specifically not using a hierarchical naming scheme in order to identify a set of resources that will be managed as a hierarchy. I understand that there may be cases where for some reason it may not be possible or practical to use such a naming scheme, but in those cases where it is possible and practical, I do not understand why it would not be a good idea to use it.

        Thanks,
        Rich

    daniel@streamdynamics.com,4BD684A8-1AF9-4E23-AB83-0EB76" type="cite">

    Daniel;


  • 11.  Re: [xacml] Issue: Hierarchical profile app