Hi Erik, On 27/11/2012 8:43 PM, Erik Rissanen wrote: Hi Steven, See inline. On 2012-11-05 05:42, Steven Legg wrote: Hi Erik, On 1/11/2012 6:40 PM, Erik Rissanen wrote: Hi Steven, I do think there is some practical value in being able to collect any types of policies into a single policy set, but I agree that the value probably is not that big. In come cases where someone would hand over a policy set "here are all my access and admin policies", they would have to hand over two separate sets of policies instead. And, yes, when I think about it more, the evaluation logic change is small. And there is actually one additional benefit. The explicit marking of a policy as an admin policy is probably simpler conceptually to users than to use weird attribute category names. I agree completely. So, I would agree with you to these changes. Reflecting on what you say here and what you were saying during the TC meeting makes me think you are assuming more than the minimal change required to dispense with category prefixing, in which case there are some technical choices to be discussed. I'll start by describing the minimal change. The reduction procedure, as currently described by the administration profile, begins when the PDP encounters an applicable, untrusted access policy. Let's call it 'A'. A reduction graph is formed by considering each ordered pair of policies in the policy set that contains 'A'. Let's call that policy set 'B'. To even get to the point of evaluating access policy 'A', policy set 'B' must be an access policy set (which is to say, it has a target that can only be satisfied by an access request). For policy 'A' to be authorized at all there must be at least one sibling policy of 'A' that is an administrative policy. Let's call it policy 'C'. So an access policy set like 'B' must be allowed to have children that are either access policies (like 'A') or administrative policies (like 'C'). In the current scheme we distinguish between access policies and administrative policies by whether or not they have attribute designators referring to prefixed categories. In the new scheme we would tell the difference by the element name of the policy, e.g., either <Policy> or <AdministrativePolicy>, and in the process exclude the unhelpful possibility of hybrid policies. It is also possible for a sibling of policy 'B' to be an administrative policy set, which is to say, a policy set with a target that can only be satisfied by an administrative request. We can likewise distinguish between access policy sets and administrative policy sets by the element name, e.g., either <PolicySet> or <AdministrativePolicySet>. Let's say we have an administrative policy set 'D' that is a sibling of policy 'A'. Both policy 'C' and policy set 'D' are considered when reducing policy 'A'. In which case they are evaluated with respect to an administrative request. Policy set 'D' is only ever considered when processing an administrative request, so any access policy or access policy set children of policy set 'D' will never be evaluated. We might as well disallow such children. In summary, what we have for the minimal change is <PolicySet> elements that may have <Policy>, <AdministrativePolicy>, <PolicySet> and <AdministrativePolicySet> children, and <AdministrativePolicySet> elements that may have only <AdministrativePolicy> and <AdministrativePolicySet> children. The fact that an access policy set can have administrative child policies and policy sets is a non-issue for most policy set combining algorithms. In the current scheme the administrative children would always evaluate to NotApplicable when evaluating an access request. In the new scheme the administrative children would be skipped (or automatically NotApplicable) when evaluating an access request. Either way, the result of the combining algorithm is unaffected. The one exception is the on-permit-apply-second combining algorithm because it limits a policy set to exactly two children. If, for an access policy set, those children are both access policies, then in practice they have to be trusted policies because there is no room for any administrative policies to authorize untrusted policies (note this is also the case with the current administration profile). If either child of an access policy is an administrative policy, then the policy set will never be applicable. To make the on-permit-apply-second combining rule more useful in an administrative setting, the restriction to two children should be relaxed to two access children and any number of administrative children when the combining rule is used in an access policy set. The "first" and "second" children should be taken to mean the first and second access children, or we can insist that any administrative children must come after the two access children. What to do in the case of an administrative policy set with the on-permit-apply-second combining rule is not so obvious. If we limit it to two administrative children, then those children would have to be trusted in practice. We could say that the first two children are considered by the combining algorithm and any subsequent children are only used if reduction of untrusted children is required. I think the above "minimal change" seems good. I don't think it is a big problem that the on-permit-apply-second is meaningful only in context of trusted children, since it is intended to solve the issue of a condition in policies, and for that purpose everything work fine. That covers the minimal change. The more substantial change is a complete separation of access and administrative policies and policy sets. That is, a <PolicySet> can only have <Policy> and <PolicySet> children, and an <AdministrativePolicySet> can only have <AdministrativePolicy> and <AdministrativePolicySet> children. An access request would initially be assessed against the collection of access policies and access policy sets. The administrative policies and policy sets would become involved if there are any untrusted access policies or policy sets to be reduced. A revision of the reduction procedure would be necessary and I see two main possibilities. I don't like the above since this introduces a top level construct in the PDP which is different from any of the regular XACML policy constructs. As opposed to the current scheme that introduces a mid-level construct (the reduction graph built from pair-wise assessment) which is different from the regular XACML policy set evaluation ? > It is a fact that the initial request to the PDP is an access request, so the access request must match the "top level policy construct" in the PDP. It still would. > Also, if the administrative profile is going to be of any use, this top level policy construct also has to also be able to contain administrative policies. Only if you assume that everything has to be wrapped up in a single, physical policy set. An important aspect of the policy labelling solution is that administrative policies and policy sets are automatically NotApplicable when evaluating access requests, and access policies and policy sets are automatically NotApplicable when evaluating administrative requests. Section 7.17 of the core specification has this to say about request evaluation: "the PDP is defined by a policy-combining algorithm and a set of policies and/or policy sets. The PDP SHALL return a response context as if it had evaluated a single policy set consisting of this policy-combining algorithm and the set of policies and/or policy sets". We could assume that this virtual, single policy set is exempt from the separation of access policy and administrative policy. The children could be access policies and/or access policy sets and/or administrative policies and/or administrative policy sets. Some of these children will be automatically NotApplicable depending on whether it is an access request or an administrative request that is being evaluated. Alternatively, we could (with respect to option 2) assume that 7.17 applies to access request evaluation and write similar text to cover administrative request evaluation. That is, the PDP is defined by a policy-combining algorithm and a set of access policies and/or access policy sets, and a policy-combining algorithm (maybe the same one) and a set of administrative policies and/or administrative policy sets. > Thus the top level policy construct is something different from the above policy constructs which you listed. That adds more specification and implementation cost, compared with a PDP which simply starts with a selected top level policy set, which is semantically no different than any other policy set in XACML. In the context of option (2), and given that an implementation chooses to restrict the "set of policies and/or policy sets" in 7.17 to exactly one policy set, is it really that difficult to have a selected top level access policy set as the place for the PDP to start for an access request and also a selected top level administrative policy set as the place for the PDP to start for an administrative request ? The first possibility is that we keep the idea of a reduction graph, only instead of the nodes in the graph being the siblings of the untrusted access policy being reduced, the nodes are the standalone administrative policies and policy sets. In effect, every access policy has every standalone administrative policy or policy set as an implied sibling when forming the reduction graph. We have the choice when reducing an untrusted administrative policy whether to consider the actual siblings of that administrative policy when forming the reduction graph (call this (1.a)), or to form the graph from the standalone administrative policies and policy sets (call this (1.b)), just as we would for untrusted access policies. The second possibility (call this (2)) is to do away with the reduction graph and simply assess an administrative request against the collection of administrative policies and policy sets just as we assess an access request against the collection of access policies and policy sets. If we find an untrusted policy (in either collection), then we form the necessary administrative request and assess it against the collection of administrative policies and policy sets. An effect of options (1.b) and (2) is that in the process of reducing an administrative policy we may encounter that very same administrative policy. If we do, then we treat it as NotApplicable rather than recursively reducing it. To do otherwise would open the possibility of self-authorizing, untrusted policies. Note that this effect doesn't arise with the delegation graph because policies aren't paired with themselves. Also with options (1.b) and (2) we don't need to do anything about the on-permit-apply-second combining rule. Administrative policies no longer need to be siblings of the untrusted policies they authorize, so the on-permit-apply-second combining rule can still insist on having exactly two children. I would very much like us to choose option (2) because working out where to put an administrative policy under the current scheme is a burden policy writers can do without. Take the simple case where User A delegates all rights to User D. This is a very simple administrative policy that basically says "if the delegate is User D, then Permit". The issue is where to put it. User A needs to place it (by copy or by reference) in every policy set where User D will potentially be creating access policies. Furthermore, as new policy sets are created that User D might put policies into, User A will have to put the administrative policy in there as well. Conversely, if User A isn't thorough or proactive in placing the administrative policy, then User D will be limited in the rights he or she can actually exercise. Compounding the difficulties is the fact that in the general case, because of multi-valued attributes and augmentation of the delegate category by a context handler, practially any untrusted policy can be authorized by any administrative policy. It all depends on the request context. It is only by making assumptions about certain attributes being single-valued or by knowing about correlations between the attributes of an access subject that we can begin to predict which untrusted policies will be authorized by which administrative policies in the absence of any specific request context. These are things that users shouldn't have to be concerned with when creating administrative policies. Options (1.b) and (2) mean that they don't have to be. Option (2) is the conceptually simpler of the two, and can simulate (1.b) if desired. I don't agree that option 2 is simpler conceptually. I would say it's the opposite since it introduces another type of policy combining at the top level. Option (1.b) calls for forming a reduction graph from the top level administrative policies and/or policy sets, which is quite different from what 7.17 requires for access requests. Option (2) is just like 7.17, except the policies or policy sets will be different ones. Also, being able to mix in admin policies in nested access policies is useful for creating hierarchical structures, where a delegated policy contains nested delegation itself. This sort of recursion is useful for being able to import a full policy set of a sub-organization which internally might want to use delegation. I'm sceptical about the utility of that. Importing policy from a sub-organization isn't necessarily going to be easy. For example, a user of the sub-organization may have "read" access to everything, which is alright in the scope of the sub-organization, but may not be appropriate in the scope of the parent organization. Access rights will generally need to be reconsidered, which will involve rewriting and reorganizing policy for both the parent organization and the sub-organization, and the administrative policies won't be immune to that. Even if restricting the scope of the sub-organization's administrative policies to the sub-organization's access policies is useful, importing the policy of a sub-organization is a relatively infrequent event. Option (2) is about making delegation easier to use all the time. Keeping the reduction graph so that importing a policy set from a sub-organization is (maybe) easier is making the wrong trade off. Also, with option (2) the parent organization would be importing an access policy set and a separate administrative policy set. If there is a simple way to distinguish the issuers in the sub-organization from issuers in the parent organization (e.g., by the domain name in their email addresses), then this could be added to the target of the administrative policy set, effectively restricting the scope of the sub-organization's administrative policies to the sub-organization's access policies, even though they are separated. Regards, Steven Best regards, Erik Regards, Steven Best regards, Erik On 2012-11-01 06:14, Steven Legg wrote: Hi Erik, On 31/10/2012 11:35 PM, Erik Rissanen wrote: Hi Steven, Sorry about the slow response to this. As I see it, there are two benefits to the category prefixing: 1. A policy can be mixed admin/access. How is that a particular benefit when any such mixed policy (or policy set) can be rewritten as a pair of a pure access policy and a pure administrative policy, together having exactly the same effect ? A policy that authorizes itself is pointless, and merging an access policy with an administrative policy that authorizes unrelated access policies is weird and confusing, so why do it ? 2. We don't need to change the XACML evaluation logic as much. To implement the delegation model, the PDP can use the normal XACML evaluation on admin requests, while building the delegation graph. I think the second is a significant benefit. It would significantly complicate both the administrative spec and the implementation if we need to define additional modes of XACML policy evaluation. The delegation model is already a significant departure from normal XACML evaluation, what with building the delegation graph and forming administrative requests. Those things would still be there. The complexity trade off is between category prefixing (which is not yet complete because it has unresolved issues) and a simple boolean test during request processing to see if the kind of the policy matches the kind of the request (i.e., access versus administrative). That test is simple and efficient compared to category prefixing. What about changing the prefix so it works with all cases? The only thing that comes to mind that would be syntactically valid is a prefix to the scheme name. For example, http://example.com/foobar becomes delegated- http://example.com/foobar . > Or changing the admin category to something else than it being based on a prefix? That's difficult without making changes to the core syntax. > By means of some other kind of algorithm, or maybe an explicit table? Labelling the policies would be much easier than a managing a mapping table. Regards, Steven Best regards, Erik On 2012-09-03 07:03, Steven Legg wrote: Hi Erik, On 1/09/2012 1:23 AM, Erik Rissanen wrote: I don't think we change the delegation model in this way since it would mean changing the core schema, which we really don't want to do at this stage. I originally suggested an XML attribute for the label, which would need a change to the core schema, but there is another way to label the policies without changing the core schema and that is substitution groups for Policy and PolicySet. For example: <xs:element name="AdministrativePolicy" type="xacml:PolicyType" substitutionGroup="xacml:Policy"/> <xs:element name="AdministrativePolicySet" type="xacml:PolicySetType" substitutionGroup="xacml:PolicySet"/> In a way this is better than a simple XML attribute because it is more visually distinctive. It would be desirable for AdministrativePolicy and AdministrativePolicySet to be in the same namespace as Policy and PolicySet, but if they have to be in their own namespace so be it. > Also, I think we did consider labeling policies like this in early stages of the delegation work. I don't remember right now why we did not go that way, but I suspect there was a reason. I've found and reported on a bunch of problems with category prefixing, so there are reasons to reconsider using labelling. If the purpose of the prefixing is just to ensure that administrative policies aren't applicable when evaluating access requests, and vice versa, then labelling is a simpler and cleaner way to achieve the same end. > Probably that the current mechanism is more flexible. It's more flexible in that it allows hybrid policies that are a bit access policy and a bit administrative policy. I can't think of a good reason to want to do that, and in any case, it is always possible to split a hybrid policy into a pure access policy and a pure administrative policy. I would happily forego this dubious flexibility to get rid of category prefixing and its problems. Regards, Steven

18. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

Recommend

Erik Rissanen

Posted 11-29-2012 12:33

Hi Steven, On 2012-11-28 06:28, Steven Legg wrote: Hi Erik, On 27/11/2012 8:43 PM, Erik Rissanen wrote: Hi Steven, See inline. On 2012-11-05 05:42, Steven Legg wrote: Hi Erik, On 1/11/2012 6:40 PM, Erik Rissanen wrote: Hi Steven, I do think there is some practical value in being able to collect any types of policies into a single policy set, but I agree that the value probably is not that big. In come cases where someone would hand over a policy set "here are all my access and admin policies", they would have to hand over two separate sets of policies instead. And, yes, when I think about it more, the evaluation logic change is small. And there is actually one additional benefit. The explicit marking of a policy as an admin policy is probably simpler conceptually to users than to use weird attribute category names. I agree completely. So, I would agree with you to these changes. Reflecting on what you say here and what you were saying during the TC meeting makes me think you are assuming more than the minimal change required to dispense with category prefixing, in which case there are some technical choices to be discussed. I'll start by describing the minimal change. The reduction procedure, as currently described by the administration profile, begins when the PDP encounters an applicable, untrusted access policy. Let's call it 'A'. A reduction graph is formed by considering each ordered pair of policies in the policy set that contains 'A'. Let's call that policy set 'B'. To even get to the point of evaluating access policy 'A', policy set 'B' must be an access policy set (which is to say, it has a target that can only be satisfied by an access request). For policy 'A' to be authorized at all there must be at least one sibling policy of 'A' that is an administrative policy. Let's call it policy 'C'. So an access policy set like 'B' must be allowed to have children that are either access policies (like 'A') or administrative policies (like 'C'). In the current scheme we distinguish between access policies and administrative policies by whether or not they have attribute designators referring to prefixed categories. In the new scheme we would tell the difference by the element name of the policy, e.g., either <Policy> or <AdministrativePolicy>, and in the process exclude the unhelpful possibility of hybrid policies. It is also possible for a sibling of policy 'B' to be an administrative policy set, which is to say, a policy set with a target that can only be satisfied by an administrative request. We can likewise distinguish between access policy sets and administrative policy sets by the element name, e.g., either <PolicySet> or <AdministrativePolicySet>. Let's say we have an administrative policy set 'D' that is a sibling of policy 'A'. Both policy 'C' and policy set 'D' are considered when reducing policy 'A'. In which case they are evaluated with respect to an administrative request. Policy set 'D' is only ever considered when processing an administrative request, so any access policy or access policy set children of policy set 'D' will never be evaluated. We might as well disallow such children. In summary, what we have for the minimal change is <PolicySet> elements that may have <Policy>, <AdministrativePolicy>, <PolicySet> and <AdministrativePolicySet> children, and <AdministrativePolicySet> elements that may have only <AdministrativePolicy> and <AdministrativePolicySet> children. The fact that an access policy set can have administrative child policies and policy sets is a non-issue for most policy set combining algorithms. In the current scheme the administrative children would always evaluate to NotApplicable when evaluating an access request. In the new scheme the administrative children would be skipped (or automatically NotApplicable) when evaluating an access request. Either way, the result of the combining algorithm is unaffected. The one exception is the on-permit-apply-second combining algorithm because it limits a policy set to exactly two children. If, for an access policy set, those children are both access policies, then in practice they have to be trusted policies because there is no room for any administrative policies to authorize untrusted policies (note this is also the case with the current administration profile). If either child of an access policy is an administrative policy, then the policy set will never be applicable. To make the on-permit-apply-second combining rule more useful in an administrative setting, the restriction to two children should be relaxed to two access children and any number of administrative children when the combining rule is used in an access policy set. The "first" and "second" children should be taken to mean the first and second access children, or we can insist that any administrative children must come after the two access children. What to do in the case of an administrative policy set with the on-permit-apply-second combining rule is not so obvious. If we limit it to two administrative children, then those children would have to be trusted in practice. We could say that the first two children are considered by the combining algorithm and any subsequent children are only used if reduction of untrusted children is required. I think the above "minimal change" seems good. I don't think it is a big problem that the on-permit-apply-second is meaningful only in context of trusted children, since it is intended to solve the issue of a condition in policies, and for that purpose everything work fine. That covers the minimal change. The more substantial change is a complete separation of access and administrative policies and policy sets. That is, a <PolicySet> can only have <Policy> and <PolicySet> children, and an <AdministrativePolicySet> can only have <AdministrativePolicy> and <AdministrativePolicySet> children. An access request would initially be assessed against the collection of access policies and access policy sets. The administrative policies and policy sets would become involved if there are any untrusted access policies or policy sets to be reduced. A revision of the reduction procedure would be necessary and I see two main possibilities. I don't like the above since this introduces a top level construct in the PDP which is different from any of the regular XACML policy constructs. As opposed to the current scheme that introduces a mid-level construct (the reduction graph built from pair-wise assessment) which is different from the regular XACML policy set evaluation ? > It is a fact that the initial request to the PDP is an access request, so the access request must match the "top level policy construct" in the PDP. It still would. > Also, if the administrative profile is going to be of any use, this top level policy construct also has to also be able to contain administrative policies. Only if you assume that everything has to be wrapped up in a single, physical policy set. It would, in a broad sense. It does not have to be a policy set strictly. Naturally, in your proposal it would be something different. It would be nice if we would not need this "different thing". An important aspect of the policy labelling solution is that administrative policies and policy sets are automatically NotApplicable when evaluating access requests, and access policies and policy sets are automatically NotApplicable when evaluating administrative requests. Section 7.17 of the core specification has this to say about request evaluation: "the PDP is defined by a policy-combining algorithm and a set of policies and/or policy sets. The PDP SHALL return a response context as if it had evaluated a single policy set consisting of this policy-combining algorithm and the set of policies and/or policy sets". We could assume that this virtual, single policy set is exempt from the separation of access policy and administrative policy. The children could be access policies and/or access policy sets and/or administrative policies and/or administrative policy sets. Some of these children will be automatically NotApplicable depending on whether it is an access request or an administrative request that is being evaluated. Alternatively, we could (with respect to option 2) assume that 7.17 applies to access request evaluation and write similar text to cover administrative request evaluation. That is, the PDP is defined by a policy-combining algorithm and a set of access policies and/or access policy sets, and a policy-combining algorithm (maybe the same one) and a set of administrative policies and/or administrative policy sets. > Thus the top level policy construct is something different from the above policy constructs which you listed. That adds more specification and implementation cost, compared with a PDP which simply starts with a selected top level policy set, which is semantically no different than any other policy set in XACML. In the context of option (2), and given that an implementation chooses to restrict the "set of policies and/or policy sets" in 7.17 to exactly one policy set, is it really that difficult to have a selected top level access policy set as the place for the PDP to start for an access request and also a selected top level administrative policy set as the place for the PDP to start for an administrative request ? No, it's not difficult, but it means that delegation will only work at the top level. A sub policyset cannot use delegation within itself in that case, which is a restriction for a collaborative policy authoring. The first possibility is that we keep the idea of a reduction graph, only instead of the nodes in the graph being the siblings of the untrusted access policy being reduced, the nodes are the standalone administrative policies and policy sets. In effect, every access policy has every standalone administrative policy or policy set as an implied sibling when forming the reduction graph. We have the choice when reducing an untrusted administrative policy whether to consider the actual siblings of that administrative policy when forming the reduction graph (call this (1.a)), or to form the graph from the standalone administrative policies and policy sets (call this (1.b)), just as we would for untrusted access policies. The second possibility (call this (2)) is to do away with the reduction graph and simply assess an administrative request against the collection of administrative policies and policy sets just as we assess an access request against the collection of access policies and policy sets. If we find an untrusted policy (in either collection), then we form the necessary administrative request and assess it against the collection of administrative policies and policy sets. An effect of options (1.b) and (2) is that in the process of reducing an administrative policy we may encounter that very same administrative policy. If we do, then we treat it as NotApplicable rather than recursively reducing it. To do otherwise would open the possibility of self-authorizing, untrusted policies. Note that this effect doesn't arise with the delegation graph because policies aren't paired with themselves. Also with options (1.b) and (2) we don't need to do anything about the on-permit-apply-second combining rule. Administrative policies no longer need to be siblings of the untrusted policies they authorize, so the on-permit-apply-second combining rule can still insist on having exactly two children. I would very much like us to choose option (2) because working out where to put an administrative policy under the current scheme is a burden policy writers can do without. Take the simple case where User A delegates all rights to User D. This is a very simple administrative policy that basically says "if the delegate is User D, then Permit". The issue is where to put it. User A needs to place it (by copy or by reference) in every policy set where User D will potentially be creating access policies. Furthermore, as new policy sets are created that User D might put policies into, User A will have to put the administrative policy in there as well. Conversely, if User A isn't thorough or proactive in placing the administrative policy, then User D will be limited in the rights he or she can actually exercise. Compounding the difficulties is the fact that in the general case, because of multi-valued attributes and augmentation of the delegate category by a context handler, practially any untrusted policy can be authorized by any administrative policy. It all depends on the request context. It is only by making assumptions about certain attributes being single-valued or by knowing about correlations between the attributes of an access subject that we can begin to predict which untrusted policies will be authorized by which administrative policies in the absence of any specific request context. These are things that users shouldn't have to be concerned with when creating administrative policies. Options (1.b) and (2) mean that they don't have to be. Option (2) is the conceptually simpler of the two, and can simulate (1.b) if desired. I don't agree that option 2 is simpler conceptually. I would say it's the opposite since it introduces another type of policy combining at the top level. Option (1.b) calls for forming a reduction graph from the top level administrative policies and/or policy sets, which is quite different from what 7.17 requires for access requests. Option (2) is just like 7.17, except the policies or policy sets will be different ones. Also, being able to mix in admin policies in nested access policies is useful for creating hierarchical structures, where a delegated policy contains nested delegation itself. This sort of recursion is useful for being able to import a full policy set of a sub-organization which internally might want to use delegation. I'm sceptical about the utility of that. Importing policy from a sub-organization isn't necessarily going to be easy. For example, a user of the sub-organization may have "read" access to everything, which is alright in the scope of the sub-organization, but may not be appropriate in the scope of the parent organization. Access rights will generally need to be reconsidered, which will involve rewriting and reorganizing policy for both the parent organization and the sub-organization, and the administrative policies won't be immune to that. Even if restricting the scope of the sub-organization's administrative policies to the sub-organization's access policies is useful, importing the policy of a sub-organization is a relatively infrequent event. Option (2) is about making delegation easier to use all the time. Keeping the reduction graph so that importing a policy set from a sub-organization is (maybe) easier is making the wrong trade off. I think collaborative policy authoring, whereby anything can be nested, is valuable. Also, with option (2) the parent organization would be importing an access policy set and a separate administrative policy set. If there is a simple way to distinguish the issuers in the sub-organization from issuers in the parent organization (e.g., by the domain name in their email addresses), then this could be added to the target of the administrative policy set, effectively restricting the scope of the sub-organization's administrative policies to the sub-organization's access policies, even though they are separated. But it would put everything at the top level. I would think that recursion and nesting would be useful to handle very large policy sets. Regards, Steven Best regards, Erik Regards, Steven Best regards, Erik On 2012-11-01 06:14, Steven Legg wrote: Hi Erik, On 31/10/2012 11:35 PM, Erik Rissanen wrote: Hi Steven, Sorry about the slow response to this. As I see it, there are two benefits to the category prefixing: 1. A policy can be mixed admin/access. How is that a particular benefit when any such mixed policy (or policy set) can be rewritten as a pair of a pure access policy and a pure administrative policy, together having exactly the same effect ? A policy that authorizes itself is pointless, and merging an access policy with an administrative policy that authorizes unrelated access policies is weird and confusing, so why do it ? 2. We don't need to change the XACML evaluation logic as much. To implement the delegation model, the PDP can use the normal XACML evaluation on admin requests, while building the delegation graph. I think the second is a significant benefit. It would significantly complicate both the administrative spec and the implementation if we need to define additional modes of XACML policy evaluation. The delegation model is already a significant departure from normal XACML evaluation, what with building the delegation graph and forming administrative requests. Those things would still be there. The complexity trade off is between category prefixing (which is not yet complete because it has unresolved issues) and a simple boolean test during request processing to see if the kind of the policy matches the kind of the request (i.e., access versus administrative). That test is simple and efficient compared to category prefixing. What about changing the prefix so it works with all cases? The only thing that comes to mind that would be syntactically valid is a prefix to the scheme name. For example, http://example.com/foobar becomes delegated- http://example.com/foobar . > Or changing the admin category to something else than it being based on a prefix? That's difficult without making changes to the core syntax. > By means of some other kind of algorithm, or maybe an explicit table? Labelling the policies would be much easier than a managing a mapping table. Regards, Steven Best regards, Erik On 2012-09-03 07:03, Steven Legg wrote: Hi Erik, On 1/09/2012 1:23 AM, Erik Rissanen wrote: I don't think we change the delegation model in this way since it would mean changing the core schema, which we really don't want to do at this stage. I originally suggested an XML attribute for the label, which would need a change to the core schema, but there is another way to label the policies without changing the core schema and that is substitution groups for Policy and PolicySet. For example: <xs:element name="AdministrativePolicy" type="xacml:PolicyType" substitutionGroup="xacml:Policy"/> <xs:element name="AdministrativePolicySet" type="xacml:PolicySetType" substitutionGroup="xacml:PolicySet"/> In a way this is better than a simple XML attribute because it is more visually distinctive. It would be desirable for AdministrativePolicy and AdministrativePolicySet to be in the same namespace as Policy and PolicySet, but if they have to be in their own namespace so be it. > Also, I think we did consider labeling policies like this in early stages of the delegation work. I don't remember right now why we did not go that way, but I suspect there was a reason. I've found and reported on a bunch of problems with category prefixing, so there are reasons to reconsider using labelling. If the purpose of the prefixing is just to ensure that administrative policies aren't applicable when evaluating access requests, and vice versa, then labelling is a simpler and cleaner way to achieve the same end. > Probably that the current mechanism is more flexible. It's more flexible in that it allows hybrid policies that are a bit access policy and a bit administrative policy. I can't think of a good reason to want to do that, and in any case, it is always possible to split a hybrid policy into a pure access policy and a pure administrative policy. I would happily forego this dubious flexibility to get rid of category prefixing and its problems. Regards, Steven

19. RE: [xacml] Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

Recommend

Hal Lockhart

Posted 11-29-2012 19:58

I am sure I don't understand all the subtleties of this debate, but it seems to me that for the organization maintaining a large policy hierarchy it will be easier to have a single tree with both admin and access policies than two trees (or the equivalent). The reason is that the policy set hierarchy is used to partition the various scopes of concern within the organizations. It seems to me that the constructs used to partition the space for the purposes of applicable policy will usually be the same as those used to partition the space for scope of administrative responsibility. With two trees, its seems to me that often it will be necessary to make synchronized parallel changes to both trees, which is a good thing to avoid if possible. For example, suppose parts of the policy tree pertain to different subsidiaries within a corporation. It is likely that administrative responsibilities will also be divided by subsidiary. If we need to change a Target which selects server from some subsidiary, it is likely the same change will be required in the admin tree as well. Hal >

Original Message

Original Message----- > From: Erik Rissanen [ mailto:erik@axiomatics.com ] > Sent: Thursday, November 29, 2012 7:33 AM > To: Steven Legg > Cc: xacml@lists.oasis-open.org > Subject: [xacml] Re: Policy Labelling (was Re: Delegation and on- > permit-apply-second) > > Hi Steven, > > On 2012-11-28 06:28, Steven Legg wrote: > > > > Hi Erik, > > > > On 27/11/2012 8:43 PM, Erik Rissanen wrote: > >> Hi Steven, > >> > >> See inline. > >> > >> On 2012-11-05 05:42, Steven Legg wrote: > >>> > >>> Hi Erik, > >>> > >>> On 1/11/2012 6:40 PM, Erik Rissanen wrote: > >>>> Hi Steven, > >>>> > >>>> I do think there is some practical value in being able to collect > >>>> any types of policies into a single policy set, but I agree that > >>>> the value probably is not that big. In come cases where someone > >>>> would hand over a policy set "here are all my access and admin > >>>> policies", they would have to hand over two separate sets of > >>>> policies instead. > >>>> > >>>> And, yes, when I think about it more, the evaluation logic change > >>>> is small. And there is actually one additional benefit. The > >>>> explicit marking of a policy as an admin policy is probably > simpler > >>>> conceptually to users than to use weird attribute category names. > >>> > >>> I agree completely. > >>> > >>>> > >>>> So, I would agree with you to these changes. > >>> > >>> Reflecting on what you say here and what you were saying during the > >>> TC meeting makes me think you are assuming more than the minimal > >>> change required to dispense with category prefixing, in which case > >>> there are some technical choices to be discussed. I'll start by > >>> describing the minimal change. > >>> > >>> The reduction procedure, as currently described by the > >>> administration profile, begins when the PDP encounters an > >>> applicable, untrusted access policy. Let's call it 'A'. A reduction > >>> graph is formed by considering each ordered pair of policies in the > policy set that contains 'A'. > >>> Let's > >>> call that policy set 'B'. To even get to the point of evaluating > >>> access policy 'A', policy set 'B' must be an access policy set > >>> (which is to say, it has a target that can only be satisfied by an > access request). > >>> For policy 'A' to be authorized at all there must be at least one > >>> sibling policy of 'A' that is an administrative policy. Let's call > >>> it policy 'C'. > >>> So an access policy set like 'B' must be allowed to have children > >>> that are either access policies (like 'A') or administrative > >>> policies (like 'C'). > >>> In the current scheme we distinguish between access policies and > >>> administrative policies by whether or not they have attribute > >>> designators referring to prefixed categories. In the new scheme we > >>> would tell the difference by the element name of the policy, e.g., > >>> either <Policy> or <AdministrativePolicy>, and in the process > >>> exclude the unhelpful possibility of hybrid policies. > >>> > >>> It is also possible for a sibling of policy 'B' to be an > >>> administrative policy set, which is to say, a policy set with a > >>> target that can only be satisfied by an administrative request. We > >>> can likewise distinguish between access policy sets and > >>> administrative policy sets by the element name, e.g., either > >>> <PolicySet> or <AdministrativePolicySet>. Let's say we have an > >>> administrative policy set 'D' that is a sibling of policy 'A'. Both > >>> policy 'C' and policy set 'D' are considered when reducing policy > >>> 'A'. In which case they are evaluated with respect to an > >>> administrative request. > >>> Policy > >>> set 'D' is only ever considered when processing an administrative > >>> request, so any access policy or access policy set children of > >>> policy set 'D' > >>> will > >>> never be evaluated. We might as well disallow such children. > >>> > >>> In summary, what we have for the minimal change is <PolicySet> > >>> elements that may have <Policy>, <AdministrativePolicy>, > <PolicySet> > >>> and <AdministrativePolicySet> children, and > >>> <AdministrativePolicySet> elements that may have only > >>> <AdministrativePolicy> and <AdministrativePolicySet> children. > >>> > >>> The fact that an access policy set can have administrative child > >>> policies and policy sets is a non-issue for most policy set > >>> combining algorithms. > >>> In the current scheme the administrative children would always > >>> evaluate to NotApplicable when evaluating an access request. In the > >>> new scheme the administrative children would be skipped (or > >>> automatically > >>> NotApplicable) > >>> when evaluating an access request. Either way, the result of the > >>> combining algorithm is unaffected. The one exception is the > >>> on-permit-apply-second combining algorithm because it limits a > >>> policy set to exactly two children. > >>> If, for an access policy set, those children are both access > >>> policies, then in practice they have to be trusted policies because > >>> there is no room for any administrative policies to authorize > >>> untrusted policies (note this is also the case with the current > >>> administration profile). If either child of an access policy is an > >>> administrative policy, then the policy set will never be > applicable. > >>> To make the on-permit-apply-second combining rule more useful in an > >>> administrative setting, the restriction to two children should be > >>> relaxed to two access children and any number of administrative > >>> children when the combining rule is used in an access policy set. > >>> The "first" and "second" children should be taken to mean the first > >>> and second access children, or we can insist that any > administrative > >>> children must come after the two access children. What to do in the > >>> case of an administrative policy set with the on-permit-apply- > second > >>> combining rule is not so obvious. If we limit it to two > >>> administrative children, then those children would have to be > >>> trusted in practice. We could say that the first two children are > >>> considered by the combining algorithm and any subsequent children > >>> are only used if reduction of untrusted children is required. > >>> > >> > >> I think the above "minimal change" seems good. I don't think it is a > >> big problem that the on-permit-apply-second is meaningful only in > >> context of trusted children, since it is intended to solve the issue > >> of a condition in policies, and for that purpose everything work > >> fine. > >> > >>> That covers the minimal change. The more substantial change is a > >>> complete separation of access and administrative policies and > policy > >>> sets. > >>> That is, > >>> a <PolicySet> can only have <Policy> and <PolicySet> children, and > >>> an <AdministrativePolicySet> can only have <AdministrativePolicy> > >>> and <AdministrativePolicySet> children. An access request would > >>> initially be assessed against the collection of access policies and > >>> access policy sets. > >>> The administrative policies and policy sets would become involved > if > >>> there are any untrusted access policies or policy sets to be > >>> reduced. A revision of the reduction procedure would be necessary > >>> and I see two main possibilities. > >>> > >> > >> I don't like the above since this introduces a top level construct > in > >> the PDP which is different from any of the regular XACML policy > >> constructs. > > > > As opposed to the current scheme that introduces a mid-level > construct > > (the reduction graph built from pair-wise assessment) which is > > different from the regular XACML policy set evaluation ? > > > > > It is a fact that the initial request to the PDP is an access > > > request, > >> so the access request must match the "top level policy construct" in > >> the PDP. > > > > It still would. > > > > > Also, if the administrative > >> profile is going to be of any use, this top level policy construct > >> also has to also be able to contain administrative policies. > > > > Only if you assume that everything has to be wrapped up in a single, > > physical policy set. > > > > It would, in a broad sense. It does not have to be a policy set > strictly. Naturally, in your proposal it would be something different. > It would be nice if we would not need this "different thing". > > > An important aspect of the policy labelling solution is that > > administrative policies and policy sets are automatically > > NotApplicable when evaluating access requests, and access policies > and > > policy sets are automatically NotApplicable when evaluating > > administrative requests. Section 7.17 of the core specification has > > this to say about request evaluation: > > > > "the PDP is defined by a policy-combining algorithm and a set of > > policies > > and/or policy sets. The PDP SHALL return a response context as > if > > it had > > evaluated a single policy set consisting of this policy- > combining > > algorithm > > and the set of policies and/or policy sets". > > > > We could assume that this virtual, single policy set is exempt from > > the separation of access policy and administrative policy. The > > children could be access policies and/or access policy sets and/or > > administrative policies and/or administrative policy sets. Some of > > these children will be automatically NotApplicable depending on > > whether it is an access request or an administrative request that is > > being evaluated. > > > > Alternatively, we could (with respect to option 2) assume that 7.17 > > applies to access request evaluation and write similar text to cover > > administrative request evaluation. That is, the PDP is defined by a > > policy-combining algorithm and a set of access policies and/or access > > policy sets, and a policy-combining algorithm (maybe the same one) > and > > a set of administrative policies and/or administrative policy sets. > > > > > Thus the top level policy construct is something different from the > > above policy > >> constructs which you listed. > >> > >> That adds more specification and implementation cost, compared with > a > >> PDP which simply starts with a selected top level policy set, which > >> is semantically no different than any other policy set in XACML. > > > > In the context of option (2), and given that an implementation > chooses > > to restrict the "set of policies and/or policy sets" in 7.17 to > > exactly one policy set, is it really that difficult to have a > selected > > top level access policy set as the place for the PDP to start for an > > access request and also a selected top level administrative policy > set > > as the place for the PDP to start for an administrative request ? > > No, it's not difficult, but it means that delegation will only work at > the top level. A sub policyset cannot use delegation within itself in > that case, which is a restriction for a collaborative policy authoring. > > > > >> > >>> The first possibility is that we keep the idea of a reduction > graph, > >>> only > >>> instead of the nodes in the graph being the siblings of the > >>> untrusted access > >>> policy being reduced, the nodes are the standalone administrative > >>> policies > >>> and policy sets. In effect, every access policy has every > standalone > >>> administrative policy or policy set as an implied sibling when > >>> forming the > >>> reduction graph. We have the choice when reducing an untrusted > >>> administrative > >>> policy whether to consider the actual siblings of that > >>> administrative policy > >>> when forming the reduction graph (call this (1.a)), or to form the > >>> graph > >>> from the standalone administrative policies and policy sets (call > >>> this (1.b)), > >>> just as we would for untrusted access policies. > >>> > >>> The second possibility (call this (2)) is to do away with the > reduction > >>> graph and simply assess an administrative request against the > >>> collection > >>> of administrative policies and policy sets just as we assess an > access > >>> request against the collection of access policies and policy sets. > >>> If we > >>> find an untrusted policy (in either collection), then we form the > >>> necessary administrative request and assess it against the > >>> collection of > >>> administrative policies and policy sets. > >>> > >>> An effect of options (1.b) and (2) is that in the process of > >>> reducing an > >>> administrative policy we may encounter that very same > administrative > >>> policy. > >>> If we do, then we treat it as NotApplicable rather than recursively > >>> reducing > >>> it. To do otherwise would open the possibility of self-authorizing, > >>> untrusted > >>> policies. Note that this effect doesn't arise with the delegation > graph > >>> because policies aren't paired with themselves. > >>> > >>> Also with options (1.b) and (2) we don't need to do anything about > the > >>> on-permit-apply-second combining rule. Administrative policies no > >>> longer > >>> need to be siblings of the untrusted policies they authorize, so > the > >>> on-permit-apply-second combining rule can still insist on having > >>> exactly > >>> two children. > >>> > >>> I would very much like us to choose option (2) because working out > >>> where > >>> to put an administrative policy under the current scheme is a > burden > >>> policy > >>> writers can do without. Take the simple case where User A delegates > all > >>> rights to User D. This is a very simple administrative policy that > >>> basically > >>> says "if the delegate is User D, then Permit". The issue is where > to > >>> put it. > >>> User A needs to place it (by copy or by reference) in every policy > >>> set where > >>> User D will potentially be creating access policies. Furthermore, > as > >>> new > >>> policy sets are created that User D might put policies into, User A > >>> will have > >>> to put the administrative policy in there as well. Conversely, if > >>> User A > >>> isn't thorough or proactive in placing the administrative policy, > >>> then User D > >>> will be limited in the rights he or she can actually exercise. > >>> Compounding > >>> the difficulties is the fact that in the general case, because of > >>> multi-valued attributes and augmentation of the delegate category > by > >>> a context handler, practially any untrusted policy can be > authorized > >>> by any > >>> administrative policy. It all depends on the request context. It is > >>> only > >>> by making assumptions about certain attributes being single-valued > >>> or by > >>> knowing about correlations between the attributes of an access > >>> subject that > >>> we can begin to predict which untrusted policies will be authorized > by > >>> which administrative policies in the absence of any specific > request > >>> context. > >>> These are things that users shouldn't have to be concerned with > when > >>> creating > >>> administrative policies. Options (1.b) and (2) mean that they don't > >>> have to > >>> be. Option (2) is the conceptually simpler of the two, and can > >>> simulate (1.b) > >>> if desired. > >>> > >> > >> I don't agree that option 2 is simpler conceptually. I would say > it's > >> the opposite since it introduces > >> another type of policy combining at the top level. > > > > Option (1.b) calls for forming a reduction graph from the top level > > administrative > > policies and/or policy sets, which is quite different from what 7.17 > > requires > > for access requests. Option (2) is just like 7.17, except the > policies or > > policy sets will be different ones. > > > >> > >> Also, being able to mix in admin policies in nested access policies > >> is useful for creating hierarchical > >> structures, where a delegated policy contains nested delegation > >> itself. This sort of recursion is useful for > >> being able to import a full policy set of a sub-organization which > >> internally might want to use delegation. > > > > I'm sceptical about the utility of that. Importing policy from a > > sub-organization > > isn't necessarily going to be easy. For example, a user of the > > sub-organization > > may have "read" access to everything, which is alright in the scope > of > > the > > sub-organization, but may not be appropriate in the scope of the > parent > > organization. Access rights will generally need to be reconsidered, > which > > will involve rewriting and reorganizing policy for both the parent > > organization > > and the sub-organization, and the administrative policies won't be > > immune to that. > > Even if restricting the scope of the sub-organization's > administrative > > policies > > to the sub-organization's access policies is useful, importing the > > policy of > > a sub-organization is a relatively infrequent event. Option (2) is > > about making > > delegation easier to use all the time. Keeping the reduction graph so > > that > > importing a policy set from a sub-organization is (maybe) easier is > > making the > > wrong trade off. > > > > I think collaborative policy authoring, whereby anything can be nested, > is valuable. > > > Also, with option (2) the parent organization would be importing an > > access policy > > set and a separate administrative policy set. If there is a simple > way > > to distinguish > > the issuers in the sub-organization from issuers in the parent > > organization (e.g., > > by the domain name in their email addresses), then this could be > added > > to the > > target of the administrative policy set, effectively restricting the > > scope of the > > sub-organization's administrative policies to the sub-organization's > > access > > policies, even though they are separated. > > > > But it would put everything at the top level. I would think that > recursion and nesting would be useful to handle very large policy sets. > > > Regards, > > Steven > > > >> > >> Best regards, > >> Erik > >> > >>> Regards, > >>> Steven > >>> > >>>> > >>>> Best regards, > >>>> Erik > >>>> > >>>> > >>>> On 2012-11-01 06:14, Steven Legg wrote: > >>>>> > >>>>> Hi Erik, > >>>>> > >>>>> On 31/10/2012 11:35 PM, Erik Rissanen wrote: > >>>>>> Hi Steven, > >>>>>> > >>>>>> Sorry about the slow response to this. > >>>>>> > >>>>>> As I see it, there are two benefits to the category prefixing: > >>>>>> > >>>>>> 1. A policy can be mixed admin/access. > >>>>> > >>>>> How is that a particular benefit when any such mixed policy (or > >>>>> policy set) can be > >>>>> rewritten as a pair of a pure access policy and a pure > >>>>> administrative policy, together > >>>>> having exactly the same effect ? A policy that authorizes itself > >>>>> is pointless, and > >>>>> merging an access policy with an administrative policy that > >>>>> authorizes unrelated > >>>>> access policies is weird and confusing, so why do it ? > >>>>> > >>>>>> > >>>>>> 2. We don't need to change the XACML evaluation logic as much. > To > >>>>>> implement the delegation model, the PDP > >>>>>> can use the normal XACML evaluation on admin requests, while > >>>>>> building the delegation graph. > >>>>>> > >>>>>> I think the second is a significant benefit. It would > >>>>>> significantly complicate both the administrative > >>>>>> spec > >>>>>> and the implementation if we need to define additional modes of > >>>>>> XACML policy evaluation. > >>>>> > >>>>> The delegation model is already a significant departure from > >>>>> normal XACML evaluation, > >>>>> what with building the delegation graph and forming > administrative > >>>>> requests. Those > >>>>> things would still be there. The complexity trade off is between > >>>>> category prefixing > >>>>> (which is not yet complete because it has unresolved issues) and > a > >>>>> simple boolean > >>>>> test during request processing to see if the kind of the policy > >>>>> matches the kind > >>>>> of the request (i.e., access versus administrative). That test is > >>>>> simple and efficient > >>>>> compared to category prefixing. > >>>>> > >>>>>> > >>>>>> What about changing the prefix so it works with all cases? > >>>>> > >>>>> The only thing that comes to mind that would be syntactically > >>>>> valid is a > >>>>> prefix to the scheme name. For example, http://example.com/foobar > >>>>> becomes > >>>>> delegated- http://example.com/foobar . > >>>>> > >>>>> > Or changing the admin category to something else > >>>>>> than it being based on a prefix? > >>>>> > >>>>> That's difficult without making changes to the core syntax. > >>>>> > >>>>> > By means of some other kind of algorithm, or maybe an explicit > >>>>> table? > >>>>> > >>>>> Labelling the policies would be much easier than a managing a > >>>>> mapping table. > >>>>> > >>>>> Regards, > >>>>> Steven > >>>>> > >>>>>> > >>>>>> Best regards, > >>>>>> Erik > >>>>>> > >>>>>> > >>>>>> On 2012-09-03 07:03, Steven Legg wrote: > >>>>>>> > >>>>>>> Hi Erik, > >>>>>>> > >>>>>>> On 1/09/2012 1:23 AM, Erik Rissanen wrote: > >>>>>>>> I don't think we change the delegation model in this way since > >>>>>>>> it would mean changing the core schema, > >>>>>>>> which > >>>>>>>> we really don't want to do at this stage. > >>>>>>> > >>>>>>> I originally suggested an XML attribute for the label, which > >>>>>>> would need > >>>>>>> a change to the core schema, but there is another way to label > the > >>>>>>> policies without changing the core schema and that is > substitution > >>>>>>> groups for Policy and PolicySet. For example: > >>>>>>> > >>>>>>> <xs:element name="AdministrativePolicy" > type="xacml:PolicyType" > >>>>>>> substitutionGroup="xacml:Policy"/> > >>>>>>> > >>>>>>> <xs:element name="AdministrativePolicySet" > >>>>>>> type="xacml:PolicySetType" > >>>>>>> substitutionGroup="xacml:PolicySet"/> > >>>>>>> > >>>>>>> In a way this is better than a simple XML attribute because it > >>>>>>> is more > >>>>>>> visually distinctive. It would be desirable for > >>>>>>> AdministrativePolicy > >>>>>>> and AdministrativePolicySet to be in the same namespace as > Policy > >>>>>>> and PolicySet, but if they have to be in their own namespace so > >>>>>>> be it. > >>>>>>> > >>>>>>> > Also, I think we did consider labeling policies like this in > >>>>>>> early > >>>>>>>> stages of the delegation work. I don't remember right now why > >>>>>>>> we did not go that way, but I suspect > >>>>>>>> there > >>>>>>>> was a reason. > >>>>>>> > >>>>>>> I've found and reported on a bunch of problems with category > >>>>>>> prefixing, > >>>>>>> so there are reasons to reconsider using labelling. If the > >>>>>>> purpose of > >>>>>>> the prefixing is just to ensure that administrative policies > aren't > >>>>>>> applicable when evaluating access requests, and vice versa, > then > >>>>>>> labelling is a simpler and cleaner way to achieve the same end. > >>>>>>> > >>>>>>> > Probably that the current mechanism is more flexible. > >>>>>>> > >>>>>>> It's more flexible in that it allows hybrid policies that are a > bit > >>>>>>> access policy and a bit administrative policy. I can't think of > a > >>>>>>> good reason to want to do that, and in any case, it is always > >>>>>>> possible > >>>>>>> to split a hybrid policy into a pure access policy and a pure > >>>>>>> administrative policy. I would happily forego this dubious > >>>>>>> flexibility > >>>>>>> to get rid of category prefixing and its problems. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Steven > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: xacml-help@lists.oasis-open.org >

20. Re: [xacml] Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

Recommend

Rich Levinson

Recommend

Remon Sinnema

36. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

Recommend

Erik Rissanen

Posted 12-19-2012 16:44

Hi Steven, On 2012-12-19 06:29, Steven Legg wrote: Hi Erik, On 19/12/2012 2:08 AM, Erik Rissanen wrote: Thanks Steven, Ok, so the difference which I had not noticed in your proposal is that you advocate that any admin request should always start from the top, You need to read more carefully. That was the fifth time I'd said it. > while I say that the reduction graph is formed within the nested policy set like before, except of course that we use labeling rather than categories to differentiate between admin and access policies. By doing nested reduction graphs, there are two benefits as I see it: - You don't need hybrids. - Someone can neatly package a complete policy set with nested admin policies in full, without having to be concerned about how this might interfere with any other "top level" policies. Could you refresh my memory again as to why you want to start reduction from the top? What are the benefits? I previously said this on the topic: ... "working out where to put an administrative policy under the current scheme is a burden policy writers can do without. Take the simple case where User A delegates all rights to User D. This is a very simple administrative policy that basically says "if the delegate is User D, then Permit". The issue is where to put it. User A needs to place it (by copy or by reference) in every policy set where User D will potentially be creating access policies. Furthermore, as new policy sets are created that User D might put policies into, User A will have to put the administrative policy in there as well. Conversely, if User A isn't thorough or proactive in placing the administrative policy, then User D will be limited in the rights he or she can actually exercise. Compounding the difficulties is the fact that in the general case, because of multi-valued attributes and augmentation of the delegate category by a context handler, practially any untrusted policy can be authorized by any administrative policy. It all depends on the request context. It is only by making assumptions about certain attributes being single-valued or by knowing about correlations between the attributes of an access subject that we can begin to predict which untrusted policies will be authorized by which administrative policies in the absence of any specific request context. These are things that users shouldn't have to be concerned with when creating administrative policies." In the current scheme an administrative policy can only authorize an untrusted policy that is a sibling or a sibling of an ancestor. This is a severe limitation when the scope of an administrative policy is wider than any one of the untrusted policies that it authorizes. It is correct that the admin policy has to be a sibling in the current scheme, and my proposed labeling scheme. I don't see this as a major issue, rather I find it nice, because it means that this allows recursive nesting of policies, which will not interfere with each other. I don't understand your second concern in the text you quoted above. It is true that XACML policies are written with a set of possible request contexts in mind. An admin policy can use any attributes it desires to constrain its applicability in any way, so it is quite clear which requests it will authorize for which delegates. It is true that the support relation between an access policy and an admin policy is resolved at runtime, so the links are not static. A policy may support another or not, depending on the situation/context. However, this is a feature, not a bug, since it allows an access policy author to "consolidate authority", that is he can write an access policy which is in itself greater in scope than any individual admin policy which authorizes him. Depending on the situation, the access policy would be supported by different admin policies. I also said this: [ In the current scheme ] "the effect of a nested AdminPolicy depends on where evaluation of the administrative request begins. Suppose that the nested AdminPolicy evaluates to Deny. If the evaluation of the administrative request started inside the AdminPolicySet, then the AdminPolicy has no effect because it doesn't add an arc to the reduction graph. If the evaluation of the administrative request started outside the AdminPolicySet, then the Deny result from the AdminPolicy is combined with the results from its siblings according to the combining algorithm of the AdminPolicySet. If that combining algorithm is deny-overrides, then the Deny result overrides any Permit results from the siblings. That sort of variability will make delegation hard for users to understand." Evaluating administrative requests from the top means that the result of an administrative policy is always combined with the results of its siblings according to the combining algorithm of the policy set in which it is found - with no exceptions. Yes, that is true, but I would not expect anyone to use delegated admin policies inside an admin policy set. (In fact, we could forbid that explicitly.) Also, I am not sure it's a lot easier to grasp the big picture in case of nested untrusted admin policies even if the evaluation jumps up to the top level for each untrusted admin policy. It's going to melt most people's brain anyway. ;-) And I said this: [ In the current scheme ] "evaluation of an administrative request always starts with the pair-wise consideration of siblings of the policy being reduced. It is a process that is different from the normal processing of a combining algorithm and, in fact, completely disregards the combining algorithm of the policy set that contains the access policy and its sibling administrative policies. Starting the evaluation of the administrative request at the top (just like an access request) would be simpler to manage and easier for users to get their heads around." When I read this, I am not sure, but do you imply that there is no reduction graph construction at the top level. BTW, what does the reduction graph look like in your proposal? Which policies participate in it? How is it built? Best regards, Erik Regards, Steven Best regards, Erik On 2012-12-18 07:17, Steven Legg wrote: Hi Erik, On 18/12/2012 2:32 AM, Erik Rissanen wrote: On 2012-12-14 04:28, Steven Legg wrote: On 13/12/2012 11:36 PM, Erik Rissanen wrote: > So why do you allow for the hybrid? To overlay the administrative and access policy set hierarchies. Some folks have expressed a dislike for a complete separation. I don't see that you need hybrids even if the admin hierarchy is overlaid. Can you give an example? Suppose I want to write a bunch of admin policies that all relate to a resource with a resource-id of "printer", so I factor out the resource-id test and wrap the admin policies in an admin policy set like so: AdminPolicySet { PolicySetId: PS1 Target: resource-id="printer" AdminPolicy { PolicyId: P1 ... } AdminPolicy { PolicyId: P2 ... } } Along comes the delegate, who creates some access policies that relate to the resource with a resource-id of "printer". If the delegate factors out the resource-id test and wraps the access policies in an access policy set it looks like this: PolicySet { PolicySetId: PS2 Target: resource-id="printer" Policy { PolicyId: P3 ... } Policy { PolicyId: P4 ... } } This represents a complete separation of access and administrative policy. In my proposal I don't allow AdminPolicy in a PolicySet, or Policy in an AdminPolicySet, not because it is harmful, but because it is pointless. Recalling that I am proposing evaluating administrative requests from the top, an AdminPolicy in a PolicySet will never get evaluated because the PolicySet is not applicable to an administrative request. Likewise, a Policy in an AdminPolicySet will never get evaluated because the AdminPolicySet is not applicable to an access request. In order to take advantage of the common targets for the two policy sets above and merge them into one I need a policy set that is applicable for both access requests and administrative requests. That thing is the HybridPolicySet: HybridPolicySet { PolicySetId: PS3 Target: resource-id="printer" AdminPolicy { PolicyId: P1 ... } AdminPolicy { PolicyId: P2 ... } Policy { PolicyId: P3 ... } Policy { PolicyId: P4 ... } } Regards, Steven

37. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

Recommend

Steven Legg

Posted 12-20-2012 06:22

Hi Erik, On 20/12/2012 3:43 AM, Erik Rissanen wrote: Hi Steven, On 2012-12-19 06:29, Steven Legg wrote: Hi Erik, On 19/12/2012 2:08 AM, Erik Rissanen wrote: Thanks Steven, Ok, so the difference which I had not noticed in your proposal is that you advocate that any admin request should always start from the top, You need to read more carefully. That was the fifth time I'd said it. > while I say that the reduction graph is formed within the nested policy set like before, except of course that we use labeling rather than categories to differentiate between admin and access policies. By doing nested reduction graphs, there are two benefits as I see it: - You don't need hybrids. - Someone can neatly package a complete policy set with nested admin policies in full, without having to be concerned about how this might interfere with any other "top level" policies. Could you refresh my memory again as to why you want to start reduction from the top? What are the benefits? I previously said this on the topic: ... "working out where to put an administrative policy under the current scheme is a burden policy writers can do without. Take the simple case where User A delegates all rights to User D. This is a very simple administrative policy that basically says "if the delegate is User D, then Permit". The issue is where to put it. User A needs to place it (by copy or by reference) in every policy set where User D will potentially be creating access policies. Furthermore, as new policy sets are created that User D might put policies into, User A will have to put the administrative policy in there as well. Conversely, if User A isn't thorough or proactive in placing the administrative policy, then User D will be limited in the rights he or she can actually exercise. Compounding the difficulties is the fact that in the general case, because of multi-valued attributes and augmentation of the delegate category by a context handler, practially any untrusted policy can be authorized by any administrative policy. It all depends on the request context. It is only by making assumptions about certain attributes being single-valued or by knowing about correlations between the attributes of an access subject that we can begin to predict which untrusted policies will be authorized by which administrative policies in the absence of any specific request context. These are things that users shouldn't have to be concerned with when creating administrative policies." In the current scheme an administrative policy can only authorize an untrusted policy that is a sibling or a sibling of an ancestor. This is a severe limitation when the scope of an administrative policy is wider than any one of the untrusted policies that it authorizes. It is correct that the admin policy has to be a sibling in the current scheme, and my proposed labeling scheme. I don't see this as a major issue, rather I find it nice, because it means that this allows recursive nesting of policies, which will not interfere with each other. That is still possible with HybridPolicySet and evaluation from the top. The only difference between the original access request and any administrative requests subsequently spawned from it because of untrusted policies is that the administrative requests will have added categories for delegate and delegation-info. If the targets of the HybridPolicySet and its ancestor HybridPolicySets don't reference these categories (and there is no good reason for them to do so), then a PDP evaluating an administrative request will find its way back to the same HybridPolicySet where the untrusted policy was encountered. If the policy set hierarchy is constructed such that policy sets don't interfere with each other with respect to access requests, then they won't interfere with each other with respect to the corresponding administrative requests. Mostly I find that I want to put the administrative policies higher up in the policy set hierarchy, because they have a wider scope. I don't understand your second concern in the text you quoted above. It is true that XACML policies are written with a set of possible request contexts in mind. An admin policy can use any attributes it desires to constrain its applicability in any way, so it is quite clear which requests it will authorize for which delegates. It is true that the support relation between an access policy and an admin policy is resolved at runtime, so the links are not static. A policy may support another or not, depending on the situation/context. However, this is a feature, not a bug, since it allows an access policy author to "consolidate authority", that is he can write an access policy which is in itself greater in scope than any individual admin policy which authorizes him. Depending on the situation, the access policy would be supported by different admin policies. That feature is not something I'm proposing changing. The limitation that authorizing administrative policies have to be a sibling or descendant of a sibling is just not in harmony with it. If a writer of an untrusted access policy doesn't know for certain which administrative policy or policies will authorize it, how can they be sure they have put it in a place that will allow it to be authorized ? The writers of administrative policies have the similar problem of not being sure they have put the administrative policy in the places it needs to be to authorize the access policies yet to come. Evaluating administrative requests from the top removes sibling adjacency as a concern and the feature operates unfettered. I also said this: [ In the current scheme ] "the effect of a nested AdminPolicy depends on where evaluation of the administrative request begins. Suppose that the nested AdminPolicy evaluates to Deny. If the evaluation of the administrative request started inside the AdminPolicySet, then the AdminPolicy has no effect because it doesn't add an arc to the reduction graph. If the evaluation of the administrative request started outside the AdminPolicySet, then the Deny result from the AdminPolicy is combined with the results from its siblings according to the combining algorithm of the AdminPolicySet. If that combining algorithm is deny-overrides, then the Deny result overrides any Permit results from the siblings. That sort of variability will make delegation hard for users to understand." Evaluating administrative requests from the top means that the result of an administrative policy is always combined with the results of its siblings according to the combining algorithm of the policy set in which it is found - with no exceptions. Yes, that is true, but I would not expect anyone to use delegated admin policies inside an admin policy set. (In fact, we could forbid that explicitly.) Also, I am not sure it's a lot easier to grasp the big picture in case of nested untrusted admin policies even if the evaluation jumps up to the top level for each untrusted admin policy. It's going to melt most people's brain anyway. ;-) In the current scheme, the reduction of an untrusted policy considers each of the sibling administrative policies by evaluating the administrative request against them. The effect of the reduction graph is to combine the results of those evaluations in a way that is similar to, though not exactly, the permit-overrides combining algorithm. This is the only predictable way to combine the results of administrative policies, whether I like it or not, and I don't. I particularly want to use deny-overrides. If I put the administrative policies inside an administrative policy set with the combining algorithm I want, then that's not reliable, for the reasons above. The practice might as well be forbidden if it can't be trusted, but either way, policy writers are condemned to only combine the results of administrative policies according to something like permit-overrides. Evaluating administrative policies from the top every time means that policy writers have the flexibility to use whatever combining algorithm they want, knowing that it will always work as specified. And I said this: [ In the current scheme ] "evaluation of an administrative request always starts with the pair-wise consideration of siblings of the policy being reduced. It is a process that is different from the normal processing of a combining algorithm and, in fact, completely disregards the combining algorithm of the policy set that contains the access policy and its sibling administrative policies. Starting the evaluation of the administrative request at the top (just like an access request) would be simpler to manage and easier for users to get their heads around." When I read this, I am not sure, but do you imply that there is no reduction graph construction at the top level. Correct. The administrative request is evaluated according to section 7.17 of the core, subject to the additional requirement that any access policy or access policy set is automatically NotApplicable. > BTW, what does the reduction graph look like in your proposal? There isn't one. Regards, Steven > Which policies participate in it? How is it built? Best regards, Erik Regards, Steven Best regards, Erik On 2012-12-18 07:17, Steven Legg wrote: Hi Erik, On 18/12/2012 2:32 AM, Erik Rissanen wrote: On 2012-12-14 04:28, Steven Legg wrote: On 13/12/2012 11:36 PM, Erik Rissanen wrote: > So why do you allow for the hybrid? To overlay the administrative and access policy set hierarchies. Some folks have expressed a dislike for a complete separation. I don't see that you need hybrids even if the admin hierarchy is overlaid. Can you give an example? Suppose I want to write a bunch of admin policies that all relate to a resource with a resource-id of "printer", so I factor out the resource-id test and wrap the admin policies in an admin policy set like so: AdminPolicySet { PolicySetId: PS1 Target: resource-id="printer" AdminPolicy { PolicyId: P1 ... } AdminPolicy { PolicyId: P2 ... } } Along comes the delegate, who creates some access policies that relate to the resource with a resource-id of "printer". If the delegate factors out the resource-id test and wraps the access policies in an access policy set it looks like this: PolicySet { PolicySetId: PS2 Target: resource-id="printer" Policy { PolicyId: P3 ... } Policy { PolicyId: P4 ... } } This represents a complete separation of access and administrative policy. In my proposal I don't allow AdminPolicy in a PolicySet, or Policy in an AdminPolicySet, not because it is harmful, but because it is pointless. Recalling that I am proposing evaluating administrative requests from the top, an AdminPolicy in a PolicySet will never get evaluated because the PolicySet is not applicable to an administrative request. Likewise, a Policy in an AdminPolicySet will never get evaluated because the AdminPolicySet is not applicable to an access request. In order to take advantage of the common targets for the two policy sets above and merge them into one I need a policy set that is applicable for both access requests and administrative requests. That thing is the HybridPolicySet: HybridPolicySet { PolicySetId: PS3 Target: resource-id="printer" AdminPolicy { PolicyId: P1 ... } AdminPolicy { PolicyId: P2 ... } Policy { PolicyId: P3 ... } Policy { PolicyId: P4 ... } } Regards, Steven

38. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

Recommend

Erik Rissanen

Posted 12-20-2012 09:27

Hi Steven, Ok, so in your proposal there is no reduction graph. Early working drafts of the delegation profile were like this, so you are suggesting that we revert back to that old model. The TC introduced the reduction graph because there are issues with the model you propose. The main reasons the TC moved on from the model you propose were (if I recall it correctly): - We did not want to have the concept of a negative administrative authority, that is, someone can deny someone else to authorize an administrative request. I am not talking about combining policies and rules within an administrative policy(set) since this is just a matter of defining the scope of the administrative policy using XACML constructs. The problem is how to combine administrative policies from multiple authors, which might conflict. The way the reduction graph now works it simple and well defined. - You have to deal with indeterminate values from both access policies and admin policies. This is not so simple if the policies themselves are not trusted with certainty. For instance, someone who puts an indeterminate policy at the top level could cause interference. - The reduction graph search is also computationally efficient. Some forms of the early delegation model were NP-complete, but that was due to the ability to restrict more than one step in the delegation chain. I am not sure if there are any issues with your proposed model though. /Erik On 2012-12-20 07:22, Steven Legg wrote: Hi Erik, On 20/12/2012 3:43 AM, Erik Rissanen wrote: Hi Steven, On 2012-12-19 06:29, Steven Legg wrote: Hi Erik, On 19/12/2012 2:08 AM, Erik Rissanen wrote: Thanks Steven, Ok, so the difference which I had not noticed in your proposal is that you advocate that any admin request should always start from the top, You need to read more carefully. That was the fifth time I'd said it. > while I say that the reduction graph is formed within the nested policy set like before, except of course that we use labeling rather than categories to differentiate between admin and access policies. By doing nested reduction graphs, there are two benefits as I see it: - You don't need hybrids. - Someone can neatly package a complete policy set with nested admin policies in full, without having to be concerned about how this might interfere with any other "top level" policies. Could you refresh my memory again as to why you want to start reduction from the top? What are the benefits? I previously said this on the topic: ... "working out where to put an administrative policy under the current scheme is a burden policy writers can do without. Take the simple case where User A delegates all rights to User D. This is a very simple administrative policy that basically says "if the delegate is User D, then Permit". The issue is where to put it. User A needs to place it (by copy or by reference) in every policy set where User D will potentially be creating access policies. Furthermore, as new policy sets are created that User D might put policies into, User A will have to put the administrative policy in there as well. Conversely, if User A isn't thorough or proactive in placing the administrative policy, then User D will be limited in the rights he or she can actually exercise. Compounding the difficulties is the fact that in the general case, because of multi-valued attributes and augmentation of the delegate category by a context handler, practially any untrusted policy can be authorized by any administrative policy. It all depends on the request context. It is only by making assumptions about certain attributes being single-valued or by knowing about correlations between the attributes of an access subject that we can begin to predict which untrusted policies will be authorized by which administrative policies in the absence of any specific request context. These are things that users shouldn't have to be concerned with when creating administrative policies." In the current scheme an administrative policy can only authorize an untrusted policy that is a sibling or a sibling of an ancestor. This is a severe limitation when the scope of an administrative policy is wider than any one of the untrusted policies that it authorizes. It is correct that the admin policy has to be a sibling in the current scheme, and my proposed labeling scheme. I don't see this as a major issue, rather I find it nice, because it means that this allows recursive nesting of policies, which will not interfere with each other. That is still possible with HybridPolicySet and evaluation from the top. The only difference between the original access request and any administrative requests subsequently spawned from it because of untrusted policies is that the administrative requests will have added categories for delegate and delegation-info. If the targets of the HybridPolicySet and its ancestor HybridPolicySets don't reference these categories (and there is no good reason for them to do so), then a PDP evaluating an administrative request will find its way back to the same HybridPolicySet where the untrusted policy was encountered. If the policy set hierarchy is constructed such that policy sets don't interfere with each other with respect to access requests, then they won't interfere with each other with respect to the corresponding administrative requests. Mostly I find that I want to put the administrative policies higher up in the policy set hierarchy, because they have a wider scope. I don't understand your second concern in the text you quoted above. It is true that XACML policies are written with a set of possible request contexts in mind. An admin policy can use any attributes it desires to constrain its applicability in any way, so it is quite clear which requests it will authorize for which delegates. It is true that the support relation between an access policy and an admin policy is resolved at runtime, so the links are not static. A policy may support another or not, depending on the situation/context. However, this is a feature, not a bug, since it allows an access policy author to "consolidate authority", that is he can write an access policy which is in itself greater in scope than any individual admin policy which authorizes him. Depending on the situation, the access policy would be supported by different admin policies. That feature is not something I'm proposing changing. The limitation that authorizing administrative policies have to be a sibling or descendant of a sibling is just not in harmony with it. If a writer of an untrusted access policy doesn't know for certain which administrative policy or policies will authorize it, how can they be sure they have put it in a place that will allow it to be authorized ? The writers of administrative policies have the similar problem of not being sure they have put the administrative policy in the places it needs to be to authorize the access policies yet to come. Evaluating administrative requests from the top removes sibling adjacency as a concern and the feature operates unfettered. I also said this: [ In the current scheme ] "the effect of a nested AdminPolicy depends on where evaluation of the administrative request begins. Suppose that the nested AdminPolicy evaluates to Deny. If the evaluation of the administrative request started inside the AdminPolicySet, then the AdminPolicy has no effect because it doesn't add an arc to the reduction graph. If the evaluation of the administrative request started outside the AdminPolicySet, then the Deny result from the AdminPolicy is combined with the results from its siblings according to the combining algorithm of the AdminPolicySet. If that combining algorithm is deny-overrides, then the Deny result overrides any Permit results from the siblings. That sort of variability will make delegation hard for users to understand." Evaluating administrative requests from the top means that the result of an administrative policy is always combined with the results of its siblings according to the combining algorithm of the policy set in which it is found - with no exceptions. Yes, that is true, but I would not expect anyone to use delegated admin policies inside an admin policy set. (In fact, we could forbid that explicitly.) Also, I am not sure it's a lot easier to grasp the big picture in case of nested untrusted admin policies even if the evaluation jumps up to the top level for each untrusted admin policy. It's going to melt most people's brain anyway. ;-) In the current scheme, the reduction of an untrusted policy considers each of the sibling administrative policies by evaluating the administrative request against them. The effect of the reduction graph is to combine the results of those evaluations in a way that is similar to, though not exactly, the permit-overrides combining algorithm. This is the only predictable way to combine the results of administrative policies, whether I like it or not, and I don't. I particularly want to use deny-overrides. If I put the administrative policies inside an administrative policy set with the combining algorithm I want, then that's not reliable, for the reasons above. The practice might as well be forbidden if it can't be trusted, but either way, policy writers are condemned to only combine the results of administrative policies according to something like permit-overrides. Evaluating administrative policies from the top every time means that policy writers have the flexibility to use whatever combining algorithm they want, knowing that it will always work as specified. And I said this: [ In the current scheme ] "evaluation of an administrative request always starts with the pair-wise consideration of siblings of the policy being reduced. It is a process that is different from the normal processing of a combining algorithm and, in fact, completely disregards the combining algorithm of the policy set that contains the access policy and its sibling administrative policies. Starting the evaluation of the administrative request at the top (just like an access request) would be simpler to manage and easier for users to get their heads around." When I read this, I am not sure, but do you imply that there is no reduction graph construction at the top level. Correct. The administrative request is evaluated according to section 7.17 of the core, subject to the additional requirement that any access policy or access policy set is automatically NotApplicable. > BTW, what does the reduction graph look like in your proposal? There isn't one. Regards, Steven > Which policies participate in it? How is it built? Best regards, Erik Regards, Steven Best regards, Erik On 2012-12-18 07:17, Steven Legg wrote: Hi Erik, On 18/12/2012 2:32 AM, Erik Rissanen wrote: On 2012-12-14 04:28, Steven Legg wrote: On 13/12/2012 11:36 PM, Erik Rissanen wrote: > So why do you allow for the hybrid? To overlay the administrative and access policy set hierarchies. Some folks have expressed a dislike for a complete separation. I don't see that you need hybrids even if the admin hierarchy is overlaid. Can you give an example? Suppose I want to write a bunch of admin policies that all relate to a resource with a resource-id of "printer", so I factor out the resource-id test and wrap the admin policies in an admin policy set like so: AdminPolicySet { PolicySetId: PS1 Target: resource-id="printer" AdminPolicy { PolicyId: P1 ... } AdminPolicy { PolicyId: P2 ... } } Along comes the delegate, who creates some access policies that relate to the resource with a resource-id of "printer". If the delegate factors out the resource-id test and wraps the access policies in an access policy set it looks like this: PolicySet { PolicySetId: PS2 Target: resource-id="printer" Policy { PolicyId: P3 ... } Policy { PolicyId: P4 ... } } This represents a complete separation of access and administrative policy. In my proposal I don't allow AdminPolicy in a PolicySet, or Policy in an AdminPolicySet, not because it is harmful, but because it is pointless. Recalling that I am proposing evaluating administrative requests from the top, an AdminPolicy in a PolicySet will never get evaluated because the PolicySet is not applicable to an administrative request. Likewise, a Policy in an AdminPolicySet will never get evaluated because the AdminPolicySet is not applicable to an access request. In order to take advantage of the common targets for the two policy sets above and merge them into one I need a policy set that is applicable for both access requests and administrative requests. That thing is the HybridPolicySet: HybridPolicySet { PolicySetId: PS3 Target: resource-id="printer" AdminPolicy { PolicyId: P1 ... } AdminPolicy { PolicyId: P2 ... } Policy { PolicyId: P3 ... } Policy { PolicyId: P4 ... } } Regards, Steven

39. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

Recommend

Steven Legg

Posted 01-24-2013 06:37

Hi Erik, On 20/12/2012 8:26 PM, Erik Rissanen wrote: Hi Steven, Ok, so in your proposal there is no reduction graph. Early working drafts of the delegation profile were like this, so you are suggesting that we revert back to that old model. Well, something like it I suppose. I haven't seen the early drafts. The TC introduced the reduction graph because there are issues with the model you propose. The main reasons the TC moved on from the model you propose were (if I recall it correctly): A case of the cure being worse than the disease :-). - We did not want to have the concept of a negative administrative authority, that is, someone can deny someone else to authorize an administrative request. I am not talking about combining policies and rules within an administrative policy(set) since this is just a matter of defining the scope of the administrative policy using XACML constructs. The problem is how to combine administrative policies from multiple authors, which might conflict. The way the reduction graph now works it simple and well defined. For delegates to interfere with each other's authorizations they need to have been given authority over the same scope. Having two or more people independently administering the same scope is asking for trouble anyway. I had concluded some time ago that the administration profile didn't have a good way of handling this situation and that one shouldn't go there. If two or more people are given authority over the same scope then they need to be cooperating, in which case there isn't a problem. A better idea is to arrange that those people have the same issuer identity so that they jointly own all the policies for the common scope, which is analogous to the situation for all the people that are permitted to manage trusted policies. But if you want to assume independent administrators for the same scope and only allow them to permit authority, then a new attribute could be added to the delegation-info to give control over whether deny administrative policies are authorized. - You have to deal with indeterminate values from both access policies and admin policies. This is not so simple if the policies themselves are not trusted with certainty. For instance, someone who puts an indeterminate policy at the top level could cause interference. An untrusted policy has no effect if there is no administrative policy that authorizes it, regardless of where it might be, and a PAP shouldn't be allowing just anybody to create trusted policies. The danger is if the PDP gets an error without being able to tell whether the policy is trusted or untrusted. It is easy for the PDP to guard against that by only accepting policies that are valid according to the XML Schema. And PAPs shouldn't allow schema-invalid policies to be created either, for extra safety. In any case, the reduction graph doesn't solve this potential problem. It only constrains the scope within which it is a problem. If administrative policies are near the top level, which would imply that untrusted policies can appear there too, then the scope hasn't been constrained by much at all. If an untrusted policy evaluates to indeterminate and there is an administrative policy that authorizes it, then the delegate is operating within the scope of authority given to them, for good or ill. We can't legislate against stupidity. - The reduction graph search is also computationally efficient. Some forms of the early delegation model were NP-complete, but that was due to the ability to restrict more than one step in the delegation chain. I am not sure if there are any issues with your proposed model though. I'm not changing anything about how authority is established, only where the PDP looks for authorizing policies and combines them. As it stands at the moment, I find that I have to put a copy of each administrative policy in just about every policy set because it isn't generally possible to determine which administrative policy will authorize which access policy without reference to a specific request context. That means that just about every administrative policy is considered as a candidate during every reduction attempt using the reduction graph, regardless of where it happens. Evaluating administrative policies from the top means that in the worst case every administrative policy is still a candidate for consideration during reduction, but at least they won't be duplicated all over the place. In practice I think the search will be improved because the targets on administrative (or hybrid) policy sets will allow large numbers of administrative policies to be disregarded during the search. Indexing of the administrative policy sets will also allow some proportion of them to be ignored without even getting to the point of checking their targets. Regards, Steven /Erik On 2012-12-20 07:22, Steven Legg wrote: Hi Erik, On 20/12/2012 3:43 AM, Erik Rissanen wrote: Hi Steven, On 2012-12-19 06:29, Steven Legg wrote: Hi Erik, On 19/12/2012 2:08 AM, Erik Rissanen wrote: Thanks Steven, Ok, so the difference which I had not noticed in your proposal is that you advocate that any admin request should always start from the top, You need to read more carefully. That was the fifth time I'd said it. > while I say that the reduction graph is formed within the nested policy set like before, except of course that we use labeling rather than categories to differentiate between admin and access policies. By doing nested reduction graphs, there are two benefits as I see it: - You don't need hybrids. - Someone can neatly package a complete policy set with nested admin policies in full, without having to be concerned about how this might interfere with any other "top level" policies. Could you refresh my memory again as to why you want to start reduction from the top? What are the benefits? I previously said this on the topic: ... "working out where to put an administrative policy under the current scheme is a burden policy writers can do without. Take the simple case where User A delegates all rights to User D. This is a very simple administrative policy that basically says "if the delegate is User D, then Permit". The issue is where to put it. User A needs to place it (by copy or by reference) in every policy set where User D will potentially be creating access policies. Furthermore, as new policy sets are created that User D might put policies into, User A will have to put the administrative policy in there as well. Conversely, if User A isn't thorough or proactive in placing the administrative policy, then User D will be limited in the rights he or she can actually exercise. Compounding the difficulties is the fact that in the general case, because of multi-valued attributes and augmentation of the delegate category by a context handler, practially any untrusted policy can be authorized by any administrative policy. It all depends on the request context. It is only by making assumptions about certain attributes being single-valued or by knowing about correlations between the attributes of an access subject that we can begin to predict which untrusted policies will be authorized by which administrative policies in the absence of any specific request context. These are things that users shouldn't have to be concerned with when creating administrative policies." In the current scheme an administrative policy can only authorize an untrusted policy that is a sibling or a sibling of an ancestor. This is a severe limitation when the scope of an administrative policy is wider than any one of the untrusted policies that it authorizes. It is correct that the admin policy has to be a sibling in the current scheme, and my proposed labeling scheme. I don't see this as a major issue, rather I find it nice, because it means that this allows recursive nesting of policies, which will not interfere with each other. That is still possible with HybridPolicySet and evaluation from the top. The only difference between the original access request and any administrative requests subsequently spawned from it because of untrusted policies is that the administrative requests will have added categories for delegate and delegation-info. If the targets of the HybridPolicySet and its ancestor HybridPolicySets don't reference these categories (and there is no good reason for them to do so), then a PDP evaluating an administrative request will find its way back to the same HybridPolicySet where the untrusted policy was encountered. If the policy set hierarchy is constructed such that policy sets don't interfere with each other with respect to access requests, then they won't interfere with each other with respect to the corresponding administrative requests. Mostly I find that I want to put the administrative policies higher up in the policy set hierarchy, because they have a wider scope. I don't understand your second concern in the text you quoted above. It is true that XACML policies are written with a set of possible request contexts in mind. An admin policy can use any attributes it desires to constrain its applicability in any way, so it is quite clear which requests it will authorize for which delegates. It is true that the support relation between an access policy and an admin policy is resolved at runtime, so the links are not static. A policy may support another or not, depending on the situation/context. However, this is a feature, not a bug, since it allows an access policy author to "consolidate authority", that is he can write an access policy which is in itself greater in scope than any individual admin policy which authorizes him. Depending on the situation, the access policy would be supported by different admin policies. That feature is not something I'm proposing changing. The limitation that authorizing administrative policies have to be a sibling or descendant of a sibling is just not in harmony with it. If a writer of an untrusted access policy doesn't know for certain which administrative policy or policies will authorize it, how can they be sure they have put it in a place that will allow it to be authorized ? The writers of administrative policies have the similar problem of not being sure they have put the administrative policy in the places it needs to be to authorize the access policies yet to come. Evaluating administrative requests from the top removes sibling adjacency as a concern and the feature operates unfettered. I also said this: [ In the current scheme ] "the effect of a nested AdminPolicy depends on where evaluation of the administrative request begins. Suppose that the nested AdminPolicy evaluates to Deny. If the evaluation of the administrative request started inside the AdminPolicySet, then the AdminPolicy has no effect because it doesn't add an arc to the reduction graph. If the evaluation of the administrative request started outside the AdminPolicySet, then the Deny result from the AdminPolicy is combined with the results from its siblings according to the combining algorithm of the AdminPolicySet. If that combining algorithm is deny-overrides, then the Deny result overrides any Permit results from the siblings. That sort of variability will make delegation hard for users to understand." Evaluating administrative requests from the top means that the result of an administrative policy is always combined with the results of its siblings according to the combining algorithm of the policy set in which it is found - with no exceptions. Yes, that is true, but I would not expect anyone to use delegated admin policies inside an admin policy set. (In fact, we could forbid that explicitly.) Also, I am not sure it's a lot easier to grasp the big picture in case of nested untrusted admin policies even if the evaluation jumps up to the top level for each untrusted admin policy. It's going to melt most people's brain anyway. ;-) In the current scheme, the reduction of an untrusted policy considers each of the sibling administrative policies by evaluating the administrative request against them. The effect of the reduction graph is to combine the results of those evaluations in a way that is similar to, though not exactly, the permit-overrides combining algorithm. This is the only predictable way to combine the results of administrative policies, whether I like it or not, and I don't. I particularly want to use deny-overrides. If I put the administrative policies inside an administrative policy set with the combining algorithm I want, then that's not reliable, for the reasons above. The practice might as well be forbidden if it can't be trusted, but either way, policy writers are condemned to only combine the results of administrative policies according to something like permit-overrides. Evaluating administrative policies from the top every time means that policy writers have the flexibility to use whatever combining algorithm they want, knowing that it will always work as specified. And I said this: [ In the current scheme ] "evaluation of an administrative request always starts with the pair-wise consideration of siblings of the policy being reduced. It is a process that is different from the normal processing of a combining algorithm and, in fact, completely disregards the combining algorithm of the policy set that contains the access policy and its sibling administrative policies. Starting the evaluation of the administrative request at the top (just like an access request) would be simpler to manage and easier for users to get their heads around." When I read this, I am not sure, but do you imply that there is no reduction graph construction at the top level. Correct. The administrative request is evaluated according to section 7.17 of the core, subject to the additional requirement that any access policy or access policy set is automatically NotApplicable. > BTW, what does the reduction graph look like in your proposal? There isn't one. Regards, Steven > Which policies participate in it? How is it built? Best regards, Erik Regards, Steven Best regards, Erik On 2012-12-18 07:17, Steven Legg wrote: Hi Erik, On 18/12/2012 2:32 AM, Erik Rissanen wrote: On 2012-12-14 04:28, Steven Legg wrote: On 13/12/2012 11:36 PM, Erik Rissanen wrote: > So why do you allow for the hybrid? To overlay the administrative and access policy set hierarchies. Some folks have expressed a dislike for a complete separation. I don't see that you need hybrids even if the admin hierarchy is overlaid. Can you give an example? Suppose I want to write a bunch of admin policies that all relate to a resource with a resource-id of "printer", so I factor out the resource-id test and wrap the admin policies in an admin policy set like so: AdminPolicySet { PolicySetId: PS1 Target: resource-id="printer" AdminPolicy { PolicyId: P1 ... } AdminPolicy { PolicyId: P2 ... } } Along comes the delegate, who creates some access policies that relate to the resource with a resource-id of "printer". If the delegate factors out the resource-id test and wraps the access policies in an access policy set it looks like this: PolicySet { PolicySetId: PS2 Target: resource-id="printer" Policy { PolicyId: P3 ... } Policy { PolicyId: P4 ... } } This represents a complete separation of access and administrative policy. In my proposal I don't allow AdminPolicy in a PolicySet, or Policy in an AdminPolicySet, not because it is harmful, but because it is pointless. Recalling that I am proposing evaluating administrative requests from the top, an AdminPolicy in a PolicySet will never get evaluated because the PolicySet is not applicable to an administrative request. Likewise, a Policy in an AdminPolicySet will never get evaluated because the AdminPolicySet is not applicable to an access request. In order to take advantage of the common targets for the two policy sets above and merge them into one I need a policy set that is applicable for both access requests and administrative requests. That thing is the HybridPolicySet: HybridPolicySet { PolicySetId: PS3 Target: resource-id="printer" AdminPolicy { PolicyId: P1 ... } AdminPolicy { PolicyId: P2 ... } Policy { PolicyId: P3 ... } Policy { PolicyId: P4 ... } } Regards, Steven

40. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

Recommend

Erik Rissanen

Posted 01-24-2013 09:04

Hi Steven, On 2013-01-24 07:36, Steven Legg wrote: Hi Erik, On 20/12/2012 8:26 PM, Erik Rissanen wrote: Hi Steven, Ok, so in your proposal there is no reduction graph. Early working drafts of the delegation profile were like this, so you are suggesting that we revert back to that old model. Well, something like it I suppose. I haven't seen the early drafts. The TC introduced the reduction graph because there are issues with the model you propose. The main reasons the TC moved on from the model you propose were (if I recall it correctly): A case of the cure being worse than the disease :-). - We did not want to have the concept of a negative administrative authority, that is, someone can deny someone else to authorize an administrative request. I am not talking about combining policies and rules within an administrative policy(set) since this is just a matter of defining the scope of the administrative policy using XACML constructs. The problem is how to combine administrative policies from multiple authors, which might conflict. The way the reduction graph now works it simple and well defined. For delegates to interfere with each other's authorizations they need to have been given authority over the same scope. Having two or more people independently administering the same scope is asking for trouble anyway. I had concluded some time ago that the administration profile didn't have a good way of handling this situation and that one shouldn't go there. If two or more people are given authority over the same scope then they need to be cooperating, in which case there isn't a problem. A better idea is to arrange that those people have the same issuer identity so that they jointly own all the policies for the common scope, which is analogous to the situation for all the people that are permitted to manage trusted policies. But if you want to assume independent administrators for the same scope and only allow them to permit authority, then a new attribute could be added to the delegation-info to give control over whether deny administrative policies are authorized. My point was that if I understand your proposal, you use normal combining algorithms during reduction, instead of a graph search (you said that there is no graph search in your proposal). That means that in the your model it is possible to have conflicts like this. This does not happen in the current working draft model because it does not have negative admin rights at all, in contrast with your model which has them. - You have to deal with indeterminate values from both access policies and admin policies. This is not so simple if the policies themselves are not trusted with certainty. For instance, someone who puts an indeterminate policy at the top level could cause interference. An untrusted policy has no effect if there is no administrative policy that authorizes it, regardless of where it might be, and a PAP shouldn't be allowing just anybody to create trusted policies. The danger is if the PDP gets an error without being able to tell whether the policy is trusted or untrusted. It is easy for the PDP to guard against that by only accepting policies that are valid according to the XML Schema. And PAPs shouldn't allow schema-invalid policies to be created either, for extra safety. In any case, the reduction graph doesn't solve this potential problem. It only constrains the scope within which it is a problem. If administrative policies are near the top level, which would imply that untrusted policies can appear there too, then the scope hasn't been constrained by much at all. If an untrusted policy evaluates to indeterminate and there is an administrative policy that authorizes it, then the delegate is operating within the scope of authority given to them, for good or ill. We can't legislate against stupidity. My point was that in order to know whether an administrative policy authorizes another policy when it evaluates to indeterminate, means that one has to perform a special type of graph search for that policy. This is described in the current working draft model. If all you do is to recursive call the policies with administrative request, there are problems, which we realized earlier on. I don't recall the details from the top of my head, but the discussions should be in the email archives. In your model, assume that untrusted policy A evaluates to Indeterminate. How do you determine whether it is supported by an administrative policy? It gets simpler if you don't differentiate between the administrative rights to issue Permit vs Deny access policies, though. Do you propose to remove this capability as well? - The reduction graph search is also computationally efficient. Some forms of the early delegation model were NP-complete, but that was due to the ability to restrict more than one step in the delegation chain. I am not sure if there are any issues with your proposed model though. I'm not changing anything about how authority is established, only where the PDP looks for authorizing policies and combines them. You stated in an earlier email that your model does not perform a graph search. That means that you are changing "how authority is established". Best regards, Erik As it stands at the moment, I find that I have to put a copy of each administrative policy in just about every policy set because it isn't generally possible to determine which administrative policy will authorize which access policy without reference to a specific request context. That means that just about every administrative policy is considered as a candidate during every reduction attempt using the reduction graph, regardless of where it happens. Evaluating administrative policies from the top means that in the worst case every administrative policy is still a candidate for consideration during reduction, but at least they won't be duplicated all over the place. In practice I think the search will be improved because the targets on administrative (or hybrid) policy sets will allow large numbers of administrative policies to be disregarded during the search. Indexing of the administrative policy sets will also allow some proportion of them to be ignored without even getting to the point of checking their targets. Regards, Steven /Erik On 2012-12-20 07:22, Steven Legg wrote: Hi Erik, On 20/12/2012 3:43 AM, Erik Rissanen wrote: Hi Steven, On 2012-12-19 06:29, Steven Legg wrote: Hi Erik, On 19/12/2012 2:08 AM, Erik Rissanen wrote: Thanks Steven, Ok, so the difference which I had not noticed in your proposal is that you advocate that any admin request should always start from the top, You need to read more carefully. That was the fifth time I'd said it. > while I say that the reduction graph is formed within the nested policy set like before, except of course that we use labeling rather than categories to differentiate between admin and access policies. By doing nested reduction graphs, there are two benefits as I see it: - You don't need hybrids. - Someone can neatly package a complete policy set with nested admin policies in full, without having to be concerned about how this might interfere with any other "top level" policies. Could you refresh my memory again as to why you want to start reduction from the top? What are the benefits? I previously said this on the topic: ... "working out where to put an administrative policy under the current scheme is a burden policy writers can do without. Take the simple case where User A delegates all rights to User D. This is a very simple administrative policy that basically says "if the delegate is User D, then Permit". The issue is where to put it. User A needs to place it (by copy or by reference) in every policy set where User D will potentially be creating access policies. Furthermore, as new policy sets are created that User D might put policies into, User A will have to put the administrative policy in there as well. Conversely, if User A isn't thorough or proactive in placing the administrative policy, then User D will be limited in the rights he or she can actually exercise. Compounding the difficulties is the fact that in the general case, because of multi-valued attributes and augmentation of the delegate category by a context handler, practially any untrusted policy can be authorized by any administrative policy. It all depends on the request context. It is only by making assumptions about certain attributes being single-valued or by knowing about correlations between the attributes of an access subject that we can begin to predict which untrusted policies will be authorized by which administrative policies in the absence of any specific request context. These are things that users shouldn't have to be concerned with when creating administrative policies." In the current scheme an administrative policy can only authorize an untrusted policy that is a sibling or a sibling of an ancestor. This is a severe limitation when the scope of an administrative policy is wider than any one of the untrusted policies that it authorizes. It is correct that the admin policy has to be a sibling in the current scheme, and my proposed labeling scheme. I don't see this as a major issue, rather I find it nice, because it means that this allows recursive nesting of policies, which will not interfere with each other. That is still possible with HybridPolicySet and evaluation from the top. The only difference between the original access request and any administrative requests subsequently spawned from it because of untrusted policies is that the administrative requests will have added categories for delegate and delegation-info. If the targets of the HybridPolicySet and its ancestor HybridPolicySets don't reference these categories (and there is no good reason for them to do so), then a PDP evaluating an administrative request will find its way back to the same HybridPolicySet where the untrusted policy was encountered. If the policy set hierarchy is constructed such that policy sets don't interfere with each other with respect to access requests, then they won't interfere with each other with respect to the corresponding administrative requests. Mostly I find that I want to put the administrative policies higher up in the policy set hierarchy, because they have a wider scope. I don't understand your second concern in the text you quoted above. It is true that XACML policies are written with a set of possible request contexts in mind. An admin policy can use any attributes it desires to constrain its applicability in any way, so it is quite clear which requests it will authorize for which delegates. It is true that the support relation between an access policy and an admin policy is resolved at runtime, so the links are not static. A policy may support another or not, depending on the situation/context. However, this is a feature, not a bug, since it allows an access policy author to "consolidate authority", that is he can write an access policy which is in itself greater in scope than any individual admin policy which authorizes him. Depending on the situation, the access policy would be supported by different admin policies. That feature is not something I'm proposing changing. The limitation that authorizing administrative policies have to be a sibling or descendant of a sibling is just not in harmony with it. If a writer of an untrusted access policy doesn't know for certain which administrative policy or policies will authorize it, how can they be sure they have put it in a place that will allow it to be authorized ? The writers of administrative policies have the similar problem of not being sure they have put the administrative policy in the places it needs to be to authorize the access policies yet to come. Evaluating administrative requests from the top removes sibling adjacency as a concern and the feature operates unfettered. I also said this: [ In the current scheme ] "the effect of a nested AdminPolicy depends on where evaluation of the administrative request begins. Suppose that the nested AdminPolicy evaluates to Deny. If the evaluation of the administrative request started inside the AdminPolicySet, then the AdminPolicy has no effect because it doesn't add an arc to the reduction graph. If the evaluation of the administrative request started outside the AdminPolicySet, then the Deny result from the AdminPolicy is combined with the results from its siblings according to the combining algorithm of the AdminPolicySet. If that combining algorithm is deny-overrides, then the Deny result overrides any Permit results from the siblings. That sort of variability will make delegation hard for users to understand." Evaluating administrative requests from the top means that the result of an administrative policy is always combined with the results of its siblings according to the combining algorithm of the policy set in which it is found - with no exceptions. Yes, that is true, but I would not expect anyone to use delegated admin policies inside an admin policy set. (In fact, we could forbid that explicitly.) Also, I am not sure it's a lot easier to grasp the big picture in case of nested untrusted admin policies even if the evaluation jumps up to the top level for each untrusted admin policy. It's going to melt most people's brain anyway. ;-) In the current scheme, the reduction of an untrusted policy considers each of the sibling administrative policies by evaluating the administrative request against them. The effect of the reduction graph is to combine the results of those evaluations in a way that is similar to, though not exactly, the permit-overrides combining algorithm. This is the only predictable way to combine the results of administrative policies, whether I like it or not, and I don't. I particularly want to use deny-overrides. If I put the administrative policies inside an administrative policy set with the combining algorithm I want, then that's not reliable, for the reasons above. The practice might as well be forbidden if it can't be trusted, but either way, policy writers are condemned to only combine the results of administrative policies according to something like permit-overrides. Evaluating administrative policies from the top every time means that policy writers have the flexibility to use whatever combining algorithm they want, knowing that it will always work as specified. And I said this: [ In the current scheme ] "evaluation of an administrative request always starts with the pair-wise consideration of siblings of the policy being reduced. It is a process that is different from the normal processing of a combining algorithm and, in fact, completely disregards the combining algorithm of the policy set that contains the access policy and its sibling administrative policies. Starting the evaluation of the administrative request at the top (just like an access request) would be simpler to manage and easier for users to get their heads around." When I read this, I am not sure, but do you imply that there is no reduction graph construction at the top level. Correct. The administrative request is evaluated according to section 7.17 of the core, subject to the additional requirement that any access policy or access policy set is automatically NotApplicable. > BTW, what does the reduction graph look like in your proposal? There isn't one. Regards, Steven > Which policies participate in it? How is it built? Best regards, Erik Regards, Steven Best regards, Erik On 2012-12-18 07:17, Steven Legg wrote: Hi Erik, On 18/12/2012 2:32 AM, Erik Rissanen wrote: On 2012-12-14 04:28, Steven Legg wrote: On 13/12/2012 11:36 PM, Erik Rissanen wrote: > So why do you allow for the hybrid? To overlay the administrative and access policy set hierarchies. Some folks have expressed a dislike for a complete separation. I don't see that you need hybrids even if the admin hierarchy is overlaid. Can you give an example? Suppose I want to write a bunch of admin policies that all relate to a resource with a resource-id of "printer", so I factor out the resource-id test and wrap the admin policies in an admin policy set like so: AdminPolicySet { PolicySetId: PS1 Target: resource-id="printer" AdminPolicy { PolicyId: P1 ... } AdminPolicy { PolicyId: P2 ... } } Along comes the delegate, who creates some access policies that relate to the resource with a resource-id of "printer". If the delegate factors out the resource-id test and wraps the access policies in an access policy set it looks like this: PolicySet { PolicySetId: PS2 Target: resource-id="printer" Policy { PolicyId: P3 ... } Policy { PolicyId: P4 ... } } This represents a complete separation of access and administrative policy. In my proposal I don't allow AdminPolicy in a PolicySet, or Policy in an AdminPolicySet, not because it is harmful, but because it is pointless. Recalling that I am proposing evaluating administrative requests from the top, an AdminPolicy in a PolicySet will never get evaluated because the PolicySet is not applicable to an administrative request. Likewise, a Policy in an AdminPolicySet will never get evaluated because the AdminPolicySet is not applicable to an access request. In order to take advantage of the common targets for the two policy sets above and merge them into one I need a policy set that is applicable for both access requests and administrative requests. That thing is the HybridPolicySet: HybridPolicySet { PolicySetId: PS3 Target: resource-id="printer" AdminPolicy { PolicyId: P1 ... } AdminPolicy { PolicyId: P2 ... } Policy { PolicyId: P3 ... } Policy { PolicyId: P4 ... } } Regards, Steven

OASIS eXtensible Access Control Markup Language (XACML) TC

Groups - xacml-3.0-combalgs-v1.0-wd02.doc uploaded

Erik Rissanen08-22-2012 08:32

Steven Legg08-23-2012 04:49

Erik Rissanen08-23-2012 09:03

Steven Legg08-24-2012 05:57

Steven Legg08-28-2012 01:09

Steven Legg08-28-2012 12:48

Erik Rissanen08-31-2012 15:24

Steven Legg09-03-2012 04:08

Erik Rissanen09-05-2012 13:27

Steven Legg09-05-2012 23:44

Steven Legg09-03-2012 05:04

Erik Rissanen10-31-2012 12:36

Steven Legg11-01-2012 05:15

Erik Rissanen11-01-2012 07:40

Steven Legg11-05-2012 04:43

Erik Rissanen11-27-2012 09:44

Steven Legg11-28-2012 05:29

Erik Rissanen11-29-2012 12:33

Hal Lockhart11-29-2012 19:58

Rich Levinson11-29-2012 20:43

Steven Legg11-30-2012 04:10

Erik Rissanen12-04-2012 11:45

Steven Legg12-05-2012 06:25

Erik Rissanen12-05-2012 16:28

Steven Legg12-06-2012 04:57

Erik Rissanen12-12-2012 10:51

Steven Legg12-12-2012 23:44

Erik Rissanen12-13-2012 12:37

Steven Legg12-14-2012 03:28

Remon Sinnema12-14-2012 08:30

Erik Rissanen12-17-2012 15:33

Steven Legg12-18-2012 06:18

Erik Rissanen12-18-2012 15:08

Steven Legg12-19-2012 05:30

Remon Sinnema12-19-2012 08:56

Erik Rissanen12-19-2012 16:44

Steven Legg12-20-2012 06:22

Erik Rissanen12-20-2012 09:27

Steven Legg01-24-2013 06:37

Erik Rissanen01-24-2013 09:04

1. Groups - xacml-3.0-combalgs-v1.0-wd02.doc uploaded

2. Re: [xacml] Groups - xacml-3.0-combalgs-v1.0-wd02.doc uploaded

3. Re: [xacml] Groups - xacml-3.0-combalgs-v1.0-wd02.doc uploaded

4. Re: [xacml] Groups - xacml-3.0-combalgs-v1.0-wd02.doc uploaded

5. Delegation and on-permit-apply-second

6. Re: Delegation and on-permit-apply-second

7. Re: Delegation and on-permit-apply-second

8. Re: Delegation and on-permit-apply-second

9. Re: Delegation and on-permit-apply-second

10. Re: Delegation and on-permit-apply-second

11. Policy Labelling (was Re: Delegation and on-permit-apply-second)

12. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

13. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

14. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

15. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

16. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

17. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

18. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

19. RE: [xacml] Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

20. Re: [xacml] Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

21. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

22. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

23. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

24. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

25. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

26. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

27. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

28. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

29. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

30. RE: [xacml] Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

31. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

32. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

33. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

34. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

35. RE: [xacml] Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

36. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

37. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

38. Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)