OASIS eXtensible Access Control Markup Language (XACML) TC

I have a number of different kinds of comments about the REST Profile and Media types which will post separately to allow the discussion to take place in distinct threads. Section 2.2.2 is not very clear about what precisely goes into the POST request and response exchanged with a PDP, but the example shows XACML <Request> and <Response> elements being sent. (Minor point: it is customary to use a namespace qualified name and define the namespace tags near the beginning of the doc. Specifications frequently reference several XML schemas and they could contain the same element names. In particular, common words like Request and Response are likely to appear in many schemas.) However, the current, SOAP-based wire protocol which is specified in section 4 of the SAML Profile of XACML wraps the request in a XACMLAuthzDecisionQuery request and the response is wrapped in an Assertion and XACMLAuthzDecisionQuery response. These wrappers add complexity, but provide a number of useful capabilities. I would suggest reviewing these to determine if any this functionality would be of value in this profile. One feature I believe is required is Request/Response correlation. The SAML-derived request/response solve this problem by means of the ID and InResponseTo XML Attributes. Assuming HTTP 1.1 may be used and considering that a typical PEP is a multithreaded server, the possibility of having more than one request outstanding at the same time arises. Therefore it becomes necessary to figure out what request the PDP has said to Permit. This could be done by means of the IncludeInResponse feature, but that involves additional transmission and processing overhead. If your intention is to set a limit of one outstanding request per TCP session, then that should be stated explicitly. IMO the SAML InResponseTo scheme or something equivalent to it is the easiest way to solve the problem. For the record, the Request includes: Issuer Signature ID Version Issue Instant Destination Consent Processing Flags InputContextOnly ReturnContext CombinePolicies AdditionalAttributes Policy PolicySet ReferencedPolicies AdditionalAttributes AssignedAttributes Holders HolderAttributes Much of this applies only to the Admin Profile, which we could choose not to support in this protocol, but I would like an explicit decision to that effect. The Assertion includes: Issuer Signature ID Version Issue Instant Validity Period The Response includes: Issuer Signature ID InResponseTo Version Issue Instant Destination Consent Status (covered by the HTTP Status Code) Hal --------------------------------------------------------------------- To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xacml-users-help@lists.oasis-open.org

Hal, > -----Original Message----- > From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On > Behalf Of Hal Lockhart > Sent: Wednesday, May 16, 2012 11:26 PM > To: xacml@lists.oasis-open.org > Subject: [xacml] [xacml-users] REST Profile - PDP Issues > > Section 2.2.2 is not very clear about what precisely goes into the POST > request and response exchanged with a PDP, but the example shows XACML > <Request> and <Response> elements being sent. Yeah, I struggled with that a bit. Since the actual media type definitions are now outside the REST profile, I find it difficult to be precise. Any suggestions for improvement? > (Minor point: it is customary to use a namespace qualified name and > define the namespace tags near the beginning of the doc. Specifications > frequently reference several XML schemas and they could contain the > same element names. In particular, common words like Request and > Response are likely to appear in many schemas.) Not all formats have the concept of namespaces (e.g. JSON), so in the interest of being neutral in terms of representation, I felt I couldn't use namespaces here. I used wording like "XACML request" to address this issue. Does that sound reasonable? > However, the current, SOAP-based wire protocol which is specified in > section 4 of the SAML Profile of XACML wraps the request in a > XACMLAuthzDecisionQuery request and the response is wrapped in an > Assertion and XACMLAuthzDecisionQuery response. These wrappers add > complexity, but provide a number of useful capabilities. I would > suggest reviewing these to determine if any this functionality would be > of value in this profile. > > One feature I believe is required is Request/Response correlation. The > SAML-derived request/response solve this problem by means of the ID and > InResponseTo XML Attributes. > > Assuming HTTP 1.1 may be used and considering that a typical PEP is a > multithreaded server, the possibility of having more than one request > outstanding at the same time arises. Therefore it becomes necessary to > figure out what request the PDP has said to Permit. Since we're using POST, which is non-idempotent ( http://tools.ietf.org/html/rfc2616#section-9.1.2 ), we must not use HTTP pipelining ( http://tools.ietf.org/html/rfc2616#section-8.1.2.2 ). So a request will always have to wait for the response and thus there can be no confusion as to which response belongs to which request. Or am I missing something? Thanks, Ray

> > Section 2.2.2 is not very clear about what precisely goes into the > > POST request and response exchanged with a PDP, but the example shows > > XACML <Request> and <Response> elements being sent. > > Yeah, I struggled with that a bit. Since the actual media type > definitions are now outside the REST profile, I find it difficult to be > precise. Any suggestions for improvement? > I don't see why you can explicitly call out schema and outermost XML element and specifically say you must send this or can send either this or this. > > > (Minor point: it is customary to use a namespace qualified name and > > define the namespace tags near the beginning of the doc. > > Specifications frequently reference several XML schemas and they > could > > contain the same element names. In particular, common words like > > Request and Response are likely to appear in many schemas.) > > Not all formats have the concept of namespaces (e.g. JSON), so in the > interest of being neutral in terms of representation, I felt I couldn't > use namespaces here. I used wording like "XACML request" to address > this issue. Does that sound reasonable? I was thinking primarily of the examples here. <Request> is potentially ambiguous. <xs:request> with a suitable definition of xs, is not. I would still like to hear from others as to whether we need any of the other features provided by the wrappers. > > > However, the current, SOAP-based wire protocol which is specified in > > section 4 of the SAML Profile of XACML wraps the request in a > > XACMLAuthzDecisionQuery request and the response is wrapped in an > > Assertion and XACMLAuthzDecisionQuery response. These wrappers add > > complexity, but provide a number of useful capabilities. I would > > suggest reviewing these to determine if any this functionality would > > be of value in this profile. > > > > One feature I believe is required is Request/Response correlation. > The > > SAML-derived request/response solve this problem by means of the ID > > and InResponseTo XML Attributes. > > > > Assuming HTTP 1.1 may be used and considering that a typical PEP is a > > multithreaded server, the possibility of having more than one request > > outstanding at the same time arises. Therefore it becomes necessary > to > > figure out what request the PDP has said to Permit. > > Since we're using POST, which is non-idempotent > ( http://tools.ietf.org/html/rfc2616#section-9.1.2 ), we must not use > HTTP pipelining ( http://tools.ietf.org/html/rfc2616#section-8.1.2.2 ). My reading of rfc 2616 - 9.1.2 is that POST is not REQUIRED to be idempotent. As a matter of fact, we know an XACML decision request IS idempotent. > So a request will always have to wait for the response and thus there > can be no confusion as to which response belongs to which request. Or > am I missing something? I don't see how this restriction could be acceptable in a production environment. Managing a large connection pool and scheduling requests onto available connections is complicated and may have its own performance implications. Making every request wait in line is unacceptable. Remember the DPD server may go off and do things that take a "long" time, like fetching attribute values from other repositories. I would like to hear what others think. Hal

-----Original Message----- From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Hal Lockhart Sent: Thursday, May 17, 2012 7:42 AM To: remon.sinnema@emc.com; xacml@lists.oasis-open.org Subject: RE: [xacml] [xacml-users] REST Profile - PDP Issues > > Section 2.2.2 is not very clear about what precisely goes into the > > POST request and response exchanged with a PDP, but the example > > shows XACML <Request> and <Response> elements being sent. > > Yeah, I struggled with that a bit. Since the actual media type > definitions are now outside the REST profile, I find it difficult to > be precise. Any suggestions for improvement? > I don't see why you can explicitly call out schema and outermost XML element and specifically say you must send this or can send either this or this. <<<< Hal, did you mean "cannot explicitly..." there? >>> > > Since we're using POST, which is non-idempotent > ( http://tools.ietf.org/html/rfc2616#section-9.1.2 ), we must not use > HTTP pipelining ( http://tools.ietf.org/html/rfc2616#section-8.1.2.2 ). My reading of rfc 2616 - 9.1.2 is that POST is not REQUIRED to be idempotent. As a matter of fact, we know an XACML decision request IS idempotent. <<< ?? The XACML decision request POST may be idempotent on the request side, but not on the response side. Identical XACML requests may return different responses if the policies in force are dependent upon time of request or other contextual data not carried in the request that changes between requests. Access permitted at 4:59pm, access denied at 5:01pm. -Danny

Danny, > -----Original Message----- > From: Danny Thorpe [ mailto:Danny.Thorpe@quest.com ] > Sent: Thursday, May 17, 2012 8:19 PM > To: Hal Lockhart; Sinnema, Remon; xacml@lists.oasis-open.org > Subject: RE: [xacml] [xacml-users] REST Profile - PDP Issues > > > Since we're using POST, which is non-idempotent > > ( http://tools.ietf.org/html/rfc2616#section-9.1.2 ), we must not use > > HTTP pipelining ( http://tools.ietf.org/html/rfc2616#section-8.1.2.2 ). > > My reading of rfc 2616 - 9.1.2 is that POST is not REQUIRED to be > idempotent. As a matter of fact, we know an XACML decision request IS > idempotent. > <<< > > ?? The XACML decision request POST may be idempotent on the request > side, but not on the response side. Identical XACML requests may return > different responses if the policies in force are dependent upon time of > request or other contextual data not carried in the request that > changes between requests. Access permitted at 4:59pm, access denied at > 5:01pm. After re-reading, I think Hal is right. RFC 2616 defines idempotence in terms of side-effects. An access request should not have side effects, so it is idempotent, even though the response may change when the request is repeated. In fact, an access request is even safe ( http://tools.ietf.org/html/rfc2616#section-9.1.1 ). So that kills my argument against HTTP pipelining, and therefore Hal is probably right that we need to write something up on how to handle it. Thanks, Ray

Ok. So a POST can have no side effects but return different results and still be considered idempotent. Thanks, -Danny Danny Thorpe Product Architect Quest Software - Now including the people and products of BiTKOO www.quest.com -----Original Message----- From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of remon.sinnema@emc.com Sent: Thursday, May 17, 2012 2:10 PM To: Danny Thorpe Cc: xacml@lists.oasis-open.org Subject: RE: [xacml] [xacml-users] REST Profile - PDP Issues Danny, > -----Original Message----- > From: Danny Thorpe [ mailto:Danny.Thorpe@quest.com ] > Sent: Thursday, May 17, 2012 8:19 PM > To: Hal Lockhart; Sinnema, Remon; xacml@lists.oasis-open.org > Subject: RE: [xacml] [xacml-users] REST Profile - PDP Issues > > > Since we're using POST, which is non-idempotent > > ( http://tools.ietf.org/html/rfc2616#section-9.1.2 ), we must not use > > HTTP pipelining ( http://tools.ietf.org/html/rfc2616#section-8.1.2.2 ). > > My reading of rfc 2616 - 9.1.2 is that POST is not REQUIRED to be > idempotent. As a matter of fact, we know an XACML decision request IS > idempotent. > <<< > > ?? The XACML decision request POST may be idempotent on the request > side, but not on the response side. Identical XACML requests may > return different responses if the policies in force are dependent upon > time of request or other contextual data not carried in the request > that changes between requests. Access permitted at 4:59pm, access > denied at 5:01pm. After re-reading, I think Hal is right. RFC 2616 defines idempotence in terms of side-effects. An access request should not have side effects, so it is idempotent, even though the response may change when the request is repeated. In fact, an access request is even safe ( http://tools.ietf.org/html/rfc2616#section-9.1.1 ). So that kills my argument against HTTP pipelining, and therefore Hal is probably right that we need to write something up on how to handle it. Thanks, Ray --------------------------------------------------------------------- To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xacml-help@lists.oasis-open.org

> > > Section 2.2.2 is not very clear about what precisely goes into the > > > POST request and response exchanged with a PDP, but the example > > > shows XACML <Request> and <Response> elements being sent. > > > > Yeah, I struggled with that a bit. Since the actual media type > > definitions are now outside the REST profile, I find it difficult to > > be precise. Any suggestions for improvement? > > > I don't see why you can explicitly call out schema and outermost XML > element and specifically say you must send this or can send either this > or this. > <<<< > > Hal, did you mean "cannot explicitly..." there? Yes, sorry I meant "can't". > > > >>> > > > > Since we're using POST, which is non-idempotent > > ( http://tools.ietf.org/html/rfc2616#section-9.1.2 ), we must not use > > HTTP pipelining ( http://tools.ietf.org/html/rfc2616#section-8.1.2.2 ). > > My reading of rfc 2616 - 9.1.2 is that POST is not REQUIRED to be > idempotent. As a matter of fact, we know an XACML decision request IS > idempotent. > <<< > > ?? The XACML decision request POST may be idempotent on the request > side, but not on the response side. Identical XACML requests may return > different responses if the policies in force are dependent upon time of > request or other contextual data not carried in the request that > changes between requests. Access permitted at 4:59pm, access denied at > 5:01pm. This is true, however this functionality can actually be controlled by the InputContextOnly XML attribute which appears in the <XACMLAuthzDecisionQuery>. This is another reason it might be desirable to allow the use of the Req/Resp wrappers. I still think for anything but a demo, requiring synchronous requests is a complete non-starter. hal

Hal, > -----Original Message----- > From: Hal Lockhart [ mailto:hal.lockhart@oracle.com ] > Sent: Thursday, May 17, 2012 4:42 PM > To: Sinnema, Remon; xacml@lists.oasis-open.org > Subject: RE: [xacml] [xacml-users] REST Profile - PDP Issues > > > > (Minor point: it is customary to use a namespace qualified name and > > > define the namespace tags near the beginning of the doc. > > > Specifications frequently reference several XML schemas and they > > could > > > contain the same element names. In particular, common words like > > > Request and Response are likely to appear in many schemas.) > > > > Not all formats have the concept of namespaces (e.g. JSON), so in the > > interest of being neutral in terms of representation, I felt I > couldn't > > use namespaces here. I used wording like "XACML request" to address > > this issue. Does that sound reasonable? > > I was thinking primarily of the examples here. <Request> is potentially > ambiguous. <xs:request> with a suitable definition of xs, is not. The example reads: <Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"> <!-- XACML request --> </Request> I do use a (default) namespace here, so I don't see how <Request> can be ambiguous. Thanks, Ray

> > I was thinking primarily of the examples here. <Request> is > > potentially ambiguous. <xs:request> with a suitable definition of xs, > is not. > > The example reads: > > <Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"> > <!-- XACML request --> > </Request> > > I do use a (default) namespace here, so I don't see how <Request> can > be ambiguous. Good point. This is mainly a style issue. I guess I am still stuck in the past where we had distinct Schemas for the Policies and the Protocols. Hal

Hal, TC, > -----Original Message----- > From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On > Behalf Of Hal Lockhart > Sent: Wednesday, May 16, 2012 11:26 PM > To: xacml@lists.oasis-open.org > Subject: [xacml] [xacml-users] REST Profile - PDP Issues > > One feature I believe is required is Request/Response correlation. The > SAML-derived request/response solve this problem by means of the ID and > InResponseTo XML Attributes. > > Assuming HTTP 1.1 may be used and considering that a typical PEP is a > multithreaded server, the possibility of having more than one request > outstanding at the same time arises. Therefore it becomes necessary to > figure out what request the PDP has said to Permit. > > This could be done by means of the IncludeInResponse feature, but that > involves additional transmission and processing overhead. If your > intention is to set a limit of one outstanding request per TCP session, > then that should be stated explicitly. IMO the SAML InResponseTo scheme > or something equivalent to it is the easiest way to solve the problem. I've looked at HTTP pipelining in more detail. RFC 2617 states that the responses must be send back in the order that the requests arrived: http://tools.ietf.org/html/rfc2616#section-8.1.2.2 So for HTTP pipelining, there doesn't seem to be an issue of correlating request and response. If there are other scenarios where this really is an issue, then we could add custom HTTP headers that correspond to the ID and InResponseTo SAML attributes. I wonder if this is a common enough use case to warrant standardization in the REST profile? What do people think? Thanks, Ray

XACML already has a request/response correlation mechanism in the IncludeInResult attribute of the Attribute element. Granted, this isn't as succinct as requiring unique message ids and InResponseTo headers, but if an application is running into confusion over which response is for which request, it seems to me that the application can turn on IncludeInResult for request Attributes sufficiently specific to perform response correlation. For that matter, the application could simplify correlation by embedding a client-generated token unique within the client's scope as an <Attribute IncludeInResult="true"> in the request. The attribute is of no interest to the PDP. It exists solely to simplify response correlation back at the client. Given that an application can embed a "message id" of its own design as an attribute in the XACML request and receive it back in the response, is it really necessary to add correlation complexity at the protocol level? -Danny Danny Thorpe Product Architect Quest Software - Now including the people and products of BiTKOO www.quest.com -----Original Message----- From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of remon.sinnema@emc.com Sent: Friday, May 18, 2012 6:28 AM To: hal.lockhart@oracle.com; xacml@lists.oasis-open.org Subject: RE: [xacml] [xacml-users] REST Profile - PDP Issues Hal, TC, > -----Original Message----- > From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] > On Behalf Of Hal Lockhart > Sent: Wednesday, May 16, 2012 11:26 PM > To: xacml@lists.oasis-open.org > Subject: [xacml] [xacml-users] REST Profile - PDP Issues > > One feature I believe is required is Request/Response correlation. The > SAML-derived request/response solve this problem by means of the ID > and InResponseTo XML Attributes. > > Assuming HTTP 1.1 may be used and considering that a typical PEP is a > multithreaded server, the possibility of having more than one request > outstanding at the same time arises. Therefore it becomes necessary to > figure out what request the PDP has said to Permit. > > This could be done by means of the IncludeInResponse feature, but that > involves additional transmission and processing overhead. If your > intention is to set a limit of one outstanding request per TCP > session, then that should be stated explicitly. IMO the SAML > InResponseTo scheme or something equivalent to it is the easiest way to solve the problem. I've looked at HTTP pipelining in more detail. RFC 2617 states that the responses must be send back in the order that the requests arrived: http://tools.ietf.org/html/rfc2616#section-8.1.2.2 So for HTTP pipelining, there doesn't seem to be an issue of correlating request and response. If there are other scenarios where this really is an issue, then we could add custom HTTP headers that correspond to the ID and InResponseTo SAML attributes. I wonder if this is a common enough use case to warrant standardization in the REST profile? What do people think? Thanks, Ray --------------------------------------------------------------------- To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xacml-help@lists.oasis-open.org