OASIS eXtensible Access Control Markup Language (XACML) TC

Greg and Franz-Stefan, You have worked out how to handle the SAML part pretty well. I have a few suggestions. I still don't agree with the local/global mapping approach for XACML, but have an alternate proposal, as well as a suggestion that might put the local/global mapping on a better footing if it is really a required feature. 1. A suggestion for writing the SAML profile: instead of specifying the evaluation of AttributePredicate with reference to a hypothetical XACML policy evaluation, maybe you could just refer to section 7.4 of the XACML spec for how to evaluate expressions. 2. I had to read closely to determine that the required return type of the AttributePredicate/Apply/@FunctionId is boolean. Consider putting this earlier in the description. 3. Is it necessary to allow multiple AttributePredicate elements in a query? It seems simpler to have the relying party wrap its predicates in an "and" function if they want this behavior. 4. I'm not too familiar with SAML, so I assume that the samlp:Status/samlp:StatusCode/@Value attribute is the conventional way to confirm or deny a SAML assertion? For the purpose at hand it seems like a roundabout way of communicating the truth-value of a (potentially) complex predicate. Rather than just echoing the predicate back to the relying party, could there be a dedicated AttributePredicateResponse with Result=true false? Optionally, the predicate could be returned as well. This would be analagous to the XACML Response, with optional return of the Request attributes. 5. Some of the preceding comments are to support a scenario that is not addressed in your proposal but was mentioned in the TC call of 2011-03-24. That is, allow the PDP during the course of its evaluation to call an IDP to evaluate an AttributePredicateQuery. The content of the query could be a literal chunk of the policy being evaluated, or a partially-processed chunk (e.g. with known attribute values in place of AttributeDesignator elements). In either case, the query would have to conform to the restrictions given in the profile. I would favor a very slim XACML profile to specify this sort of behavior--but I'm not sure just what needs to be specified, as it is really just an implementation option. It does not affect the specified result of policy evaluation or add any syntactic or functional features to the XACML core. 6. Policy evaluation using AttributePredicateQuery seems to obviate the need for local/global attribute mapping. Weren't local boolean attributes introduced as a feature of an earlier design solution for this problem? Now that the design has advanced further, they are not needed. If however, there are real use cases requiring them, you should specify how to bind the local boolean attribute to the predicate over global attributes. Your draft specifically excludes this mechanism from standardization, but that is exactly the point that would facilitate interoperability. I have some ideas on that but will hold until the requirement is confirmed. Regards, --Paul

Hi Paul, Thanks for your comments, responses are in-line. > 1. A suggestion for writing the SAML profile: instead of specifying the > evaluation of AttributePredicate with reference to a hypothetical XACML > policy evaluation, maybe you could just refer to section 7.4 of the > XACML spec for how to evaluate expressions. I guess we could, but Section 7.4 in the XACML spec seems somewhat short. Especially how AttributeDesignator elements need to be treated seems to need a bit of clarification, don't you think? > 2. I had to read closely to determine that the required return type of > the AttributePredicate/Apply/@FunctionId is boolean. Consider putting > this earlier in the description. Okay, will do. > 3. Is it necessary to allow multiple AttributePredicate elements in a > query? It seems simpler to have the relying party wrap its predicates > in an "and" function if they want this behavior. I agree that the semantics of having multiple predicates in a query/assertion is equivalent to an AND over the same predicates. When using the local/global attribute mapping that we proposed for XACML, though, it is quite likely that one may need assertions for multiple predicates (corresponding to multiple local variables). It makes sense to bundle the queries/responses for all these predicates in a single query/response. > 4. I'm not too familiar with SAML, so I assume that the > samlp:Status/samlp:StatusCode/@Value attribute is the conventional way > to confirm or deny a SAML assertion? For the purpose at hand it seems > like a roundabout way of communicating the truth-value of a > (potentially) complex predicate. Rather than just echoing the predicate > back to the relying party, could there be a dedicated > AttributePredicateResponse with Result=true false? Optionally, the > predicate could be returned as well. This would be analagous to the > XACML Response, with optional return of the Request attributes. When a predicate is not explicitly included in the response, is it still possible to have the description of the predicate (and not just some ID/reference to it) be signed by the XML Signature? If so, then you're right, one could make the predicate optional in the response. If not, then there's a danger that, if the PEP and IDP communicate over an insecure connection or through redirects via the user, an adversary replaces the queried predicate with a fake predicate and so that a "true" response from the IDP would be misinterpreted by the PEP as being for the real predicate instead of the fake predicate. > 5. Some of the preceding comments are to support a scenario that is not > addressed in your proposal but was mentioned in the TC call of > 2011-03-24. That is, allow the PDP during the course of its evaluation > to call an IDP to evaluate an AttributePredicateQuery. The content of > the query could be a literal chunk of the policy being evaluated, or a > partially-processed chunk (e.g. with known attribute values in place of > AttributeDesignator elements). In either case, the query would have to > conform to the restrictions given in the profile. I would favor a very > slim XACML profile to specify this sort of behavior--but I'm not sure > just what needs to be specified, as it is really just an implementation > option. It does not affect the specified result of policy evaluation or > add any syntactic or functional features to the XACML core. I'm not sure I understand your point here. Which "restrictions given in the profile" do you mean, those specified in section 3.2 of our draft? Which sort of behavior do you exactly mean? > 6. Policy evaluation using AttributePredicateQuery seems to obviate the > need for local/global attribute mapping. Weren't local boolean > attributes introduced as a feature of an earlier design solution for > this problem? Now that the design has advanced further, they are not > needed. If however, there are real use cases requiring them, you should > specify how to bind the local boolean attribute to the predicate over > global attributes. Your draft specifically excludes this mechanism from > standardization, but that is exactly the point that would facilitate > interoperability. I have some ideas on that but will hold until the > requirement is confirmed. Do you mean that the attribute predicate profile as specified in our draft obviates the need for the local/global attribute mapping? I actually don't think so. As discussed before, there are some research challenges to be solved to feed the attribute predicates straight to the PDP and let the PDP decide whether they imply the policy or not. (Cf. the Prolog-style statements you once illustrated on the Wiki.) As long as we haven't tackled those issues, the local/global translation solution is the best we have. Greg

On Mon, 2011-04-04 at 15:26 +0200, Gregory Neven wrote: > Hi Paul, > > Thanks for your comments, responses are in-line. > > > 1. A suggestion for writing the SAML profile: instead of specifying the > > evaluation of AttributePredicate with reference to a hypothetical XACML > > policy evaluation, maybe you could just refer to section 7.4 of the > > XACML spec for how to evaluate expressions. > > I guess we could, but Section 7.4 in the XACML spec seems somewhat > short. Especially how AttributeDesignator elements need to be treated > seems to need a bit of clarification, don't you think? I agree, but you don't--and shouldn't--clarify the behavior in the profile. As I understand it, you don't intend to change the semantics of the xacml expression elements that are used in AttributePredicateQuery. So you should refer to the XACML spec for how to evaluate them. > > > 2. I had to read closely to determine that the required return type of > > the AttributePredicate/Apply/@FunctionId is boolean. Consider putting > > this earlier in the description. > > Okay, will do. > > > 3. Is it necessary to allow multiple AttributePredicate elements in a > > query? It seems simpler to have the relying party wrap its predicates > > in an "and" function if they want this behavior. > > I agree that the semantics of having multiple predicates in a > query/assertion is equivalent to an AND over the same predicates. When > using the local/global attribute mapping that we proposed for XACML, > though, it is quite likely that one may need assertions for multiple > predicates (corresponding to multiple local variables). It makes sense > to bundle the queries/responses for all these predicates in a single > query/response. I don't think such hypothetical use cases justify defining AttributePredicateQuery as a conjunctive list. You're adding a built-in logical construction in an area that should be completely user-defined. By comparison, the XACML Condition element only allows one top-level expression. The XACML Target element is defined as a conjunctive list, but it serves a different purpose, and has some history behind it so it is somewhat justified. > > > 4. I'm not too familiar with SAML, so I assume that the > > samlp:Status/samlp:StatusCode/@Value attribute is the conventional way > > to confirm or deny a SAML assertion? For the purpose at hand it seems > > like a roundabout way of communicating the truth-value of a > > (potentially) complex predicate. Rather than just echoing the predicate > > back to the relying party, could there be a dedicated > > AttributePredicateResponse with Result=true false? Optionally, the > > predicate could be returned as well. This would be analagous to the > > XACML Response, with optional return of the Request attributes. > > When a predicate is not explicitly included in the response, is it still > possible to have the description of the predicate (and not just some > ID/reference to it) be signed by the XML Signature? If so, then you're > right, one could make the predicate optional in the response. If not, > then there's a danger that, if the PEP and IDP communicate over an > insecure connection or through redirects via the user, an adversary > replaces the queried predicate with a fake predicate and so that a > "true" response from the IDP would be misinterpreted by the PEP as being > for the real predicate instead of the fake predicate. Transmission-level security is not my strong suit, but I would think there would be other, better ways to protect and verify the communication. Apparently the SAML communication idioms are different from XACML, so I will stay out of this part. > > > 5. Some of the preceding comments are to support a scenario that is not > > addressed in your proposal but was mentioned in the TC call of > > 2011-03-24. That is, allow the PDP during the course of its evaluation > > to call an IDP to evaluate an AttributePredicateQuery. The content of > > the query could be a literal chunk of the policy being evaluated, or a > > partially-processed chunk (e.g. with known attribute values in place of > > AttributeDesignator elements). In either case, the query would have to > > conform to the restrictions given in the profile. I would favor a very > > slim XACML profile to specify this sort of behavior--but I'm not sure > > just what needs to be specified, as it is really just an implementation > > option. It does not affect the specified result of policy evaluation or > > add any syntactic or functional features to the XACML core. > > I'm not sure I understand your point here. Which "restrictions given in > the profile" do you mean, those specified in section 3.2 of our draft? > Which sort of behavior do you exactly mean? Here is the scenario: while evaluating a policy with respect to a request context, the PDP realizes it cannot evaluate an expression because it does not have a value for a particular subject attribute, and it cannot fetch the value from a PIP. It does, however, know about an IDP that can handle this particular attribute and can respond to an AttributePredicateQuery. So the PDP carves out the entire Apply expression in which that attribute occurs, resolves AttributeDesignators that it does know about (replacing them with AttributeValues), forms an AttributePredicateQuery containing the Apply element, and ships it off (along with the subject identifier) to the IDP. It gets the return value and continues with its policy evaluation, marking the Apply element as true or false (or indeterminate) based on the saml:Response to the AttributePredicateQuery. The effect is exactly the same as what you describe, but without the need for a local boolean attribute. > > > 6. Policy evaluation using AttributePredicateQuery seems to obviate the > > need for local/global attribute mapping. Weren't local boolean > > attributes introduced as a feature of an earlier design solution for > > this problem? Now that the design has advanced further, they are not > > needed. If however, there are real use cases requiring them, you should > > specify how to bind the local boolean attribute to the predicate over > > global attributes. Your draft specifically excludes this mechanism from > > standardization, but that is exactly the point that would facilitate > > interoperability. I have some ideas on that but will hold until the > > requirement is confirmed. > > Do you mean that the attribute predicate profile as specified in our > draft obviates the need for the local/global attribute mapping? I > actually don't think so. As discussed before, there are some research > challenges to be solved to feed the attribute predicates straight to the > PDP and let the PDP decide whether they imply the policy or not. (Cf. > the Prolog-style statements you once illustrated on the Wiki.) As long > as we haven't tackled those issues, the local/global translation > solution is the best we have. In the scenario I described above, the PDP is just outsourcing a bit of the policy evaluation, perhaps to minimize exposure of a particular attribute value outside of the IDP. If that is possible, I don't see what is the requirement for local attributes standing in for attribute predicates. This scenario does not require the request context itself to contain attribute assertions nor does it require the PDP to evaluate policy expressions against attribute assertions. The IDP does all the hard work by evaluating AttributePredicateQuerys. I believe AttributeAssertions in the request context (as I described on the wiki) would still provide a nice architectural option, but more research is required to put all the pieces together. Regards, --Paul > > Greg >

Hi Paul, > >>> 1. A suggestion for writing the SAML profile: instead of specifying the >>> evaluation of AttributePredicate with reference to a hypothetical XACML >>> policy evaluation, maybe you could just refer to section 7.4 of the >>> XACML spec for how to evaluate expressions. >> I guess we could, but Section 7.4 in the XACML spec seems somewhat >> short. Especially how AttributeDesignator elements need to be treated >> seems to need a bit of clarification, don't you think? > I agree, but you don't--and shouldn't--clarify the behavior in the > profile. As I understand it, you don't intend to change the semantics > of the xacml expression elements that are used in > AttributePredicateQuery. So you should refer to the XACML spec for how > to evaluate them. Okay, but then the profile would at least mention against which request context the predicate needs to be evaluated, no? I.e., the context containing all known attributes about the subject. >>> 3. Is it necessary to allow multiple AttributePredicate elements in a >>> query? It seems simpler to have the relying party wrap its predicates >>> in an "and" function if they want this behavior. >> [...] When >> using the local/global attribute mapping that we proposed for XACML, >> though, it is quite likely that one may need assertions for multiple >> predicates (corresponding to multiple local variables). It makes sense >> to bundle the queries/responses for all these predicates in a single >> query/response. > [...] > By comparison, the XACML Condition element only allows one top-level > expression. The XACML Target element is defined as a conjunctive list, > but it serves a different purpose, and has some history behind it so it > is somewhat justified. I guess I'm too "young" in this TC to know about the history of the Target element ;-) but I can see your comparison to the Condition element. I actually presented the same issue to the SAML TC during their call last Tuesday, and there people seemed to agree with you as well. So let's restrict to a single AttributePredicate per query/assertion, as you suggested. >>> 4. [...] Rather than just echoing the predicate >>> back to the relying party, could there be a dedicated >>> AttributePredicateResponse with Result=true false? Optionally, the >>> predicate could be returned as well. This would be analagous to the >>> XACML Response, with optional return of the Request attributes. >> [...] >> then there's a danger that, if the PEP and IDP communicate over an >> insecure connection or through redirects via the user, an adversary >> replaces the queried predicate with a fake predicate and so that a >> "true" response from the IDP would be misinterpreted by the PEP as being >> for the real predicate instead of the fake predicate. > Transmission-level security is not my strong suit, but I would think > there would be other, better ways to protect and verify the > communication. Apparently the SAML communication idioms are different > from XACML, so I will stay out of this part. You're right though that there are communication settings in which a yes/no response would do. I would insist that the IDP should at least have the option to include the predicate in the assertion in other communcation settings, but I guess by making it optional, all communication settings can be dealt with in the most efficient way. > Here is the scenario: while evaluating a policy with respect to a > request context, the PDP realizes it cannot evaluate an expression > because it does not have a value for a particular subject attribute, and > it cannot fetch the value from a PIP. It does, however, know about an > IDP that can handle this particular attribute and can respond to an > AttributePredicateQuery. So the PDP carves out the entire Apply > expression in which that attribute occurs, resolves AttributeDesignators > that it does know about (replacing them with AttributeValues), forms an > AttributePredicateQuery containing the Apply element, and ships it off > (along with the subject identifier) to the IDP. It gets the return > value and continues with its policy evaluation, marking the Apply > element as true or false (or indeterminate) based on the saml:Response > to the AttributePredicateQuery. The effect is exactly the same as what > you describe, but without the need for a local boolean attribute. After your clarifications during the call, I now better understand your point how this approach eliminates the need for local/global attribute translation. So you're suggesting that the PDP, during the policy evaluation, calls out directly to the IDP with an attribute predicate query taken from the Condition. But there are no predicates being passed in the request context, and the PDP does not have to perform "intelligent matching" between predicates in the request context and in the policy. Then the only remaining issue is _which_ Apply expression the PDP "carves out". I already discussed this issue and possible solutions on slide 14 of http://www.oasis-open.org/committees/document.php?document_id=39960 . Namely, the PDP could use (in order of increasing privacy-friendliness) the lowest Apply statement with a boolean return type, a higher-up Apply statement with boolean return type and containing only AttributeDesignator with the IDP as issuer, or the entire Condition. We could leave it up to the implementation of the PDP to decide which strategy it follows. > I believe AttributeAssertions in the request context (as I described on > the wiki) would still provide a nice architectural option, but more > research is required to put all the pieces together. I absolutely agree. Greg

>
Original Message----- > From: Gregory Neven [ mailto:nev@zurich.ibm.com ] > Sent: Monday, April 04, 2011 3:26 PM > To: Paul Tyson > Cc: XACML > Subject: Re: [xacml] Comments on Attribute predicate profile for SAML > and XACML > > > 4. I'm not too familiar with SAML, so I assume that the > > samlp:Status/samlp:StatusCode/@Value attribute is the conventional > way > > to confirm or deny a SAML assertion? For the purpose at hand it > seems > > like a roundabout way of communicating the truth-value of a > > (potentially) complex predicate. Rather than just echoing the > predicate > > back to the relying party, could there be a dedicated > > AttributePredicateResponse with Result=true false? Optionally, the > > predicate could be returned as well. This would be analagous to the > > XACML Response, with optional return of the Request attributes. > > When a predicate is not explicitly included in the response, is it > still > possible to have the description of the predicate (and not just some > ID/reference to it) be signed by the XML Signature? If so, then you're > right, one could make the predicate optional in the response. If not, > then there's a danger that, if the PEP and IDP communicate over an > insecure connection or through redirects via the user, an adversary > replaces the queried predicate with a fake predicate and so that a > "true" response from the IDP would be misinterpreted by the PEP as > being > for the real predicate instead of the fake predicate. If there is an adversary in the middle, couldn't he just return true to the PEP anyway, without invoking the IDP at all? I think we should assume a secure connection.