RE: [xacml] [xacml-users] REST Profile - PDP Issues

[Danny Thorpe <Danny.Thorpe@quest.com>]

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