Subject: AW: [xacml] AW: Issue #4: Context Handler - Proposal
thanks for your feedback. The current version of the spec leaves it open where the XACML Context Handler is placed. It could be part of the PEP, a separate SW-component or might even be integrated in the PDP (which I never thought about so far). Ideally the mandatory guidelines in the spec should be applicable to all these different cases as they only describe different logical aggregations of code. So far I encountered the first two cases only and the spec supports both cases without posing any inconsistent requirements. The questions you mentioned are of course valid but address the scenario of chains of XACML Context Handlers. From my point of view, the core XACML spec should only address the handling of XACML authorization requests and responses. The mapping of the application domain specifics to and from XACML authorization requests and responses should be out of scope – as far as possible. This aspect points out another advantage of triggering the obligation handling in the context Handler. Assume e.g. that the XACML Context Handler and the PEP do not speak XACML. Transforming XACML obligations into another language might be the source of various problems and might further imply the risk of loosing interoperability (assume e.g. that you agreed on certain types of XACML obligations like e.g. rewrite-obligations in an use case specific XACML profile).
Hi Ray, all,
I like your edits and I think that they point out the flexibilities of XACML Context Handlers’ behavior. I would even go one step further and add some text blocks in these sentences, that highlight the option, that Context Handlers can also call Obligation Handlers. I have seen many use cases/requirements where XACML Context Handlers need to call Obligation Handlers to discharge the obligations included in an XACML authorization decision. Note that in these scenarios it was not possible/appropriate to discharge the obligations in the PEP (assuming that the Context Handler is not included in the PEP), as the Obligations had an effect on the representation of intercepted Web Service messages included in the XACML authorization decision request (which is only available in the Context Handler and not in the PEP).
Some background information on these use cases:
The underlying requirement of these use cases is to enforce rewrite effects on intercepted Web Service requests (or responses). Enforcing rewrite effects is needed in cases where you need to apply access restrictions on intercepted Web Service requests that shall e.g. limit read requests to certain objects (e.g. rewrite the query “select * from person” to the authorized query “select * from person WHERE person.id = dereferenced-subject-id-attr”). The concepts behind this is a more general and DBMS independent form of what can e.g. be done through Oracle’s VPD mechanism. The attached word document describes the details how to use the XACML obligation mechanism to achieve a XACML policy controlled rewriting of intercepted Web Service messages. Feel free to contact me if you need further explanations. One more note: a very similar approach can be taken to generate sub-requests that will be forwarded to the PIP and tell him how to retrieve more data in order to avoid/solve indeterminate responses.
PS: regrets that I can only irregularly attend the teleconferences but they take place during our family dinner time.
30 Context handler
31 The system entity that converts decision requests in the native request format to the XACML
32 canonical form and converts authorization decisions in the XACML canonical form to the native
33 response format
The system entity that converts decision requests in the native request format to the XACML canonical form, coordinates with Policy Information Points to add attribute values to the request context, and converts authorization decisions in the XACML canonical form to the native response format.
474 4. The context handler constructs an XACML request context and sends it to the PDP.
4. The context handler constructs an XACML request context, optionally adds attributes, and sends it to the PDP.
3280 7.3.5 Attribute Retrieval
3281 The PDP SHALL request the values of attributes in the request context from the context handler. The
3282 PDP SHALL reference the attributes as if they were in a physical request context document, but the
3283 context handler is responsible for obtaining and supplying the requested values by whatever means it
3284 deems appropriate.
7.3.5 Attribute Retrieval
The PDP SHALL request the values of attributes in the request context from the context handler. The context handler MAY also add attributes to the request context without the PDP requesting them. The PDP SHALL reference the attributes as if they were in a physical request context document, but the context handler is responsible for obtaining and supplying the requested values by whatever means it deems appropriate, including by retrieving them from one or more Policy Information Points.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org