[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)
Hi Steven, On 2012-12-13 00:44, Steven Legg wrote:
Hi Erik, On 12/12/2012 9:51 PM, Erik Rissanen wrote:Hi Steven, On 2012-12-06 05:57, Steven Legg wrote:Hi Erik, On 6/12/2012 3:28 AM, Erik Rissanen wrote:Hi Steven, Three comments:1. Yes, if you use permit-unless-deny in a policy which matches admin requests in its target and put that in a policy set which has delegated policies, then you might get into trouble. But there are many other ways towrite incorrect policies, so what is special about this one?It's special in that it doesn't start out incorrect. It is perfectly reasonable to create an access policy set that uses permit-unless-deny in a deployment that doesn't use delegation. If at a later time that deployment decides to start using delegation, then the access policy sets that are using permit-unless-deny immediately become toxic and have to be remediated. It is an undesirable side-effectof simply starting to use administrative policies.This could be handled by saying that admin policies are not combined for an access decision at all.This is effectively what we are already saying, so it isn't a solution.If a policy set with the permit-unless-deny combining algorithm and no administrative policy children is evaluated with respect to an administrative request (which is what can happen if we don't distinguish the different kinds of policy set), then none of the children are applicable so the overall result is Permit. This is not a good outcome for a policy set that was originally created as an access policy set without delegation in mind. We need the three labels for policy sets so that policy sets originally created as access policy sets stay as access policy sets unless a policy writerconsciously decides to change that by changing the label.
This is cannot happen given the set of labels i proposed in my earlier email. An access policy set would never be evaluated with respect to an administrative request. It is possible that a delegation graph is formed within it during evaluation of an access request, but in that case the combining algorithm is not applied during reduction. Instead it's the graph search which is used.
> This issimilar to how the current delegation profile draft says that policies which fail to reduce are discardedand not combined.2. I still don't understand what your preferred solution is. Sorry about that. ;-)Three labels for policy sets.Could you list all these labels and their meaning, like I did for my proposal? When you respond to my proposal by comparing it to your proposal, but not enumerating your own proposal in full and on its own, it's hard for me to follow the discussion and understand what exactly your proposal reads like in full. Sorry about the confusion, but I am still unable to resolve this by the "delta" your comments provide. ;-)Okay.Policy: Only evaluated in the normal manner for access requests. Automatically and unconditionally treated as NotApplicable when evaluating an administrativerequest. Contains rules.AdminPolicy: Only evaluated in the normal manner for administrative requests. Automatically and unconditionally treated as NotApplicable when evaluating anaccess request.PolicySet: Only evaluated in the normal manner for access requests. Automatically and unconditionally treated as NotApplicable when evaluating an administrativerequest. Contains Policy and/or PolicySet instances.AdminPolicySet: Only evaluated in the normal manner for administrative requests. Automatically and unconditionally treated as NotApplicable when evaluating anaccess request. Contains AdminPolicy and/or AdminPolicySet instances.HybridPolicySet: Evaluated in the normal manner for both access requests and administrative requests. Contains Policy, AdminPolicy, PolicySet, AdminPolicySetand/or HybridPolicySet instances.
Thanks Steven. This makes your proposal clear. The difference is that your proposal includes the HybridPolicySet. I am actually surprised by that since you argued against hybrids in previous posts and you even convinced me to drop the hybrids. ;-) So why do you allow for the hybrid?
The evaluation of administrative requests always starts at the top, just likeaccess requests. Recalling Section 7.17 of the core specification, i.e.:"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 algorithmand the set of policies and/or policy sets".The set of policies and/or policy sets includes Policy, AdminPolicy, PolicySet, AdminPolicySet and/or HybridPolicySet instances, which means that effectively "the PDP is defined by" a single, virtual HybridPolicySet. A deployment that chooses to use delegation and wants to wrap up everything in a single, physicalpolicy set would use a HybridPolicySet to do that.
In my proposal, which does not allow hybrids, the evaluation starts at an access policy set or an access policy. Naturally this policy set may internally use delegation. All policies are contained within this access policy (except of course policies which are referenced). There is no separate bundle of admin policies.
Regards, StevenBest regards, Erik3. The way I think of the different types of policies are these (not sure about the naming itself, but wecan discuss that later): - Policy: is applied only to access requests. Contains rules.Yes.- AdminPolicy: is applied only to admin requests. Contains rules.Yes.- PolicySet: is applied only to access requests. Contains Policy, AdminPolicy, PolicySet or AdminPolicySet. Note that the AdminPolicies and AdminPolicySets which are contained here are only applied to admin requests which are generated during processing of delegated policies within the policy set.This is a policy set of the first kind, though it isn't exactly a pure access policy set. With regard to the current draft of the administration profile, or the "minimal change" solution, where the evaluation of an administrative request begins within a policy set, it is appropriate for a PolicySet to contain an AdminPolicy or AdminPolicySet. What I would like to see is the evaluation of an administrative request beginning at the top, in which case there is no reason for a PolicySet to contain an AdminPolicy orAdminPolicySet because they would never be evaluated.- AdminPolicySet: is applied only to admin requests. Contains AdminPolicy or AdminPolicySet. Note that there will never be any access request processing within one of these. Note that nesting a delegated AdminPolicy or AdminPolicySet in here probably will lead to some kind of confusion since we would then have two kinds of admin requests being processed within this AdminPolicySet: the initial one applied to this AdminPolicySet,and the ones generated from the nested delegated policies.That's one of the reasons I don't like the way evaluation of an administrative request starts within a policy set. 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. In part, I have been advocating evaluating administrative requests from the top to remove thisvariability. AdminPolicySet is a policy set of kind (2).Does this correspond to what you meant?You haven't covered policy sets of the third kind, which the current draft of the profile allows. Of course, the name can be discussed later. Some possible names are HybridPolicySet, MixedPolicySet, DualPolicySet or AdminAndAccessPolicySet. A HybridPolicySet may contain Policy, AdminPolicy, PolicySet, AdminPolicySet and/or HybridPolicySet children, and has a target that is satisfied by access requests oradministrative requests.If one assumes the "minimal change", then there isn't a compelling case for having policy sets of the third kind. If one assumes the complete separation of access and administrative policy, with administrative requests evaluated from the top, then there is no case for having policy sets of the third kind. If one assumes that administrative requests are evaluated from the top and the administrative policy set hierarchy is overlayed on the access policy set hierarchy, then policy sets of the third kind are needed to achieve that overlay. This last possibility iswhat I prefer. Regards, StevenBest regards, Erik On 2012-12-05 07:25, Steven Legg wrote:Hi Erik, On 4/12/2012 10:45 PM, Erik Rissanen wrote:Hi Steven,I am uncertain, but are you now proposing that admin policies are nested in the same hierarchy as accesspolicies?Yes, until today when I noticed a problem with it in the context of policy labelling.Like it's today and which I also suggest?Could you summarize your latest proposal with a couple of lines of pseudo xacml?It's not exactly like today, which is part of the reason this thread exists, and I think it will take more than a couple of lines of pseudo XACML to describe thedifference.Under the current version of the administration profile there are roughly four kinds of policy set, which are distinguished by their targets. I'll demonstratewith an example Match element.(1) The first kind of policy set is a pure access policy set, which would havea target that contains a Match element something like this:<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI";>http://example.com/MyDocument</AttributeValue> <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"DataType="http://www.w3.org/2001/XMLSchema#anyURI"; MustBePresent="false"/></Match>This Match element can be satisfied by an access request, but cannot be satisfiedby an administrative request.(2) The current version of the profile uses category prefixing. The second kind of policy set is a pure administrative policy set, which uses category prefixes in its attribute designators and would have a target that contains a Match elementlike this:<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI";>http://example.com/MyDocument</AttributeValue> <AttributeDesignatorCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:delegated:urn:oasis:names:tc:xacml:3.0:attribute-category:resource"AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"DataType="http://www.w3.org/2001/XMLSchema#anyURI"; MustBePresent="false"/></Match>This Match element can be satisfied by an administrative request, but cannot be satisfiedby an access request.(3) The third kind of policy set is a hybrid where the target matches both an accessrequest and its corresponding administrative request(s): <AnyOf> <AllOf><Match MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI";>http://example.com/MyDocument</AttributeValue> <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"DataType="http://www.w3.org/2001/XMLSchema#anyURI"; MustBePresent="false"/></Match> </AllOf> <AllOf><Match MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI";>http://example.com/MyDocument</AttributeValue> <AttributeDesignatorCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:delegated:urn:oasis:names:tc:xacml:3.0:attribute-category:resource"AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"DataType="http://www.w3.org/2001/XMLSchema#anyURI"; MustBePresent="false"/></Match> </AllOf> </AnyOf> This has to be a disjunction or it will never be satisfiable.(4) The fourth kind is a hybrid where the target matches unrelated accessrequests and administrative requests: <AnyOf> <AllOf><Match MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI";>http://example.com/MyDocument</AttributeValue> <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"DataType="http://www.w3.org/2001/XMLSchema#anyURI"; MustBePresent="false"/></Match> </AllOf> <AllOf><Match MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI"; >http://example.com/SomeOtherDocument</AttributeValue> <!-- NOTE THE DIFFERENCE HERE. --><AttributeDesignatorCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:delegated:urn:oasis:names:tc:xacml:3.0:attribute-category:resource"AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"DataType="http://www.w3.org/2001/XMLSchema#anyURI"; MustBePresent="false"/></Match> </AllOf> </AnyOf>With policy labelling, (4) is no longer representable, which is no great loss since it is strange usage. With policy labelling, i.e., no category prefixing, the targets for (1), (2) and (3) would all look like (1). If we don't distinguished between the three kinds of policy set by how the policy set is labelled, then all policy sets will be treated as hybrids like (3). It means that the target of a pure access policy set will sometimes be applicable for an administrative request, and the target of a pure administrative policy set will sometimes be applicable for an access request. I thought this was harmless because a pure access policy set will only contain access policies and a pure administrative policy set will only contain administrative policies (we would be able to tell the difference between access policies and administrative policies by their element names). If the PDP is processing an access request against the children of a pure administrative policy set, then all those children will evaluate to NotApplicable automatically. If the PDP is processing an administrative request against the children of a pure access policy set, then all those children will also evaluate to NotApplicable. Most policy set combining algorithms evaluate to NotApplicable if the children are all NotApplicable, so there's no harm done, apart from wasting CPU cycles. Unfortunately, there are at least two combining algorithms that can never return NotApplicable: permit-unless-deny and deny-unless-permit. If we don't distinguish between the different kinds of policy set, then we can't safely use combining algorithms like permit-unless-deny and deny-unless-permit. A pure access policy set with the permit-unless-deny combining algorithm will automatically authorize any untrusted sibling policy or policy set.A complete separation of access and administrative policy doesn't have this problem because policy sets are labelled to clearly identify them as either (1) or (2). There are no (3)s and no ambiguity between (1) and (2). However a complete separation meansthat some mirroring of the policy set hierarchy will occur.To overlay the administrative policy set hierarchy on the access policy set hierarchy without excluding some combining algorithms seems to require that we distinguish between the three kinds of policy set, i.e., (1), (2) and (3). I was hoping to avoidthree labels but it seems I can't.I can live with either a complete separation, or three labels for the three kinds ofpolicy set. Regards, StevenBest regards, Erik On 2012-11-30 05:09, Steven Legg wrote:Hi Erik, On 29/11/2012 11:32 PM, Erik Rissanen wrote: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 asingle policyset, but I agree that the value probably is not that big. In come cases where someone would handover apolicy set "here are all my access and admin policies", they would have to hand over two separatesets of policies instead.And, yes, when I think about it more, the evaluation logic change is small. And there is actuallyoneadditional benefit. The explicit marking of a policy as an admin policy is probably simplerconceptually 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 theminimal 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 unhelpfulpossibility 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' willnever be evaluated. We might as well disallow such children.In summary, what we have for the minimal change is <PolicySet> elementsthat 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 isrequired.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 tosolve theissue 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 mainpossibilities.I don't like the above since this introduces a top level construct in the PDP which is different fromany 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 fromthe 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 administrativeprofile is going to be of any use, this top level policy construct also has to also be able to containadministrative policies.Only if you assume that everything has to be wrapped up in a single, physicalpolicy 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 thecore 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 algorithmand 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 administrativerequest 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 administrativepolicy sets.> Thus the top level policy construct is something different from the above policyconstructs 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 tostart for an administrative request ?No, it's not difficult, but it means that delegation will only work at the top level.The evaluation of an administrative request starts at the top level, but the untrusted policy or policy set that is being authorized (or not) by the evaluation of the administrative request can be at any level, as is currentlythe case. > A sub policyset cannotuse delegation within itself in that case, which is a restriction for a collaborative policy authoring.With complete separation, the administrative policies that authorize policies within the access sub-policy-set cannot be in the access sub-policy-set, but they can be in an administrative sub-policy-set in the administrative policy hierarchy that mirrors the access policy hierarchy. As Hal points out, it would be good to avoid maintaining that mirror hierarchy, which we can do because the administrative policy sets wouldn't be doing much more than providing an efficiency improvement.If we don't distinguish between access policy sets and administrative policy sets (but still distinguish between access policies and administrative policies; a partial separation) and just have "policy sets", then that means the PDP might spend time looking into policy sets that it didn't need to. However, a smart implementation can note which policy sets only contain access policies, which policy sets only contain administrative policies, and which policy sets contain a mix, so that when evaluating an access request it can skip the policy sets that contain only administrative policies, and when evaluating an administrative request it can skip policy setsthat contain only access policies.So let's just have PolicySet, Policy and AdministrativePolicy elements, where a PolicySet can contain Policy and/or AdministrativePolicy elements. The administrative policy set hierarchy will be aligned with the access policy sethierarchy because they will be the same hierarchy.The thing that makes delegation difficult to manage (and really needs to be changed) is the fact that 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 headsaround. Regards, StevenThe 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 ofadministrative 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 graphbecause 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 exactlytwo 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 introducesanother 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 orpolicy sets will be different ones.Also, being able to mix in admin policies in nested access policies is useful for creatinghierarchicalstructures, where a delegated policy contains nested delegation itself. This sort of recursion isuseful forbeing able to import a full policy set of a sub-organization which internally might want to usedelegation.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 thewrong 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 accesspolicies, even though they are separated.But it would put everything at the top level. I would think that recursion and nesting would beuseful to handle very large policy sets.Regards, StevenBest regards, ErikRegards, StevenBest 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 unrelatedaccess 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 PDPcan 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 theadministrative specand 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 efficientcompared 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 becomesdelegated-http://example.com/foobar. > Or changing the admin category to something elsethan 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, StevenBest 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 coreschema, 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 substitutiongroups 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 earlystages of the delegation work. I don't remember right now why we did not go that way, but Isuspect 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 flexibilityto get rid of category prefixing and its problems. Regards, Steven
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]