OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AW: Issue #4: Context Handler - Proposal


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.

 

 

 

Von: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] Im Auftrag von remon.sinnema@emc.com
Gesendet: Freitag
, 24. Februar 2012 16:31
An: xacml@lists.oasis-open.org
Betreff: [xacml] Issue #4: Context Handler - Proposal

 

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

 

Attachment: example_rewrite-rule.pdf
Description: example_rewrite-rule.pdf

Attachment: Details on how to use the XACML obligation mechanism to achieve a rewriting of intercepted Web Service messages.pdf
Description: Details on how to use the XACML obligation mechanism to achieve a rewriting of intercepted Web Service messages.pdf



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]