[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: > Cc: xacml@lists.oasis-open.org > Betreff: RE: [xacml] PDP REST Interface - proposal --> standardised PAP > interface > > Jan, > > > > -----Original Message----- > > From: Jan Herrmann [mailto: > > 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 Jan > > > 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]