OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  Issue: Ambiguity in defn of Request wrt Attributes Category

    Posted 03-04-2013 06:01
    To TC: The issue here is that it does not appear to me that it specifies anywhere that a single PDP authorization decision is based on a set of <Attributes> element each with a different Category and that there can be at most one <Attributes> element of a specific Category involved in a single decision. I have been working under the assumption that this is true for quite a while now, but recently I have tried to find the supporting documentation to unambiguously validate that claim, and I have been unable to do so, leaving me with the conclusion that either the claim is wrong and that more than one <Attributes> element of the same Category can be involved in a single decision (which I believe to be false), or that the documentation should be improved somewhere to emphasis this fundamental point. The description in the 3.0 spec says: <Attributes> [One to Many] Specifies information about attributes of the request context by listing a sequence of <Attribute> elements associated with an attribute category. One or more <Attributes> elements are allowed. Different <Attributes> elements with different categories are used to represent information about the subject, resource, action, environment or other categories of the access request. While the text above might lead one to believe that one might want to consider only including one <Attributes> element per Category, it says nothing definitive one way or the other. I am well aware that the multi-decision profile uses multiple <Attributes> elements of the same Category as the basis for generating a cross-product to generate Individual Decision Requests , where in section 2.3.3 it states: For each combination of repeated <Attributes> elements, one Individual Decision Request SHALL be created. This Individual Request SHALL be identical to the original request context with one exception: only one <Attributes> element  of each repeated category  SHALL be present. Again, this text is useful wrt providing the ContextHandler w the info it needs to generate multiple decision requests, however, it does not imply that this is a requirement from the PDP side. For example, what would happen if someone submitted a Request with two <Attributes> elements, each for a different Target resource, but both with the same Category, namely: urn:oasis:names:tc:xacml:3.0:attribute-category:resource ? Would this be a request for which the user was asking for access to both resources at the same time? Or would this be an error if the multi-profile was not supported? I don't believe questions like this can be answered w the info in the specs as they currently exist. (unless, of course, I have missed something, which is entirely possible :) )     Thanks,     Rich


  • 2.  Re: [xacml] Issue: Ambiguity in defn of Request wrt Attributes Category

    Posted 03-04-2013 11:38
    Hi, I would say that if you are not supporting multiple decisions, then it's an error. It might be the case that it's not explicitly mentioned in the spec. We should add this to an errata item or an implementer guide. Best regards, Erik On 2013-03-04 01:00, rich levinson wrote: To TC: The issue here is that it does not appear to me that it specifies anywhere that a single PDP authorization decision is based on a set of <Attributes> element each with a different Category and that there can be at most one <Attributes> element of a specific Category involved in a single decision. I have been working under the assumption that this is true for quite a while now, but recently I have tried to find the supporting documentation to unambiguously validate that claim, and I have been unable to do so, leaving me with the conclusion that either the claim is wrong and that more than one <Attributes> element of the same Category can be involved in a single decision (which I believe to be false), or that the documentation should be improved somewhere to emphasis this fundamental point. The description in the 3.0 spec says: <Attributes> [One to Many] Specifies information about attributes of the request context by listing a sequence of <Attribute> elements associated with an attribute category. One or more <Attributes> elements are allowed. Different <Attributes> elements with different categories are used to represent information about the subject, resource, action, environment or other categories of the access request. While the text above might lead one to believe that one might want to consider only including one <Attributes> element per Category, it says nothing definitive one way or the other. I am well aware that the multi-decision profile uses multiple <Attributes> elements of the same Category as the basis for generating a cross-product to generate Individual Decision Requests , where in section 2.3.3 it states: For each combination of repeated <Attributes> elements, one Individual Decision Request SHALL be created. This Individual Request SHALL be identical to the original request context with one exception: only one <Attributes> element  of each repeated category  SHALL be present. Again, this text is useful wrt providing the ContextHandler w the info it needs to generate multiple decision requests, however, it does not imply that this is a requirement from the PDP side. For example, what would happen if someone submitted a Request with two <Attributes> elements, each for a different Target resource, but both with the same Category, namely: urn:oasis:names:tc:xacml:3.0:attribute-category:resource ? Would this be a request for which the user was asking for access to both resources at the same time? Or would this be an error if the multi-profile was not supported? I don't believe questions like this can be answered w the info in the specs as they currently exist. (unless, of course, I have missed something, which is entirely possible :) )     Thanks,     Rich


  • 3.  Re: [xacml] Issue: Ambiguity in defn of Request wrt Attributes Category

    Posted 03-04-2013 18:06
    Hi Erik, That sounds good to me. I believe that is consistent w the process we used for XACML 2.0, so now that 3.0 is in OS state, we should start the errata process: agenda item for next mtg.     Thanks,     Rich On 3/4/2013 6:38 AM, Erik Rissanen wrote: Hi, I would say that if you are not supporting multiple decisions, then it's an error. It might be the case that it's not explicitly mentioned in the spec. We should add this to an errata item or an implementer guide. Best regards, Erik On 2013-03-04 01:00, rich levinson wrote: To TC: The issue here is that it does not appear to me that it specifies anywhere that a single PDP authorization decision is based on a set of <Attributes> element each with a different Category and that there can be at most one <Attributes> element of a specific Category involved in a single decision. I have been working under the assumption that this is true for quite a while now, but recently I have tried to find the supporting documentation to unambiguously validate that claim, and I have been unable to do so, leaving me with the conclusion that either the claim is wrong and that more than one <Attributes> element of the same Category can be involved in a single decision (which I believe to be false), or that the documentation should be improved somewhere to emphasis this fundamental point. The description in the 3.0 spec says: <Attributes> [One to Many] Specifies information about attributes of the request context by listing a sequence of <Attribute> elements associated with an attribute category. One or more <Attributes> elements are allowed. Different <Attributes> elements with different categories are used to represent information about the subject, resource, action, environment or other categories of the access request. While the text above might lead one to believe that one might want to consider only including one <Attributes> element per Category, it says nothing definitive one way or the other. I am well aware that the multi-decision profile uses multiple <Attributes> elements of the same Category as the basis for generating a cross-product to generate Individual Decision Requests , where in section 2.3.3 it states: For each combination of repeated <Attributes> elements, one Individual Decision Request SHALL be created. This Individual Request SHALL be identical to the original request context with one exception: only one <Attributes> element  of each repeated category  SHALL be present. Again, this text is useful wrt providing the ContextHandler w the info it needs to generate multiple decision requests, however, it does not imply that this is a requirement from the PDP side. For example, what would happen if someone submitted a Request with two <Attributes> elements, each for a different Target resource, but both with the same Category, namely: urn:oasis:names:tc:xacml:3.0:attribute-category:resource ? Would this be a request for which the user was asking for access to both resources at the same time? Or would this be an error if the multi-profile was not supported? I don't believe questions like this can be answered w the info in the specs as they currently exist. (unless, of course, I have missed something, which is entirely possible :) )     Thanks,     Rich


  • 4.  RE: [xacml] Issue: Ambiguity in defn of Request wrt Attributes Category

    Posted 03-05-2013 16:25
    +1   From: rich levinson Sent: Monday, March 04, 2013 1:05 PM To: Erik Rissanen Cc: xacml@lists.oasis-open.org Subject: Re: [xacml] Issue: Ambiguity in defn of Request wrt Attributes Category   Hi Erik, That sounds good to me. I believe that is consistent w the process we used for XACML 2.0, so now that 3.0 is in OS state, we should start the errata process: agenda item for next mtg.     Thanks,     Rich On 3/4/2013 6:38 AM, Erik Rissanen wrote: Hi, I would say that if you are not supporting multiple decisions, then it's an error. It might be the case that it's not explicitly mentioned in the spec. We should add this to an errata item or an implementer guide. Best regards, Erik On 2013-03-04 01:00, rich levinson wrote: To TC: The "issue" here is that it does not appear to me that it specifies anywhere that a single PDP authorization decision is based on a set of <Attributes> element each with a different Category and that there can be at most one <Attributes> element of a specific Category involved in a single decision. I have been working under the assumption that this is true for quite a while now, but recently I have tried to find the supporting documentation to unambiguously validate that claim, and I have been unable to do so, leaving me with the conclusion that either the claim is wrong and that more than one <Attributes> element of the same Category can be involved in a single decision (which I believe to be false), or that the documentation should be improved somewhere to emphasis this fundamental point. The description in the 3.0 spec says: "<Attributes> [One to Many] Specifies information about attributes of the request context by listing a sequence of <Attribute> elements associated with an attribute category. One or more <Attributes> elements are allowed. Different <Attributes> elements with different categories are used to represent information about the subject, resource, action, environment or other categories of the access request." While the text above might lead one to believe that one might want to consider only including one <Attributes> element per Category, it says nothing definitive one way or the other. I am well aware that the multi-decision profile uses multiple <Attributes> elements of the same Category as the basis for generating a cross-product to generate "Individual Decision Requests", where in section 2.3.3 it states: "For each combination of repeated <Attributes> elements, one Individual Decision Request SHALL be created. This Individual Request SHALL be identical to the original request context with one exception: only one <Attributes> element  of each repeated category  SHALL be present." Again, this text is useful wrt providing the ContextHandler w the info it needs to generate multiple decision requests, however, it does not imply that this is a requirement from the PDP side. For example, what would happen if someone submitted a Request with two <Attributes> elements, each for a different Target resource, but both with the same Category, namely: "urn:oasis:names:tc:xacml:3.0:attribute-category:resource"? Would this be a request for which the user was asking for access to both resources at the same time? Or would this be an error if the multi-profile was not supported? I don't believe questions like this can be answered w the info in the specs as they currently exist. (unless, of course, I have missed something, which is entirely possible :) )     Thanks,     Rich