[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft 09 of the administrative policy specification
All, I have submitted a new draft on the delegation stuff. This time there is not as much big changes as last time. Maximum delegation depth is now included in the processing model. I also moved the depth from an element in the policy to an attribute in the Delegates element in the target. The rationale is that the maximum depth does not make sense unless there is a Delegates element, so they should be co-located. I did some thinking about issue 25, nested policy sets and enforcement of delegation constraints. I think the problem is a fundamental property of delegation and cannot be solved in general. However, the problem can be controlled, so I added a description of the problem and some suggested workarounds to the security considerations section. I also thought about obligations and delegation. I added them to the processing model at the access level. However, there is a potential issue with them, which I was not able to solve. I am not sure whether it can be solved or not. I wrote a section about it in the security considerations, with some suggested workarounds. When I thought about the obligations, it seemed it would be quite simple to allow obligations in administrative policies as well if we want to. There could be a point in doing so. For instance we could specify that all accesses in the end allowed by an administrative policy have to be logged. We had previously said that we do not support obligations in administrative policies, so I didn't add them yet, but it seems to be a good idea to do so for the next draft. Because of this, I didn't go into an effort in specifying error semantics for the presence of obligations in administrative policies yet. I thought about the indirect delegates. I was hoping to use the high order bag functions to write conditions on them, but I was not able to make it work since there can be several indirect delegates. If there are several indirect delegates the IndirectDelegateAttributeDesignator would have to either mix the different indirect delegates or return a bag of bags. If we do the former, we cannot write meaningful conditions since we don't know whether the condition applies to a single indirect delegate or to all of them together. If we do the latter, there are no way to write conditions on them since there are (to my knowledge) no way to iterate over bags in XACML or other functions that work on bags of bags. I solved the problem by replacing the IndirectDelegateAttributeDesignator with a special case expression called IndirectDelegatesCondition, which is a kind of combination between a *Match and *AttributeDesignator. It returns true if all indirect delegates contain the specified attribute value. I added use of this to the example. If any of you XACML veterans have a more general or otherwise better way to achieve this, let me know. Talking about the indirect delegates, the condition element that I added is a fairly simple one. We have sometimes discussed, for instance, whether the indirect delegates should be ordered. For now, I chose to use a simple form. My colleague Babak and his colleagues have developed a more general constrained delegation model which we have been using the last several years. You can read about the model in the following paper: Olav Bandmann, Mads Dam, and B. Sadighi Firozabadi. Constrained Delegations <http://www.sics.se/isl/pbr/papers/ConstraintDelegation.ps>. In proceedings of 2002 IEEE Symposium on Security and Privacy, 2002 which is available at http://www.sics.se/isl/pbr/papers/ConstraintDelegation.ps The experimental delegation implementation I did last year is a full implementation of the above model. In that case the order is significant and you can specify patterns of delegation, similar to regular expressions. However, in our research and application of the model during the last year, we haven't really used much of that power. Basically we have been only using a restricted version of it, for which the IndirectDelegatesCondition element in this new draft is enough. So, for a pragmatic approach, I would suggest that we give it some thought and perhaps for this version try to keep it simple. If there is user demand, we can always add more in version 3.1. :-) There is one important issue with the IndirectDelegate that I did not address in this draft yet. It is the matter of what point in time to use for resolving issuer attributes. In our research and use of the model we have found that in many cases it is better to use the time point at which the policy was issued for the time of resolving attributes of the issuer, rather than the time point of the access request. Imagine that there is a policy that says that people in a certain group may issue rights. Now, if you have an administrator who has issued policies (with the right of being in the admin group), in many cases you do not want the policies he has issued to become invalid if he leaves his administrator position. If you use current attributes for the issuer, the verification of his right to issue a policy will fail when he leaves his position and loses his administration attributes. All policies he has created become invalid. Instead we can reason that the policy should still be valid since he had the right to issue it when he issued it, even though he no longer would have the right to issue the same policy. To verify that we need to pass along the timepoint of issuing to the context handler, so it can get "old" attributes of the right instant in time. So, we need an attribute for the issue instant of the policy. Should we define this attribute or leave it to implementors? Also, this opens up the question of revocation right, since a new administrator should perhaps be able to revoke what his precedessor did. Now for something simpler: I added an attribute called "allowAccessRequest" to the Delegates element of the target. If it is true, the policy will match both access and administrative requests. I hope the next draft could be somewhat "feature complete". On top of my head, the main missing features are reduction of deny and some misc stuff like policies in the request context. Should I aim at getting one more draft out before the F2F, including some version of reduction of deny, or should we let that be for discussion at the F2F?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]