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: [xacml] PDP REST Interface - proposal --> standardised PAP interface

Hi Ray,

see comments inline...


> -----Ursprüngliche Nachricht-----

> Von: remon.sinnema@emc.com [mailto:remon.sinnema@emc.com]

> Gesendet: Mittwoch, 25. Mai 2011 11:22

> An: herrmanj@in.tum.de

> Cc: xacml@lists.oasis-open.org

> Betreff: RE: [xacml] PDP REST Interface - proposal --> standardised PAP

> interface


> Jan,



> > -----Original Message-----

> > From: Jan Herrmann [mailto:herrmanj@in.tum.de]

> > Sent: Wednesday, May 25, 2011 11:04 AM

> > To: Sinnema, Remon

> > Cc: xacml@lists.oasis-open.org

> > Subject: AW: [xacml] PDP REST Interface - proposal --> standardised PAP

> > interface

> >

> > So far we have a XML based request/response language in mind.


> What's the granularity of that language? A whole Policy(Set)? An

> individual Rule?


The signatures of a XACML v3.0 Policy Administration Web Service (XACML-PAWS) could be as follows:

mandatory XACML-PAWS module:

ˇ         createFileContainer(String Store, String containerName)

ˇ         createTableContainer(String Store, String ContainerName, String createTableDefinition)

ˇ         insertPolicyElement(String containerName, XPath pathToFather, String namespace, XML xacmlPolicyElement)

§         where xacmlPolicyElement is either a <PolicySet>, <Policy>, <PolicySetIdReference>, <PolicyIdReference>, <Rule>

§         Note that it can be left open to the user whether he wants to insert nested <PolicySet> and <Policy> elements. In use cases where you control access on the insert requests to a PAWS it might however make things easier to restrict the possibility to have nested <PolicySet> and <Policy> elements by corresponding metarules (i.e. rules that refer to PAWS requests). Doing so enforces a step-by-step construction of the polices and makes the definition of administrative rules a lot easier.

ˇ         insertPolicyElementBefore(String containerName, XPath pathToSibling, String namespace, XML xacmlPolicyElement)

ˇ         insertPolicyElementAfter(String containerName, XPath pathToSibling, String namespace, XML xacmlPolicyElement)

ˇ         updatePolicyElement(String containerName, XPath pathToNode, String namespace, XML xacmlPolicyElement, Boolean deep)

§         the deep argument is used to control whether the existing children elements of the element to update shall remain childrens without explicit repetition in the updated version

ˇ         selectPolicyElement(String containerName, XPath pathToNode, String <Namespace>, Boolean deep, Boolean dereference)

§         the deep parameter is use to control whether only a local part or the whole subtree shall be selected. Via the dereference parameter one can dereference Policy(SetIdReference Elements

ˇ         deletePolicyElement(String containerName, XPath pathToNode, String <Namespace>)


optional XACML-PAWS moduls:

ˇ         analyze(String analyzeFunctionName, [String containerName, XPath pathToNode, String <Namespace>]+)

ˇ         optimize(String containerName, XPath pathToNode, String <Namespace>, String optimizeFunctionName, XML optimizeFunctionParameters)

ˇ         test(String containerName, XPath pathToNode, String <Namespace>, XML xacmlAutorisationDecisionRequest)



> Are there shortcuts for specialized rules like ACLs?


next to the basic functions one could add additional operations. What do you mean by these specialised rules (effect=x, resource-id=y, action-id=z) Tupels?





> > The transport protocol used to submit these messages could either be

> soap or http/post.


> I have no interest in SOAP, but I am interested in the PAP interface

> itself.



> > Using http/Get is not very suitable.


> Agreed for updating policies, but not for retrieving them.


In our use cases we are protecting Web Services by intercepting and controlling the messages exchanged with these service. Having xml encoded requests (ore more precisely a standardised xml encoded representation of these requests in the xacml adr) allows to enforce more expressible access rights based on the intercepted request. If there are strong arguments to support a KVP-based requests than it should always be in addition to xml encoded request formats. If this is the case, it should be guaranteed, that kvp encoded requests transmitted over http/get can be uniquely transformed into a xml encoded version.



Best regards





> Thanks,

> Ray



> ---------------------------------------------------------------------

> To unsubscribe from this mail list, you must leave the OASIS TC that

> generates this mail.  Follow this link to all your TCs in OASIS at:

> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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