OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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]