Hi Erik,
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).
Best regards
Jan
Siemens AG
Corporate Technology
Corporate Research and Technologies
CT T DE IT1
Otto-Hahn-Ring 6
81739 Munich, Germany
Tel.: +49 89 636-40612
Fax: +49 89 636-48000
mailto:jan.herrmann@siemens.com
Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive Officer; Roland Busch,
Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Suess; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No.
DE 23691322
Important notice: This e-mail and any attachment thereof contain corporate proprietary information. If you have received it by mistake, please notify us immediately by reply
e-mail and delete this e-mail and its attachments from your system. Thank you.
Von: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org]
Im Auftrag von Erik Rissanen
Gesendet: Dienstag, 28. Februar 2012 11:23
An: xacml@lists.oasis-open.org
Betreff: Re: [xacml] AW: Issue #4: Context Handler - Proposal
Hi Jan,
I think adding obligation handling to the PDP side would be a too big change to the current architecture at this point. It opens up questions such as whether obligations which were processed by the PDP, should they be sent to the PEP as well? If not, is that
safe? If so, should the PEP know which ones were already handled? Just a couple from the top of my head.
Best regards,
Erik
On 2012-02-27 10:22, Herrmann, Jan wrote:
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.
Best regards
Jan
PS: regrets that I can only irregularly attend the teleconferences but they take place during our family dinner time.
Siemens AG
Corporate Technology
Corporate Research and Technologies
CT T DE IT1
Otto-Hahn-Ring 6
81739 Munich, Germany
Tel.: +49 89 636-40612
Fax: +49 89 636-48000
mailto:jan.herrmann@siemens.com
Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive Officer; Roland Busch,
Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Suess; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No.
DE 23691322
Important notice: This e-mail and any attachment thereof contain corporate proprietary information. If you have received it by mistake, please notify us immediately by reply
e-mail and delete this e-mail and its attachments from your system. Thank you.
All,
Current text
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
Proposal
Context handler
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.
Current text
474 4. The context handler constructs an XACML request context and sends it to the PDP.
Proposal
4. The context handler constructs an XACML request context, optionally adds attributes, and sends it to the PDP.
Current text
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.
Proposal
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.
Thanks,
Ray
---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-help@lists.oasis-open.org