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: Constraints on delegate


Hello all,

During the focus group meeting, there was some discussion about my
proposal to include a constraint on issuers further down in a delegation
chain. I was not able to explain it very well on the phone, so I
promised to try to explain it in an email, so here I go.

The current draft specifies something like this:

<Policy>
  <PolicyIssuer>Alice</PolicyIssuer>
  <Target>
    <Subjects>Group=staff</Subjects>
    <Resources>Printer</Resources>
    <Actions>Print</Actions>
    <PolicyIssuerMatch>Bob</PolicyIssuerMatch>
  <Target>
   ...
</Policy>

This grants an administrative right to Bob. Bob in his turn can grant an
administrative right to Carol:

<Policy>
  <PolicyIssuer>Bob</PolicyIssuer>
  <Target>
    <Subjects>Group=engineering</Subjects>
    <Resources>Printer</Resources>
    <Actions>Print</Actions>
    <PolicyIssuerMatch>Carol</PolicyIssuerMatch>
  <Target>
   ...
</Policy>

Carol in turn can grant an access right to David:

<Policy>
  <PolicyIssuer>Carol</PolicyIssuer>
  <Target>
    <Subjects>David</Subjects>
    <Resources>Printer</Resources>
    <Actions>Print</Actions>
  <Target>
   ...
</Policy>


The policies are evaluated against a request. Assume that we reach the
stage that Bob's policy evaluates to a permit. The right of Bob to issue
the given policy needs to be validated. This is done by comparing the
original request subject, resource and action against the first policy's
target, but also by comparing Bob against the PolicyIssuerMatch in
Alice's policy. If they all match, it means that Bob had a delegation
right for the "situation" [David, Printer, Print].

But notice how there is nothing in Alice's policy that constrains Carol.
Bob could have granted the second policy to anyone besides Carol. What I
propose is something like this:

<Policy>
  <PolicyIssuer>Alice</PolicyIssuer>
  <Target>
    <Subjects>Group=staff</Subjects>
    <Resources>Printer</Resources>
    <Actions>Print</Actions>
    <PolicyIssuerMatch>Bob</PolicyIssuerMatch>
    <DelegationConstraint>Group=admin</DelegationConstraint>
  <Target>
   ...
</Policy>

If we assume the two other policies from above, in this case the access
is not permitted unless Carol is in the admin group.

In the case of longer chains, for instance Carol, David, Eve, etc, they
all would have to satisfy the delegation constraint. This way Alice can
specify that administrative rights should not spread outside certain
constraints.

I am sure the name "DelegationConstraint" is the best possible though.

Best regards,
Erik




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]