[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-dev] Re: [xacml-users] XACML 2.0 Conformance Tests Questions
Hi Oleg. > Well, I think you should agree with a simple truth > that there is no a universal mechanism to resolve an > attribute. Moreover, I don't believe that there is an > efficient way of binding a policy/policy set id to a > set of relevant "dynamic" attributes (I think this is > what Seth suggested). So the attribute mapping > function is f(Subject,Resource,Attribute)->Attributes > rather than f(Policy_ID) -> Attributes. I'm not sure what you mean by this binding, but I don't think that I suggested any kind of binding between policies and dynamically resolved attribute values. I agree that there's no universal attribute resolution approach, which is (to my mind) exactly why we're having this discussion. Different systems want or need to fetch attribute values in very different ways. Some can and indeed do supply all values up-front, whereas others *need* to wait until certain points in the evaluation of a policy before values are referenced. It is precisely because we want to support this flexibility that we have a flexible model. > It doesn't matter how many policy creators worked on a > policy/policy set. They are still the single source of > knowledge about what attributes they need and where > these attributes are stored. They will need to > communicate this knowledge to engineers who will > create adapters to get attributes from different > repositories. I still don't see a necessity to call > attribute resolution logic from inside of PDP. If > attribute model is changed, the adapters will need to > reflect the change, no matter where the adapter is > called from (from inside PDP or outside of PDP). I think you've missed a step here. Yes, the author of a policy knows what attributes might be needed by that policy, and can theoretically publish this list. Given a published list, it's even possible to look at policy references, and see what values a given tree of policies may need to do a complete evaluation. This said, how does the PEP know what policy will be chosen for a given Request? This is supposed to be something that only the PDP knows, for a variety of (in my opinion) good reasons. Actually, given how references work, this is something that even the PDP may not know until evaluation is already underway. So, even if a policy author knows what attributes might be needed, that doesn't mean that the PEP knows which policy or policies will be chosen for a given request, and therefore which values will be required. Given a very small set of policies, or a very small set of possible attribute values used by the policies, a PDP could tell the PEP the exhaustive possible set of attributes that might be needed. Of course, this would typically result in much larger and more complex Requests than are usually needed, more work ahead of time to gather values for the Request, etc. It also raises privacy concerns, because many systems don't want attributes to be presented unless they're actually needed (sometimes this gets very interesting and tricky, involving negotiation). Even given all of this, of course, it's perfectly valid to create a new policy dynamically as part of evaluation. For instance, many people have PDPs that handle the "more than one applicable top-level policy" issue by dynamically creating a single parent PolicySet with a chosen combining algorithm. You can also have a Policy Reference that doesn't point to a physically existing policy, but one that is generated dynamically based on some context (yes, I've seen this done many times). Again, you could list out the possible attributes needed, but this gets back to the same problems as above. The bottom line is that there are many very good reasons for why the model that XACML is based on (not invented by the XACML TC, but by others who have been doing this for a long time) allows for an abstract context where values can be fetched at run-time as needed. But if you don't need this in a given system, or would rather just make sure that all values are included in the Request, then there's nothing wrong with that either. The model is flexible by design, and allows you to support as little or as much as you'd like vis a vis attribute retrieval. There is nothing wrong with having a PDP that can only use values from a physical XACML Request document if that works for your environment.. seth
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]