OASIS eXtensible Access Control Markup Language (XACML) TC

  • 1.  Example of dag and forest used to manage collection of resourcesfor comparison

    Posted 02-26-2009 19:22
    
    
    
    
    Hi All,

    At this week's tc meeting, when we discussed the proposed changes to the Hierarchical Resource Profile,
    http://lists.oasis-open.org/archives/xacml/200902/msg00056.html
    I was asked to provide an example distinguishing the dag and forest so people could easier understand the core of the issue and impact on things in general.

    It consists of:
    • some assumptions about a real world situation within which we will use to frame the concepts
    • a problem statement
    • a manual data collection process during which multiple sources of authority define hierarchies associated with a common set of resources
    • a hypothetical "resource manager program", which can manage the data as a dag or a forest and we will consider the implications
    • some concluding remarks
    Assumptions:
    1. There is a flat collection of resources, which can be anything, records in a database, people, or for the sake of concreteness, let's consider a bunch of large physical metal containers in a storage area or warehouse near a shipping port. The problem to consider is the management of these containers and the customers that use them. Each container has a large painted alphanumeric identifier on it, such as "AT12345XY", with no other properties except there are no duplicates. The containers are very large and typically can be used to provide storage for more than one customer.
    2. We can draw a picture of these containers as a collection of boxes on a piece of paper, the point being, that we are going to model the management of these containers as a forest and a dag and use this drawing to conceptualize the problem and the forest and dag solutions.
    3. Let us assume that there are two interested customers in these containers, and that they each have their own uses for the containers and have their own labels for the containers and that for what ever reason, they each choose to organize the containers as a single rooted hierarchy.
    Problem statement:
    • Design a "resource manager" for these containers and the 2 customers so that the hierarchy each customer specifies is used to initially establish the hierarchical relationship each customer has requested among the containers the customer chooses to use.
    Manual data collection process to follow:
    1. As Hal suggested at the TC meeting, let's assume we have all the containers drawn as boxes on a piece of paper, which shows all the boxes, each with a serial number in the upper left corner of an otherwise blank box.
    2. Now each customer will have their own sheet and in their own separate color draw their own hierarchy on the sheet, which will show a top node and then children nodes recursively, for whatever boxes they choose to be in their collection. In addition to showing the hierarchical lines connecting their boxes, each customer may pick their own "name" for each box, or they can leave it blank and we will use the serial number instead when the data is entered.The only requirement on the customer-specific names is that they be unique on the sheet. It does not matter what any other customer defines on another sheet. If the customer is lazy or simply does not want to think up names, that is ok, because we will be able to use the serial numbers instead.
    3. When the 2 customers are done they will hand in their sheets to the "guy" who runs the warehouse and he will enter the data from the sheets into the resource manager program on his laptop.
    The "hypothetical" resource manager program:
    1. Assume the program is a little database, and that an initial database has been set up that has one row for each container, and it has a primary key with serial number of container in column zero.
    2. Collect information for both the dag:and the forest:
    3. Enter the data for one sheet at a time, i.e. for each sheet, i:
      • find the top of the customer hierarchy (from the customer drawn diagram, pick the serial number in the box at the top of the customer drawn hierarchy) and
      • enter the customer specified name as the 2i-1st column value after the box serial number of the row with identifier equal to serial number of box on sheet of paper, for which, by definition, exists in the initial "empty" database (a list of all the available boxes) (if no customer-specified name supplied, put a copy of the row's serial number in instead)
      • for each child (iteratively until all entries processed):
        • enter the customer specified name as the 2i-1st column value after the serial number of the row with identifier equal to serial number of box on sheet of paper (if no customer-specified name supplied, put a copy of the row's serial number in instead)
        • enter the name of the parent node as the 2ith column value in the same row
    4. When step 3 is complete, we should have all customer 1's boxes with their customer-selected id in columns 1 and the parent customer-selected name in column 2. And for customer 2's boxes we will have the same information in columns 3 and 4.
    5. This process can be repeated indefinitely for any number of customers, and each customer can choose any subset of boxes with any specific box as the top of the customer specific hierarchy, recognizable by the fact that it is the only entry that does not have a parent value in the 2ith column.
    6. At this point the situation is set up completely so the forest resource manager or the dag resource manager can begin operation.
    Concluding remarks:

    So, what is the difference between the forest and dag?

    The following explanation is my interpretation of the data structures of forest and dag, and my analysis of the comparison to follow may not be correct, in which case I am more than happy to have someone explain what would be correct. However, if it is correct, I think it will clearly demonstrate why I have considered this issue to have the "severity" I have attributed to it (and why there has been this whole sequence of emails and proposed revs to the spec).

    The difference, as I see it, is:
    • For the forest, the job is done. The forest resource manager can add new customers, remove customers by clearing out their 2 columns and freeing them up for a new customer.

    • For the dag, the there is an "optimization" that can now be made. The dag resource manager notices that there are many empty pairs of cells in the table representing boxes that the current customer in each column is not using. Therefore this data can be "compressed" so that all rows only use the number of columns times two for which a customer actually has a box in use.
    As is well known, for every optimization there is usually a cost. The cost of this optimization,as described, and if accurate representation of info missing from dag, is that the ability to define a specific customer's set of boxes could previously be done just by finding the customer's named root node, then all the non-blank boxes in that column belonged to the customer. With this "optimization" the association of customer to column is destroyed and that information is either no longer available or has to be obtained by other means.

    Bottom line: again as I see it, this is the problem with the person who was the xacml-commenter referenced in earlier emails who was seeking advice, presumbably guided by the spec in its current form to dismantle their URIs. To me, this appears as if they are basically destroying information that they had already established as a sunk cost, and constraining themselves to work within the more limited framework that the lesser information provides.

    Comments welcome.

        Thanks,
        Rich


  • 2.  Re: [xacml] Example of dag and forest used to manage collection of resources for comparison

    Posted 02-26-2009 20:32
     


    Bottom line: again as I see it, this is the problem with the person who was the xacml-commenter referenced in earlier emails who was seeking advice, presumbably guided by the spec in its current form to dismantle their URIs. To me, this appears as if they are basically destroying information that they had already established as a sunk cost, and constraining themselves to work within the more limited framework that the lesser information provides.


    This assumption is incorrect.  There is no need to construct any URI in the first place.

    This whole overly complicated example demonstrates that XACML should not be involved in any form of resource ontology management.  It is based on wrong and completely unjustified assumption about what hierarchy means for the purpose of policy evaluation.     From the point of view of PDP, there is only one hierarchy.  There is only one "customer" at a time.  All we need to do is to specify is a protocol to transmit this information to PDP.    That is completely sufficient.   DAG accomplishes that.   Everything else is completely extraneous, not needed, and none of our business.    We should clarify the existing specification about the use of opaque unique identifiers, remove any references to URI's for the non-XML case, and leave it at that.  It works, and works correctly.

    Daniel;




  • 3.  Re: [xacml] Example of dag and forest used to manage collection ofresources for comparison

    Posted 02-26-2009 22:19
    
    
      
    
    
    Hi Daniel and TC,

    I am disappointed that this response does not directly address the example. I consider it to be a very reasonable example. One such use case would be a "farm" of sharable computers, and two applications, each organized as a hierarchy of modules, that the appl deployer configures on different machines, possibly because those machines have resources needed by specific application modules.

    Also, it is not an "overly complicated example". It is as simple as 2 sheets of paper with numbered boxes that are each filled in by a different person with a different purpose for using the shared resources.

    Each person may want to make the contents of those boxes (physical or logical) available only to certain members of that person's organization and allocates access to the boxes within organization's own hierarchical framework (which is all contained in the two columns allocated to the customer by the parent attribute associated with each customer-specified node name).

    This is typical enterprise use case with many large distributed applications over world-wide corporate resources. Each application needs to be managed independently of other applications, yet at the same time must share the common corporate resources on which it is run.

    Finally, I want to emphasize one more time: I have not advocated removing any of the DAG functionality that already exists in the spec. If you carefully read the proposed modified spec, I think you will see it is functionally unchanged. The changes are only to distinguish the DAG from the forest and to fill in the missing information to show how the forest can be used, if one chooses to do so.

    Both the forest and URI capabilities (URI is concrete representation of more general forest) have been in the spec since the beginning, long before I had any working involvement with the XACML specifications. There are many obvious use cases for forest and URI, such as the ones I have mentioned and, at a minimum, cases where an investment has already been made and URIs already exist and the customer has no interest in changing them.

    The example I have given demonstrates the distinction of information content between the forest and the DAG, namely that the forest, as a set of disjoint trees, one way or another contains the hierarchical relationship of the collection of resources within each disjoint tree, as well as the relationships to the other trees when the trees are mapped on the common resources to be organized.

    The DAG specifically does not need to keep whatever structures are used to keep the original trees disjoint, and similarly has no capabilities for recovering any information about the original disjoint properties of its current members unless it happens to have kept this information around. That is why the DAG leads one to dismantle URIs, because there is no need to maintain the order of the components. That is analogous to the row compression in the example I gave.

    For application use cases where the URI structure or the example row structure is not needed, then DAG is a perfectly good solution.

    However, the use cases in enterprise security quite often are geared around independent hierarchical lines of authority for which it is very important to maintain knowledge of precisely where this authority is coming from.

    The change to the spec leaves the DAG capabilities unchanged and available for use. The change also explicitly distinguishes DAG and forest and fills in section 3.2, which currently only contains DAG information and is missing the comparable forest information.

    The main difference between DAG and forest is that DAG can be used  to "merge" hierarchies into a single uniform structure which has no memory of the original hierarchies. The forest "aggregates" hierarchies into a single uniform structure that does have memory of the original hierarchies and the capability of maintaining that info thru adds moves and changes.
    The example shows a concrete instance of this forest implementation and the changes that can be made to transform it into a DAG, which is essentially the same structure minus the original hierarchy mechanism, which was to maintain a customer as two columns.
    The "forest", applied to resources, is in common use today under the term "polyarchy". Since the XACML Hierarchical Resource Profile already has this capability, I see no reason to suppress or remove it, but consider it a strength of XACML that it currently does support it and that it can be used if properly explained in the specification, which is the purpose of these proposed changes.

        Thanks,
        Rich


    Daniel Engovatov wrote:
    daniel@streamdynamics.com,03B729EB-77CF-4C70-A78A-0AFC2" type="cite">


    Bottom line: again as I see it, this is the problem with the person who was the xacml-commenter referenced in earlier emails who was seeking advice, presumbably guided by the spec in its current form to dismantle their URIs. To me, this appears as if they are basically destroying information that they had already established as a sunk cost, and constraining themselves to work within the more limited framework that the lesser information provides.


    This assumption is incorrect.  There is no need to construct any URI in the first place.

    This whole overly complicated example demonstrates that XACML should not be involved in any form of resource ontology management.  It is based on wrong and completely unjustified assumption about what hierarchy means for the purpose of policy evaluation.     From the point of view of PDP, there is only one hierarchy.  There is only one "customer" at a time.  All we need to do is to specify is a protocol to transmit this information to PDP.    That is completely sufficient.   DAG accomplishes that.   Everything else is completely extraneous, not needed, and none of our business.    We should clarify the existing specification about the use of opaque unique identifiers, remove any references to URI's for the non-XML case, and leave it at that.  It works, and works correctly.

    Daniel;





  • 4.  Re: [xacml] Example of dag and forest used to manage collection of resources for comparison

    Posted 02-26-2009 22:34
    On Feb 26, 2009, at 2:18 PM, Rich.Levinson wrote:
    
    > Hi Daniel and TC,
    >
    > I am disappointed that this response does not directly address the  
    > example. I consider it to be a very reasonable example. One such  
    > use case would be a "farm" of sharable computers, and two  
    > applications, each organized as a hierarchy of modules, that the  
    > appl deployer configures on different machines, possibly because  
    > those machines have resources needed by specific application modules.
    >
    
    I did address the example.   I have said that managing a "farm of  
    sharable computers", or anything else of that nature should not be a  
    part of XACML.   There is a multitude of possible structures that we  
    could possibly address, but trying to standardize them is a folly.   
    It should be left to an industry/vendor/domain specific profiles.
    
    The only thing that matters for a simple, core hierarchical rules  
    management system is an ability to specify a rule that apply to  
    "descendants" of a resource and an ability to specify what resources  
    are "descendants".
    
    > This is typical enterprise use case with many large distributed  
    > applications over world-wide corporate resources. Each application  
    > needs to be managed independently of other applications, yet at the  
    > same time must share the common corporate resources on which it is  
    > run.
    >
    
    That is one of a myriad of possible such resource ontologies.    All  
    of them can be mapped into a simple attribute based scheme that is  
    needed to apply hierarchical rules.
    
    
    > Finally, I want to emphasize one more time: I have not advocated  
    > removing any of the DAG functionality that already exists in the  
    > spec. If you carefully read the proposed modified spec, I think you  
    > will see it is functionally unchanged. The changes are only to  
    > distinguish the DAG from the forest and to fill in the missing  
    > information to show how the forest can be used, if one chooses to  
    > do so.
    >
    
    I am glad that you do not advocate removing DAG.    I am voicing my  
    opinion about adding anything else.   There is no need for that and  
    it brings complexity.
    
    > The main difference between DAG and forest is that DAG can be used   
    > to "merge" hierarchies into a single uniform structure which has no  
    > memory of the original hierarchies. The forest "aggregates"  
    > hierarchies into a single uniform structure that does have memory  
    > of the original hierarchies and the capability of maintaining that  
    > info thru adds moves and changes.
    >
     From the point of view of PDP there are no hierarchies to merge.    
    There is one hierarchy at a time that is pertinent to an  
    evaluation.   Merging etc. is to be handled by an external system.
    
    
    Daniel;
    
    


  • 5.  Re: [xacml] Example of dag and forest used to manage collection ofresources for comparison

    Posted 02-27-2009 00:23
    
    
      
    
    
    Hi Daniel and TC,

    Some of these appear to be repeat criticisms from previous discussions that I thought were addressed in previous emails, but will try again to clarify, so TC members have context for evaluating situation.

    All the concrete examples, such as a "farm of computers" or a "warehouse of boxes" are not attempts to standardize anything. They are simply examples, which some people find useful to understand the abstract concepts in the specifications. I am well aware that some people find these kinds of examples useful and some don't. Personally, I find them useful, and find that some people who I explain things to also find useful. Also, it is a very common practice to explain by example, so I do not understand the issue here.

    Simply saying
    "managing a "farm of sharable computers", or anything else of that nature should not be a part of XACML"
    does not appear to me to be addressing the example, but simply making a statement that the example should not be a part of XACML. Since the example was only used to explain an aspect of the XACML Hierarchical Profile, and was not intended to be put in the profile, but only help the TC members understand what the purpose of the proposed changes are in the profile, the statement appears to me not to be in conflict with what was said in the original email, nor does it appear to take issue with the example itself on any of the particulars.

    On your second point:
    "The only thing that matters for a simple, core hierarchical rules management system is an ability to specify a rule that apply to "descendants" of a resource and an ability to specify what resources are "descendants". "
    Again, in principle, I don't think we have a disagreement here. The DAG and the forest define two different sets of descendants. The forest defines only "direct" descendants from the original hierarchies. The DAG defines only "direct" descendants from the merged hierarchy. Previous emails have explained the details of the differences, but for many people the key fact is that the original hierarchy is changed by the DAG. Users who want to maintain the original hierarchies will not be able to use the DAG for this, but they will be able to use the forest. Furthermore, any structure that can be created with a DAG can also be created in the forest. Therefore, the DAG members can be obtained from the forest "simply" by directing the forest manager to collect all nodes that are descendants of ancestors whether direct or not. Obviously forest is not optimized for this type of operation, but information is available if needed.


    The notion that you have suggested in this email and some of the previous emails,
    "That is one of a myriad of possible such resource ontologies.    All of them can be mapped into a simple attribute based scheme that is needed to apply hierarchical rules."
    I still have interest in and would like to see a clearly defined example so that I might understand the DAG use cases better and if they have broader application capabilities then is currently apparent to me.

    However, for those use cases, such as have been described explicitly and generally, where the DAG has no capabilities, the critical factor is that there is no DAG capability to maintain multiple hierarchies that retain the original lines of authority without spreading that authority to additional unintended entities. As a result, any particular resource in a DAG will be subject to policies from direct ancestors and indirect ancestors as well with no way to distinguish them. Without this capability, other capabilities are not a factor, because the DAG will not meet the requirements.

    For the forest, the capability to maintain the original lines of authority is built-in. The capability to obtain, what we might call the additional lines of "influence" is also available as is the ability to distinguish each from the other.  For applications that only require "influence + direct", then DAG is appropriate. When there is a requirement to maintain "direct lines of authority only" then DAG will not meet the requirement, and one has the option in the spec, then, of choosing forest.

    This next point still keeps coming up and still I must address it because it does not represent what the proposal is:
    "I am glad that you do not advocate removing DAG.    I am voicing my opinion about adding anything else.   There is no need for that and it brings complexity. "
    This statement creates the impression that the "forest" capability is being "added". It is not. It is already there and has been there since the spec was first released. However the capability has not been properly explained and it is difficult for me to see how anyone could discern between the two very distinct characteristics of the DAG and forest from the current spec. Since there are many application that require the forest and not the DAG, the purpose of the clarifications in the spec is to enable readers to understand the distinction and select what they need appropriately.

    What currently exists in the spec is "complexity" because these two concepts are intertwined in a manner that one cannot see the difference between disjoint and merged trees and if one is interested in disjoint trees then there is tremendous complexity figuring out how to use the spec for this purpose. The proposed changes simplify the spec by disambiguating the two concepts and enabling the user of the spec to have a clear choice.

    The final statement also mixes up the capabilities:
    "From the point of view of PDP there are no hierarchies to merge.   There is one hierarchy at a time that is pertinent to an evaluation.   Merging etc. is to be handled by an external system. "
    It is correct that the PDP does not merge hierarchies, nor does anything in the proposed changes suggest that does.

    It is the DAG content handler that merges hierarchies by applying the ancestor collection algorithms in section 3.2 to the resource collection data before it submits the request to the PDP. These algorithms explicitly collect ancestors that are not direct ancestors of the requested node, because they make the assumption that the information distinguishing between the two kinds of ancestors is not available, which in itself is an assumption about the external systems that cannot objectively be made.

    The example given in earlier email shows exactly the kinds of external systems that exist and shows that the information is generally available if it is of potential use. The assumption in the 3.2 algorithms is that there is no distinguishing information externally to distinguish between direct and indirect ancestors. This is, in general, a false assumption. One should be free to implement context handlers that have any capabilities necessary to meet the needs of the policy designers who use the PDP.

    In the example given, one would have the choice of the "forest resource manager" or the "DAG resource manager". If the enterprise wanted to maintain "disjoint, but overlapping" lines of authority, then they could deploy a "forest resource manager". If they wanted "merged" lines of authority, they could deploy a "DAG resource manager".

    I expect, in principle, if they wanted a mix of both, disjoint for some policies, and merged for other policies, there are probably enterprise design strategies where the PEP in initial request could be configured to trigger one or the other type of ancestor collection by the context handler, which is the point of specifying the "forest" identifier for the URIs in section 2.2 and the functions in 3.2. If context handler needs to gather only direct ancestors, or if it is all URIs not gather any ancestors, or if is DAG gather all ancestors, then contexthandler can make that choice based on identifiers in request.

        Thanks,
        Rich


    Daniel Engovatov wrote:
    daniel@streamdynamics.com,EF3F8695-6BA4-400F-A2A4-C5725" type="cite">
    On Feb 26, 2009, at 2:18 PM, Rich.Levinson wrote:

    Hi Daniel and TC,

    I am disappointed that this response does not directly address the example. I consider it to be a very reasonable example. One such use case would be a "farm" of sharable computers, and two applications, each organized as a hierarchy of modules, that the appl deployer configures on different machines, possibly because those machines have resources needed by specific application modules.


    I did address the example.   I have said that managing a "farm of sharable computers", or anything else of that nature should not be a part of XACML.   There is a multitude of possible structures that we could possibly address, but trying to standardize them is a folly.  It should be left to an industry/vendor/domain specific profiles.

    The only thing that matters for a simple, core hierarchical rules management system is an ability to specify a rule that apply to "descendants" of a resource and an ability to specify what resources are "descendants".

    This is typical enterprise use case with many large distributed applications over world-wide corporate resources. Each application needs to be managed independently of other applications, yet at the same time must share the common corporate resources on which it is run.


    That is one of a myriad of possible such resource ontologies.    All of them can be mapped into a simple attribute based scheme that is needed to apply hierarchical rules.


    Finally, I want to emphasize one more time: I have not advocated removing any of the DAG functionality that already exists in the spec. If you carefully read the proposed modified spec, I think you will see it is functionally unchanged. The changes are only to distinguish the DAG from the forest and to fill in the missing information to show how the forest can be used, if one chooses to do so.


    I am glad that you do not advocate removing DAG.    I am voicing my opinion about adding anything else.   There is no need for that and it brings complexity.

    The main difference between DAG and forest is that DAG can be used  to "merge" hierarchies into a single uniform structure which has no memory of the original hierarchies. The forest "aggregates" hierarchies into a single uniform structure that does have memory of the original hierarchies and the capability of maintaining that info thru adds moves and changes.

    From the point of view of PDP there are no hierarchies to merge.   There is one hierarchy at a time that is pertinent to an evaluation.   Merging etc. is to be handled by an external system.


    Daniel;



  • 6.  RE: [xacml] Example of dag and forest used to manage collectionof resources for comparison

    Posted 03-03-2009 17:08
    
    
    
    
    


  • 7.  Re: [xacml] Example of dag and forest used to manage collection of resources for comparison

    Posted 03-03-2009 20:26



    It all should be very simple.    There is a set of rules.  Each rule has a resource identifier in its target (written as to apply to all descendants) For each evaluation one wants to include a finite set of applicable rules.
    Resource identifiers from the applicable rules are included into the "ancestors" attribute.   It is always possible to define this set.

    That is it.   There are no multiple red green or blue "hierarchies" that XACML should be concerned about.  It is up to a concrete system to define the exact mapping.    For example, one system may want to model all resources as a tree, but restrict the inheritance to be only three levels deep.   Another system may maintain multiple hierarchies and use different depending on the time of day.  It does not matter.  They can always be presented in an "ancestor" attribute form that allows PDP to evaluate the intended policy.

    Daniel;



  • 8.  Re: [xacml] Example of dag and forest used to manage collection ofresources for comparison

    Posted 03-04-2009 03:12
    Hi Hal,
    
    Let me try to quickly address the points you raise. If there is 
    insufficient detail, I will be happy to provide, but will try to keep 
    short for clarity inline:
    
    Hal Lockhart wrote:
    > I am sorry Rich, I cannot make any sense out of this example. Let me try to explain what I thought last week was the distinction you were trying to make.
    >   
    Ok, I still think it is simplest representation of issues that have been 
    discussed, but will follow your example here.
    >  
    >
    > First, my reading of the non-xml hierarchical profile says that the key step is that the context handler must put in the context the following:
    >
    >  
    >
    > the id(s) of the resource
    >
    > the id(s) of the parent(s) of the resource
    >
    > the id(s) of the ancestor(s) of the resource
    >
    > the id(s) of the ancestor(s) or self of the resource
    >  
    >
    > we can ignore the last as it is by definition the union of the first and third.
    >
    >   
    Yes, they have already been added.
    >  
    >
    > My understanding was that the issue or DAG or Forest boiled down to the fact that in some cases, the DAG and forest approaches would yield different lists.
    >
    >   
    That is correct.
    >  
    >
    > Specifically, I thought that your point was that in the forest model, the resource would only have ancestors that were in the one of the hierarchies which the resource belongs to. Whereas in the DAG, the resource could have ancestors which were not in the same hierarchy, but which were in a hierarchy with a parent or ancestor of the resource.
    >   
    That is also correct.
    >  
    >
    > Let me try to give an example of what I think you mean.
    >
    >  
    >
    > A resource R is a member of the red hierarchy which consists of its parent A and A's parent B.
    >
    >  
    >
    > B-A-R
    >
    >   
    Ok, let me add direction:   B->A->R
    >  
    >
    > R is also a member of the blue hierarchy which consists of parent X and X's parent Y.
    >
    >  
    >
    > Y-X-R
    >   
    OK,  Y->X->R
    >  
    >
    > R is not a member of the green hierarchy, but A is and so is A's parent Z.
    >
    >  
    >
    > Z-A
    >   
    OK, 3rd hierarchy, no problem: Z->A
    >  
    >
    > Now if I understand you, for Forest the list would be:
    >
    >  
    >
    > Resource: R
    >
    > Parents: A, X
    >
    > Ancestors: A, B, X, Y
    >
    >   
    Yes, I agree.
    >  
    >
    > However for DAG it would be:
    >
    >  
    >
    > Resource: R
    >
    > Parents: A, X
    >
    > Ancestors: A, B, X, Y, Z
    >
    >   
    Yes, I also agree.
    >  
    >
    > Please tell me if this is correct, or if not explain what you mean.
    >   
    At this point we appear to be "on same page". :)
    >
    >  
    >
    > If this is correct, as far as I can see, the difference will never be in the parents, only in non-parent ancestors.
    >
    >   
    Yes.
    >  
    >
    > Hal
    >   
    That's it? Ok, well the problem I see here is that if you go and collect 
    applicable policies for DAG, then if there is policy on Z it will be 
    applicable to R.
    
    It you are modeling "intersecting hierarchies" then this would be 
    incorrect for any use cases that require this model. For example company 
    departments on different floors of building. Policies associated with 
    floor 2 should not be applicable to descendants of department members on 
    floor 2 who are on other floors.
    
    However, if you are modeling "sub-assemblies" or "code-versioning" type 
    resource collections, then DAG might be more appropriate since it 
    automatically sweeps up subtrees as opposed to individual nodes.
    
        Thanks,
        Rich
    
    >  
    >
    > ________________________________
    >
    > From: Rich.Levinson [mailto:rich.levinson@oracle.com] 
    > Sent: Thursday, February 26, 2009 7:23 PM
    > To: Daniel Engovatov
    > Cc: xacml
    > Subject: Re: [xacml] Example of dag and forest used to manage collection of resources for comparison
    >
    >  
    >
    > Hi Daniel and TC,
    >
    > Some of these appear to be repeat criticisms from previous discussions that I thought were addressed in previous emails, but will try again to clarify, so TC members have context for evaluating situation.
    >
    > All the concrete examples, such as a "farm of computers" or a "warehouse of boxes" are not attempts to standardize anything. They are simply examples, which some people find useful to understand the abstract concepts in the specifications. I am well aware that some people find these kinds of examples useful and some don't. Personally, I find them useful, and find that some people who I explain things to also find useful. Also, it is a very common practice to explain by example, so I do not understand the issue here.
    >
    > Simply saying 
    >
    > "managing a "farm of sharable computers", or anything else of that nature should not be a part of XACML" 
    >
    > does not appear to me to be addressing the example, but simply making a statement that the example should not be a part of XACML. Since the example was only used to explain an aspect of the XACML Hierarchical Profile, and was not intended to be put in the profile, but only help the TC members understand what the purpose of the proposed changes are in the profile, the statement appears to me not to be in conflict with what was said in the original email, nor does it appear to take issue with the example itself on any of the particulars.
    >
    > On your second point:
    >
    > "The only thing that matters for a simple, core hierarchical rules management system is an ability to specify a rule that apply to "descendants" of a resource and an ability to specify what resources are "descendants". "
    >
    > Again, in principle, I don't think we have a disagreement here. The DAG and the forest define two different sets of descendants. The forest defines only "direct" descendants from the original hierarchies. The DAG defines only "direct" descendants from the merged hierarchy. Previous emails have explained the details of the differences, but for many people the key fact is that the original hierarchy is changed by the DAG. Users who want to maintain the original hierarchies will not be able to use the DAG for this, but they will be able to use the forest. Furthermore, any structure that can be created with a DAG can also be created in the forest. Therefore, the DAG members can be obtained from the forest "simply" by directing the forest manager to collect all nodes that are descendants of ancestors whether direct or not. Obviously forest is not optimized for this type of operation, but information is available if needed.
    >
    >
    > The notion that you have suggested in this email and some of the previous emails,
    >
    > "That is one of a myriad of possible such resource ontologies.    All of them can be mapped into a simple attribute based scheme that is needed to apply hierarchical rules." 
    >
    > I still have interest in and would like to see a clearly defined example so that I might understand the DAG use cases better and if they have broader application capabilities then is currently apparent to me. 
    >
    > However, for those use cases, such as have been described explicitly and generally, where the DAG has no capabilities, the critical factor is that there is no DAG capability to maintain multiple hierarchies that retain the original lines of authority without spreading that authority to additional unintended entities. As a result, any particular resource in a DAG will be subject to policies from direct ancestors and indirect ancestors as well with no way to distinguish them. Without this capability, other capabilities are not a factor, because the DAG will not meet the requirements.
    >
    > For the forest, the capability to maintain the original lines of authority is built-in. The capability to obtain, what we might call the additional lines of "influence" is also available as is the ability to distinguish each from the other.  For applications that only require "influence + direct", then DAG is appropriate. When there is a requirement to maintain "direct lines of authority only" then DAG will not meet the requirement, and one has the option in the spec, then, of choosing forest.
    >
    > This next point still keeps coming up and still I must address it because it does not represent what the proposal is:
    >
    > "I am glad that you do not advocate removing DAG.    I am voicing my opinion about adding anything else.   There is no need for that and it brings complexity. "
    >
    > This statement creates the impression that the "forest" capability is being "added". It is not. It is already there and has been there since the spec was first released. However the capability has not been properly explained and it is difficult for me to see how anyone could discern between the two very distinct characteristics of the DAG and forest from the current spec. Since there are many application that require the forest and not the DAG, the purpose of the clarifications in the spec is to enable readers to understand the distinction and select what they need appropriately.
    >
    > What currently exists in the spec is "complexity" because these two concepts are intertwined in a manner that one cannot see the difference between disjoint and merged trees and if one is interested in disjoint trees then there is tremendous complexity figuring out how to use the spec for this purpose. The proposed changes simplify the spec by disambiguating the two concepts and enabling the user of the spec to have a clear choice.
    >
    > The final statement also mixes up the capabilities:
    >
    > "From the point of view of PDP there are no hierarchies to merge.   There is one hierarchy at a time that is pertinent to an evaluation.   Merging etc. is to be handled by an external system. "
    >
    > It is correct that the PDP does not merge hierarchies, nor does anything in the proposed changes suggest that does.
    >
    > It is the DAG content handler that merges hierarchies by applying the ancestor collection algorithms in section 3.2 to the resource collection data before it submits the request to the PDP. These algorithms explicitly collect ancestors that are not direct ancestors of the requested node, because they make the assumption that the information distinguishing between the two kinds of ancestors is not available, which in itself is an assumption about the external systems that cannot objectively be made.
    >
    > The example given in earlier email shows exactly the kinds of external systems that exist and shows that the information is generally available if it is of potential use. The assumption in the 3.2 algorithms is that there is no distinguishing information externally to distinguish between direct and indirect ancestors. This is, in general, a false assumption. One should be free to implement context handlers that have any capabilities necessary to meet the needs of the policy designers who use the PDP. 
    >
    > In the example given, one would have the choice of the "forest resource manager" or the "DAG resource manager". If the enterprise wanted to maintain "disjoint, but overlapping" lines of authority, then they could deploy a "forest resource manager". If they wanted "merged" lines of authority, they could deploy a "DAG resource manager". 
    >
    > I expect, in principle, if they wanted a mix of both, disjoint for some policies, and merged for other policies, there are probably enterprise design strategies where the PEP in initial request could be configured to trigger one or the other type of ancestor collection by the context handler, which is the point of specifying the "forest" identifier for the URIs in section 2.2 and the functions in 3.2. If context handler needs to gather only direct ancestors, or if it is all URIs not gather any ancestors, or if is DAG gather all ancestors, then contexthandler can make that choice based on identifiers in request.
    >
    >     Thanks,
    >     Rich
    >
    >
    > Daniel Engovatov wrote: 
    >
    >
    > On Feb 26, 2009, at 2:18 PM, Rich.Levinson wrote: 
    >
    >
    >
    >
    > Hi Daniel and TC, 
    >
    > I am disappointed that this response does not directly address the example. I consider it to be a very reasonable example. One such use case would be a "farm" of sharable computers, and two applications, each organized as a hierarchy of modules, that the appl deployer configures on different machines, possibly because those machines have resources needed by specific application modules. 
    >
    >
    > I did address the example.   I have said that managing a "farm of sharable computers", or anything else of that nature should not be a part of XACML.   There is a multitude of possible structures that we could possibly address, but trying to standardize them is a folly.  It should be left to an industry/vendor/domain specific profiles. 
    >
    > The only thing that matters for a simple, core hierarchical rules management system is an ability to specify a rule that apply to "descendants" of a resource and an ability to specify what resources are "descendants". 
    >
    >
    >
    >
    > This is typical enterprise use case with many large distributed applications over world-wide corporate resources. Each application needs to be managed independently of other applications, yet at the same time must share the common corporate resources on which it is run. 
    >
    >
    > That is one of a myriad of possible such resource ontologies.    All of them can be mapped into a simple attribute based scheme that is needed to apply hierarchical rules. 
    >
    >
    >
    >
    >
    > Finally, I want to emphasize one more time: I have not advocated removing any of the DAG functionality that already exists in the spec. If you carefully read the proposed modified spec, I think you will see it is functionally unchanged. The changes are only to distinguish the DAG from the forest and to fill in the missing information to show how the forest can be used, if one chooses to do so. 
    >
    >
    > I am glad that you do not advocate removing DAG.    I am voicing my opinion about adding anything else.   There is no need for that and it brings complexity. 
    >
    >
    >
    >
    > The main difference between DAG and forest is that DAG can be used  to "merge" hierarchies into a single uniform structure which has no memory of the original hierarchies. The forest "aggregates" hierarchies into a single uniform structure that does have memory of the original hierarchies and the capability of maintaining that info thru adds moves and changes. 
    >
    > From the point of view of PDP there are no hierarchies to merge.   There is one hierarchy at a time that is pertinent to an evaluation.   Merging etc. is to be handled by an external system. 
    >
    >
    > Daniel; 
    >
    >
    >