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