[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-comment] Public Comment
Others in the XACML TC may have other comments, but here is my response at your comments. -Anne Anderson > Comment from: rgrzywinski@yahoo.com > o Attributes > > Assumptions: the PEP is separate (linked via network) from the PDP (and potentially any context handler) > Anne> This is not an XACML assumption, but it may be your own use Anne> case situation. XACML certainly is intended to support Anne> this configuration. > Question: It is -implied- throughout the specification that the attributes required for a decision request are passed from the PEP to the PDP in the <Request>. Since it is not possible for the PEP to know a priori what attributes are required, nor is it feasible to include every possible attribute, (as some may be expensive to compute or too large to send) what is the current thinking for the retrieval of these attributes? > Anne> The specification actually is fairly careful NOT to say Anne> that all attributes are passed form the PEP to the PDP. Anne> The diagram on p. 19 of the specification (Figure 1 - Anne> Data-flow diagram) shows attribute queries going from the Anne> context handler to a PIP, and attributes being returned. Anne> At least some attributes will probably come from the PEP. Anne> Others may be retrieved from a repository or on-line Anne> attribute authority using other attributes as the keys. Anne> For example, the PEP may pass a subject-id in the form of Anne> an X500Name. The context handler may use this subject-id Anne> to retrieve role attributes associated with that identity. Anne> Sun's XACML Implementation (Open Source - Anne> http://sunxacml.sourceforge.net/) supports pluggable Anne> "AttributeFinderModules" that know how to retrieve values Anne> associated with various AttributeIds. Anne> The "Request Context" represents all attributes available Anne> to the PDP for use in making a policy evaluation. You Anne> might consider it to be "seeded" with the values from the Anne> PEP, but even this is not necessarily true: a PDP may not Anne> trust a given PEP to supply certain attribute values and Anne> may look them up independently. > Possible solution 1: Figure 1 shows an attribute query from the context handler to the PIP. It is possible for a PIP to exist on the same machine as the PEP and an out-of-band query is perfomed from the context handler to retrieve any required attributes. This would imply that the communication is outside of the realm of the XACML spec. The addition of a statement (perhaps in one of the examples) indicating that it may be necessary to retrieve other attributes from the PEP that are not present in the <Request>, may resolve this issue. This additional statement appears to be in scope given sections 2.5 and 2.7. Anne> It is hard to clarify a specification that is deliberately Anne> intended to leave certain matters out of scope. We have Anne> shied away from suggesting particular implementation Anne> solutions in order to avoid the appearance that a certain Anne> interpretation of the specification is more correct than Anne> another. Anne> There is the start of an "Implementer's Guide" linked from Anne> the XACML TC home page Anne> (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml) Anne> that does explain some possible approaches. > Possible solution 2: A second request / response is added to the existing communication that would query for the required attributes. This is an in-band solution and would increase the scope of the current specification which is likely not desired. Anne> This would also be allowed. XACML does not constrain how Anne> attribute values are obtains. > Use case: Policy associated with a decision request includes a QoS component from the PEP (such as the load average of the machine on which the PEP resides). The QoS attribues are too expensive to compute (and whose computation may actually affect the QoS) and send with each <Request>. > > > > Use case: A PEP is located within an MTA (mail transport agent). Some policy decisions are made on Bayesian filter results of the email message. These results are too expensive to compute for each email and the email contents are too large to send with each decision request. These attributes should be requested from the PEP IFF a condition requires them. > > o Obligation scope > > Part 1: > > Background: The specification states that obligations will be carried out on the PEP and that if "the PEP does not understand an obligation, then it MUST act as if the PDP had denied access to the requested resource" (section 6.10). > > > > Assumption: The PDP logs all authorization decisions for auditing. > > QoS policy decisions are made based on -actual- results of authorization decisions. > > Question: How does the PEP inform the PDP of the -actual- decision? Anne> This is out of scope for XACML. The PEP should probably Anne> log the actual decisions implemented, since the PDP is Anne> merely responsible for evaluating a policy. > Possible solution 1: An out-of-band response is sent from the PEP to the PDP. This would imply that the communication is outside of the realm of the XACML spec. This approach reduces the affinity of the actual decision from the initial decision request causing potential auditing problems as a second communication channel needs to be authenticated and maintained. > > > > Possible solution 2: A follow-up response is made from the PEP to the PDP. This is an in-band solution and would increase the scope of the current specification. Addressing this issue in the specification as a "protocol issue" may clear up any ambiguities. Anne> Out of scope. You are free to implement such a solution, Anne> however. > Part 2: > > Lines: 1768 - 1770, 2731 - 2733, 2756 - 2757, 2859 - 2862 > > "It MAY include a set of obligations that MUST be fulfilled by the PEP. If the PEP does not understand an obligation, then it MUST act as if the PDP had denied access to the requested resource." > > Question: Has there been consideration to change the language from "does not understand" to "does not understand or cannot fulfill"? If not, what is the recommended action for an obligation that is understood yet is unable to be fulfilled. Anne> That is up to the PEP. If the PEP understands an Anne> obligation, it presumably has some rules about what to do Anne> if it can't fulfill it. Out of scope for XACML. > Possible Solution: Expand the definition of "understood" to include compliance meaning that an obligation is "understood" IFF it can be interpreted and has all necessary attributes (the traditional meaning of "understood") -and- fulfilled. > > Follow up 1: lines 3060 - 3062 use the "fulfill" terminology. > > Follow up 2: the mixing of the terms "understood" and "fulfill" in multiple contexts leads to much ambiguity. Anne> This might be good to clarify in the next revision of the Anne> specification. I think the sense is "If the PEP does not Anne> know what to do when presented with a given obligation, it Anne> MUST act as if the PDP had denied access." > Part 3: > > Background: The specification states that the obligations will be fulfilled on the PEP. (I should point out that the specification does not say that the obligations cannot be carried out elsewhere, but I will assume that obligations are only fulfilled on the PEP.) > > > > Assumption: It is assumed that the implication from Part 2 (above) is that the PEP must both understand and successfully fulfill the obligations in order for access to be allowed. Anne> No, I would interpret the specification to say that the PEP Anne> must know what to do when presented with a given Anne> obligation. What it means to "fulfill" an obligation is up Anne> to the PEP. Anne> The correct handling of obligations is defined via contract Anne> between a policy writer and PEPs. The PDP merely passes Anne> along the value. > It is implied that the obligation is fulfilled at the time of the response in order for the PEP to potentially deny authorization. > Anne> I don't think this is implied. Obligations may involve Anne> future actions. Again, not specified by XACML. Depends on Anne> contract between policy writer and PEP. > > Question 1: Can components, other than the PEP, fulfill obligations? And if not, has any consideration been given to extending obligations to other components? > Anne> Out of scope for XACML. The PEP is free to implement the Anne> fulfilling of obligations in any way consistent with their Anne> requirements. > > Use case: The PEP for a web service is located on a web server. An obligation requires that a record from a data store (which is located on a separate machine) is deleted. The PDP dispatches the obligations to a central "obligation service" which then dispatches the obligation to the data store. > Anne> XACML does not specify or constrain such an Anne> implementation. > > Follow up: The use case outlined above is technologically possible given figure 1 of the specification. The concern is that it is not feasible for one primary reason: a PEP, located in a DMZ, cannot be trusted to initiate such requests back out of the DMZ. The PDP would be a better choice. > Anne> Not XACML's problem to solve. > > Question 2: Has there been any consideration to delayed obligations and their effect on the ability for a PEP to deny an access based on their result? > Anne> This is up to the contract between the policy writer and the Anne> PEP. > > Use case: The obligation is to delete a record after a period of 30 days. (This was derived from the P3P specification.) Anne> XACML can't possibly specify what to do in such cases. Anne> This has to be defined outside of XACML. > Part 4: > > Lines: 2076 - 2077 compared with 1768 (for example) > > "The <Obligations> element SHALL contain a set of obligations that MUST be fulfilled by the PDP in conjunction with the authorization decision." > > Question: This appears to be in conflict with the other normative sections of the specification. There are no other references to the PDP fulfilling the obligations and appears to be in conflict with 5.35. Is this a typo? It is possible that I'm overreading this but the phrase "by the PDP" appears to be in reference to "MUST be fulfilled". Anne> This is an error in the XACML specification. I will put it Anne> on our list of work items to fix. > Thank you for your time. Thank you for your comments. I'm sorry I can't be more helpful, but XACML is not intended to answer most of your questions. Anne -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]