MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] Modeling Delegation of Rights in a simplified XACML withHaskell
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]