Re: [xacml] Modeling Delegation of Rights in a simplified XACML withHaskell

[Frank Siebenlist <franks@mcs.anl.gov>]

Polar Humenn wrote:

> Frank,
> 
> Could you give us the use case for your paper? The paper doesn't quite
> describe it, and I'm having trouble figuring out what you really want to
> do other than abstractly.

Use case 1:

A user has a job running on his behalf on a server, and that job has to start an 
separate ftp service that needs access to the user's files. The user has to give 
the administrative rights to his job that will allow that job to assign the 
access rights to the ftp service to access the file on the user's behalf.
Currently, we implement this with our proxy-certs in what essentially 
constitutes to pure impersonation.

Use case 2:

A user specifies a "job" on a very high level of abstraction without any details 
about where the execution should take place, and an hierarchy of broker and 
scheduler services will be used to find the available and apropriate services 
that fulfill the job requirements and the job will subsequently be executed by 
these matched services on the user's behalf. The authorization requirement is 
that the least amount of privileges will be delegated at every work flow node.
One scenarios is that the user has to have the access rights to all the possible 
services on which his job could run, and therefor has to give all these access 
rights to the broker/schedulers, which in turn will delegate these rights 
further down until these rights are used by the actual services that execute the 
job. In a least privilege model, each broker/scheduler could limit/narrow the 
scope of the rights to the mimumum that is needed for the job to be executed in 
that workflow segment.
Currently, we use our proxy-certs again, and have to delegate to many rights to 
all the components as we're uable to narrow the amount of rights appropriately.

Use case 3:

The resource owner wants to outsource the detailed access policy administration 
to a foreign administrator who will manage the rights for all its users. Because 
the resource owner does not have the ability to check the use of its resource, 
he can not anticipate the required policies, and only the users of that resource 
can. Therefor, the user's foreign administrator needs the ability to specify 
fine grained authorization rules with target attributes that are possibly 
unknown to the resource owner. We have a so-called community authorization 
service (cas) that will is administered by the foreign domain, and issues 
authorization assertions in the form of policy statements to its users. These 
policy statements will be pushed with the user's request and evaluated by a 
policy engine on the resource. An authorization decision of permit will indicate 
to the resource's pep that the according to the foreign cas-policy, that user is 
allowed to access the resource. In other words, the resource owner has delegated 
the admin right to the foreign cas to manage the access rights to its resource 
for its set of users.
Currently, we have this implemented with a simple azn-policy language, and would 
like to use the expressiveness of xacml for this.


> To me, it looks like you just want to set up a chain of delegations being
> that anybody that is allowed access has the right to give it away.  

With an additional delegation "depth" attribute of the policy, one can 
explicitly manage the right to delegate.

> I am
> not sure why the "issuer" comes in on this point, and it seems to cause
> problems, such as you note by having decisions "issued" by different
> principals and the complicated combining algorithms. However, you use the
> issuer and subjects as an explicit connector between policies.

"If" you use a scheme where access rights constitutes right to delegate, you 
have to check whether the delegator himself has the access rights. If not, his 
policy statement is of no use and can be discarded.

> Furthermore, it looks like you had to refine the policy such that a
> subject is no longer a general predicate that is matched against arbitrary
> subject attributes.  You make it to match an explicit principal, so
> presumably, that you can correlate the subject in the policy exactly with
> another policy issuer, or visa versa.

Although I simplified the model by having subject/resource/action without 
attributes, you should be able to generalize that...

The issuer of a policy should have the attributes that came with the verified, 
authenticated/signed policy statement, and these are the ones that should be 
used (plus maybe other attributes that can be retrieved from the PIP?)

> Let me take a stab at something. For the moment, let me make use of the
> Abadi Principal Calculus. I think what you really want to say is that
> there are principals that can "speak for" another principal, and these
> successive "speaks for" relations can form your delegation chain, but we
> can take the "chain" complications out of it.
> 
> We will take advantage of a rule:
> 
> A says s       B speaksfor A on s
> -----------------------------
>      A /\ B says s
> 
> where "/\" effectively means a conjunctive principal, i.e. they both say
> s by themselves
> 
>      A /\ B says s
> -------------------------
> A says s     B says s
> 
> Lets say the question is can Alice access resource Boat with action Drive.
> 
> Alice says "Drive:Boat"
> 
> Let's say our policy does not know anything about Alice, such that the PDP
> would return NotApplicable. However, it's John's boat, and if the
> question were asked of John,
> 
> John says "Drive:Boat"
> 
> the PDP would return Permit.
> 
> John wants Alice to drive his boat, so he might be able to convince the
> PDP that Alice "speaks for" John on that particular resource and action.
> 
> Alice speaksfor John on "Drive:Boat"
 >
> Then when the question is asked on
> 
> Alice says "Drive:Boat"
> 
> the PDP calculates in any speaksfor relations it has, and therefore you
> have the combined question"
> 
> Alice /\ John says "Drive:Boat"
> 
> Since John is allowed to drive the boat, and
> 
> John says "Drive:Boat"
> 
> is deduced from the conjunctive statement, then John's access rule will
> fire and a Permit will be the result.
> 
> This way, you don't have the problematic "Permit/Deny" delegation
> chaining, especially if "John says "Drive:Boat" yields a Deny, then Alice
> will be denied as well.

As far as i can tell, this is exactly what i'm doing in the policy reduction. 
Except that I first build up the whole tree of anyone who says he speaks for 
anybody else. Only after that, I look for the decisive principal, the trust 
root, your "PDP". Then I can collapse the tree step by step by reduction after 
having resolved the ambiguities that arise when multple pricipals claim to 
speakfor somebody and have conflicting things to say.

> We can write rules with targets and conditions as we do now, which will
> keep the predicates on subjects, resources, and actions, in general form.
> And all we really need to do is deal with conjunctive principals, which is
> something we wanted to do anyway.
> 
> The rules for the "speaksfor" can have almost the same format for the
> access rules. Instead of "emitting" a Permit or Deny effect, it emits a
> Subject (i.e. set of SubjectAttributes).
> 
> These "speaksfor" rules can be placed in a special section, or I think,
> less intrusive to what we have now, as arguments to a combining algorithm,
> which we might do as well.
> 
> This way the combining algorithm may calculate the "speaksfor" relations
> before hand (there is still a recursive problem, but there is a least fix
> point) which will "enhance" the request with the added subjects. Then the
> constituent policies may be evaluated on those subject attributes.
> 
> How does that sound?

I'm afraid that I didn't folow the last steps... but as far as I understand the 
reduction rules within Abadi's Principal Calculus are pretty much the same (?)

What I'm working on right now, however, is to show the same schema where access 
rights constitutes admin rights with a permit-overrides combinator. This results 
in a much easier to understand reduction and combination of policy statements.
(to be honest, deny-overrides has all kinds of nasty quirks to it with 
unexpected and unwanted results... i regret that i tried to use it as the first 
example.)

But, also permit-overrides doesn't address all the use cases well...

The real issue with this access right => delegation right model is that one can 
narrow the scope of the resource and actions in every subsequent delegation 
statement, but you can't narrow the subject.

The more correct way to address this is a scheme where the admin policy is 
expressed as a function of the tuple (issuer, subject, resource, action), with 
attributes of course. This allows a PDP to specify that an other subject as 
issuer, john, is allowed to specify access control policy for the subject mary 
on resource boat and action drive. In other words, the PDP can narrow down the 
potential subjects that john is allowed to manage the access rights for, to a 
single mary.

The latter was essentially what I initially proposed at the last F2F, and I'm 
trying to model this again in similar fashion as the others. I actually believe 
that we could implement this in the current xacml, by defining an 
issuing-subject category for the request context's subjects, with the addition 
of associating issuers with a policy/policyset.

In the end, I hope that we can make a choice between the different combinator 
and reduction schemes, and find the one that makes most sense, is easiest to 
understand and least "surprising".

Regards, Frank.


-- 
Frank Siebenlist               franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory