[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] first proposal for hierarchial resources
> This is a draft proposal for the xacml 1.1 work item 'Fully > specified hierarchial resources'. This is an interesting proposal. It adds a lot of complexity to the PDP, but could make things much more efficient (the alternative being that the PEP knows about models, knows what "search" requires, and does separate queries "up" some tree). I'll admit to having mixed feelings, but I'm willing to be convinced. Unsurprisingly, I have a couple questions. :) First off, it seems that rather than trying to define how you resolve hierarchical resources, you're only defining how policies relate to each other in some hierarchy. Is that correct? It looks like the model URI could provide that information, but since you then want to define some relationships in the policy, it's not clear to me what the model URI is used for (it would be much easier to write these policies if the model was the only addition and it defined everything). > In this proposal resource model is defined for the policy and does > not vary from rule to rule. For the motivation behind this consider > xml document use case. One can select abstract tree model or dom > model. These two models have different requirements and different > syntax. I'm a little concerned about writing policies that only work for a particular resource framework. I would think that I should be able to write a general policy that says "reading requires searching" and not have to replicate that for each resource hierarchy I use. Why not put information about the hierarchy model in the request instead? > Resource model can specify permission propogations. For example, > 'search' permission on a directory in a file system requires > 'search' permission on all ancestor directories up to the root. How exactly will you recognize the "search" action? There is no required or standard action attribute, so there's no way to know what kind of action the request is specifying. There is a line in the spec about an action-id attribute, but there is no description or suggestion of how to use it, and since it's not required, there's no guarentee that it will be in a request. It seems to me that both the PropigationRule and Implication tags reference some URI that is an action. Another question: how do you know to look for "read" or "search"? These aren't standard URIs. Are you going to define standard action URIs to go with each of the resource model URIs? If the models are standard, then it seems to me that they will also need standard actions since those actions need standard sematics, or the models won't make sense. > Resource model can state that 'search' permission on a node > propogates 'search' permission on all ancestor nodes, unless > overwritten by other rules. Again, I'm confused about the role of the model URI. If a policy can suddenly redefine the way that the resource hierarchy works, what is the model providing? Shouldn't the model be a constant that always defines the way a hierarchy works? I can't specify a UFS directory that doesn't require search permission up the tree to search the current directory. Why? Because that would confuse things, and make it hard for software to function correctly. Likewise, how will policy and PEP writers know how to handle these sudden changes? Along these lines, how do we know what "up" or any other direction means? This has to be something that is defined by the model, so the model must be something concrete that can be looked up and used to handle some direction.Specifically, the identifier "up" will have to be mapped to some mechanism that can look for the resource that is "up" and get the accompanying policy. This is non-trivial. I would feel much more comfortable if there was a more concrete description of how these features were used, not just what they're supposed to mean. Finally, while you've clearly defined how some relationships are laid out, I don't see anything about how policies are supposed to be enforced. For example, do we look at the PropigationRules and Implications as soon as a request arrives? After the request has been satisfied? When using the model information to lookup the next policy "up" do we need to apply the PropigationRules to get that resource? What if that loops or otherwise causes the PDP to hang? There's a lot of the "what" in this propsal, but not a lot of the "how." I'd like to see some of that get fleshed out. Even if XACML shouldn't be defining any of this (though I think it should), I'd still want some convincing arguments that this will actually work. Like I said at the start, I'm willing to be convinced, so these are real questions. I'm curious about how all these details will work together. If it can be built, if it doesn't confuse the sematics, and if it doesn't slow down the system too drastically, I'm willing to give it a try. seth ps I'm still a little puzzled about where this propsal came from. The original idea was just to define a few standard models so that children and descendant resources could be resolved in a standard way. Once that's done we know how to find policies for those resources. Also, everything that's being proposed here can already be done by using policy references (ie, if an action of "search" is issued on a given resource, the policy can say that the "up" policy must be referenced). There's no standard way to map that to the resource model, but I don't see that this is needed if the models aren't constants that can be used to define all interactions.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]