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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

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


Subject: Re: Fwd: [xacml-users] Single request to query multiple resourceswith multiple actions on each resource


Hi Yoichi,

The intent of the 3.0 multiple profile has been that by specifying 
multiple <Attributes> elements, all combinations of subject, resource, 
action or another categories can be used, so what Ludwig describes is 
how it should work. See section 2.2.3 in the CD-1 version of the 3.0 
Multiple resource profile:

--8<--
Each <Attributes> element SHALL represent one Individual Resource, 
subject, or another category unless that element utilizes the other 
mechanisms described in this Profile.
For each combination of repeated <Attributes> elements, one Individual 
Resource Request SHALL be created.
--8<--

Best regards,
Erik


Yoichi Takayama wrote:
> *From: *Yoichi Takayama <takayama.yoichi@gmail.com 
> <mailto:takayama.yoichi@gmail.com>>
> *Date: *23 September 2009 11:52:09 AM PDT
> *To: *Ludwig Seitz <ludwig@axiomatics.com <mailto:ludwig@axiomatics.com>>
> *Cc: *Andy Bailey <andy@hazlorealidad.com 
> <mailto:andy@hazlorealidad.com>>, xacml-users 
> <xacml-users@lists.oasis-open.org 
> <mailto:xacml-users@lists.oasis-open.org>>, Seth Proctor 
> <Seth.Proctor@sun.com <mailto:Seth.Proctor@sun.com>>
> *Subject: **Re: [xacml-users] Single request to query multiple 
> resources with multiple actions on each resource*
>
> The XACML "Multi" document (mentioned in the 3.0 Core document) refers 
> to multiple *Resources*, nothing on multiple Actions or it was not 
> intended for it (although the XACML 3.0 Request context syntax could 
> make it possible). Although it mentions that multiple Subjects, 
> Subjects is not usually used to ask about multiple decisions on them, 
> but to ask wether as a group those Subjects together may take some 
> Action on some Resource or not. 
>
> Again, XACML 3.0 Request syntax and the use of the Multiple Resource 
> syntax will allow generating a Request on each Subject separately when 
> multiple Subjects are defined, but such is not indicated. Normally 
> defining multiple Subjects will mean "AND" not "FOR EACH".
>
>
> Also, there is no such a thing as automatic generation of all possible 
> combinations of Actions and Resources, if you are using the 2.3 
> Multiple <Attributes> elements, in XACML v3.0 Multiple Resource 
> Profile Version 1.0. If you are using XPath or by "node" or "scope", 
> of course automatically multiple resources may be included, but in 
> such cases you do not specify individual resources one by one in your 
> Request context. So, that is entirely a different situation.
>
>
> Example:
>
>
> <Request>
> <RequestDefaults /><!-- optional -->
> <Attributes Category="attriburte-category:*subject*" id="subject1">...
> <Attributes Category="attriburte-category:*action*" id="action1">...
> <Attributes Category="attriburte-category:*resource*" id="*resource1*">
> <Attribute AttributeId="resource:resource-id" IncludeInResult="true">
> <AttributeValue>patient:Jim Jones:medical records</AttributeValue>
> <AttributeValue>patient:Mary Clark:medical records</AttributeValue>
> <AttributeValue>...</AttributeValue>
> ...
> <!-- it could have multiple AttributeValue elements -->
> <Attribute/>
> <Attribute AttributeId="resource:resource-category" 
> IncludeInResult="true">
> <AttributeValue>CT Scan</AttributeValue>
> <AttributeValue>X-ray images</AttributeValue>
> <AttributeValue>MRI images</AttributeValue>
> <Attribute/>
> ...
> <!-- it could have multiple Attribute elements -->
> </Attributes>
> <Attributes Category="attriburte-category:*resource*" id="*resource2*">
> <!-- Attrbutes does not necessary contain any resource-id -->
> <!-- In such a case, the meaning of MultipleReqauest is obscure -->
> <Attribute AttributeId="resource:resource-category" 
> IncludeInResult="true">
> <AttributeValue>Heart diagnostics</AttributeValue>
> </Attribute>
> <Attribute/>
> </Attributes>
> <Attributes Category="attriburte-category:*resource*" id="*resource3*">
> <Attribute AttributeId="resource:resource-classification" 
> IncludeInResult="true">
> <AttributeValue>urgent</AttributeValue>
> <AttributeValue>pending</AttributeValue>
> <Attribute/>
> </Attributes>
> <Attributes Category="attriburte-category:*resource*" id="*resource4*">
> <Attribute AttributeId="resource:resource-archived" 
> IncludeInResult="true">
> <AttributeValue>any</AttributeValue>
> <Attribute/>
> </Attributes>
> ...
> * **<MultiRequests>*
> * **<RequestReference>*
> * **<AttributesReference ReferenceID="subject1"/>*
> * **<!-- Is Subject necesary? -->*
> * **<AttributesReference ReferenceID="action1"/>*
> * **<!-- Is Action necessary -->*
> * **<AttributesReference ReferenceID="resource1"/>*
> * **<!-- This generates a normal single Resource request -->*
> * **<RequestReference>*
> * **<RequestReference>*
> * **<!-- What happens if Subject and Action are omitted? --?*
> * **<AttributesReference ReferenceID="resource2"/>*
> * **<AttributesReference ReferenceID="resource3"/>*
> * **<!-- This creates a Request to determin*
> * **whether the Subject is allowed to*
> * **take the Action (presumably) on BOTH of these Resources.*
> * **The Response will contain mentions for both*
> * **of these Attribute elements but would not say*
> * **whether EITHER or BOTH can be accessed. *
> * **The Response will contain one Result element, *
> * **which will contain one Attrubtes elements, *
> * **which will list all Attribute elements (and values?) *
> * **which were used for the decision. But the exact syntax*
> * **is not desribed in the OASIS documents-->*
> * **<RequestReference>*
> * **</MultiRequests>*
> </Request>
>
> As you can see, you are supposed to manually construct what Requests 
> will be generated. It is only that the only one Request (containing 
> specifications for multiple Requests) will be made to PDP and one 
> Response (with multiple Result elements) will be returned.
>
> XACML v3.0 Multiple Resource Profile Version 1.0
>
> 148 2.3 Multiple <Attributes> elements 
> 149 {Optional}
> 150 This Section describes use of multiple <Attributes> elements with 
> the same category in a request 
> 151 context to specify a request for access to multiple *resources* or 
> requests for access by multiple *subjects*. 
> 152 This syntax MAY be used with any resource or resources, regardless 
> of whether they are XML 
> 153 documents or not and regardless of whether they are hierarchical 
> resources [Hierarchical] or not.
>
>
> As you can see, the multiple Actions could be referred in this 
> section, too, but that is not mentioned.
>
>
> Yoichi
>
>
>
>
> On 23/09/2009, at 2:26 AM, Ludwig Seitz wrote:
>
>> On Tue, 2009-09-22 at 09:48 -0500, Andy Bailey wrote:
>>> Ludwig,
>>>
>>> Thanks for the quick reply.
>>>
>>> Can you provide a sample request and response using <MultiRequests>
>>> its not clear to me from the 3.0 spec how it works.
>>
>> Sorry MultiRequests is something else (although you could probably also
>> achieve your goal with that). I was suggesting the method from section
>> 2.3 in the XACML v3.0 Multiple Resource Profile.
>>
>> Basically what you do is you send your request with multiple resource
>> and action (and whatever) elements
>> Example (very simplified):
>> Request
>>   Subject = Alice
>>   Resource = file1 (includeInResult=true)
>>   Resource = file2 (includeInResult=true)
>>   Action = read with (includeInResult=true)
>>   Action = write with (includeInResult=true)
>>
>> And the PDP will test every combination of {file1, file2} and
>> {read,write}
>>
>> giving you an answer like this (again very simplified):
>>
>> Response
>> Result = Permit
>>  Attributes
>>    Resource = file1
>>    Action = read
>> Result = Deny
>>  Attributes
>>    Resource = file1
>>    Action = write
>> Result = Permit
>>  Attributes
>>    Resource = file2
>>    Action = read
>> Result = Permit
>>  Attributes
>>    Resource = file2
>>    Action = write
>>
>> I have attached the "real" XACML files if you want to see the whole
>> thing.
>>
>>> I assume the policy doesnt change at all.
>>>
>> Except for the syntax. XACML 3.0 has introduced a few changes in the
>> XAMCL syntax. Have a look at the examples in the XACML 3.0 core document
>> to get an idea what they are.
>>
>> Regards,
>>
>> Ludwig Seitz
>>
>> PS: Just to set things straight: Sunxacml _does_ the Multiple Resource
>> profile for XACML 2.0 (although I don't know if it is 100% correct).
>>
>>
>> -- 
>> Ludwig Seitz, PhD             |   Axiomatics AB
>> Training & Development        |   Electrum 223
>> Phone: +46 (0)760 44 22 91    |   S-164 40 Kista, Sweden
>> Mail: ludwig@axiomatics.com <mailto:ludwig@axiomatics.com>   |
>> <Request.xml><Response.xml>
>
>



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