Re: [xacml] MAD conceptual model

[Erik Rissanen <erik@axiomatics.com>]

Paul, All,

I find this proposal hard to follow because it mixes all the different 
schemes into a single long description. I agree that the spec currently 
lacks a good summary of in which order the various transforms should be 
done, but I think it is better to describe each transformation of  a 
multiple request in a separate section, in a more modular fashion. Also, 
I have a preference for doing the Cartesian product of repeated 
categories before the scope transformation. I just find that easier to 
work with mentally, but that might be a personal preference. :-)

I would propose something like this (with some material stolen from Paul):

This profile specifies four different schemes by which multiple requests 
for authorization decisions can be encoded into a single XACML <Request> 
element. These schemes can be nested. An implementation MUST behave such 
that it will produce identical results as if would perform the following 
operations.

1. For each MultiRequest/RequestReference in the request, create a new
   request context, as specified in section 2.4 in this profile.  If 
there are no <MultiRequest>
   elements, then use the original request context as input to the
   following steps. If there are any errors, include the errors in the 
final result defined in step 5 below, while any valid <Request> is 
processed as defined by the following steps.

2. For each <Request> element from the previous step which contains 
<Attributes> elements with repeated values for the Category XML 
attribute, perform the processing defined in section 2.3 of this 
profile. The outputs of this processing and any <Request> elements 
without repeated values for the Category XML attribute form the inputs 
for the following steps. If there are any errors, include the errors in 
the final result defined in step 5 below, while any valid <Request> is 
processed as defined by the following steps.

3. For each <Request> element from the previous step which specifies a 
"scope" attribute, perform the processing defined in sections 2.1 and 
2.2 of this profile to expand the <Request> context into multiple 
individual <Request> contexts, to be used as the inputs in the next 
step. If there is no "scope" attribute, use that <Request> context as it 
is in the next step. If there are any errors, include the errors in the 
final result defined in step 5 below, while any valid <Request> is 
processed as defined by the following steps.

4. At this stage each <Request> is a request for an individual 
authorization decision. Each <Request> MUST be processed by the PDP as 
an individual access control request according to the XACML core 
specification and any implemented profiles and extensions.

5. The final result of the original <Request> element which was the 
input to step 1 above is a <Response> which contains all collected 
errors from steps one through three and all the individual results from 
step 4 as <Result> elements.

Best regards,
Erik


Tyson, Paul H wrote:
> Attached version has a few corrections and clarifications.
>
> --Paul 
>
>   
>> -----Original Message-----
>> From: Tyson, Paul H 
>> Sent: Friday, October 16, 2009 09:59
>> To: xacml@lists.oasis-open.org
>> Subject: [xacml] MAD conceptual model
>>
>> Attached find proposed description of conceptual model for 
>> producing single authorization decision requests from a 
>> multiple authorization decision (MAD) request.
>>
>> This would replace some content in sections 2.1, 2.2, 2.3.
>>
>> I came up with a few questions and concerns:
>>
>> 1. I still don't like the idea of mutable resource-ids.  
>> Either the original request should have something like 
>> "resource-selector", or the resulting context should have 
>> "decision-node-id" or something.  But then the problem is, 
>> how does the PEP request the resource-id to be returned 
>> (using "IncludeInResult")?  We might have to specify some 
>> built-in semantics to handle this.
>>
>> 2. This does not specify how the xpathExpression resource-id 
>> for individual resources will be constructed.  The TC is 
>> still discussing whether to specify this, and if so, what the 
>> form should be.  In any case, it seems necessary to say 
>> something about the namespace binding context that will be 
>> used for name prefixes.  Default might be to use the 
>> namespace binding context represented by the union of the 
>> contexts in <Content> children, but this is not specified. 
>> One way to facilitate regexp matching on xpath strings would 
>> be to allow policies and/or requests to specify a namespace 
>> binding context.
>>
>> 3. scope=EntireHierarchy is out of place here.  Consider 
>> moving Section
>> 3 to hierarchical profile.  The conceptual model and expected 
>> results are different than the other multiple authorization 
>> decision modes.  The "multiple" processing only takes place 
>> internally--a single decision is expected (possibly 
>> multiplied by additional subjects or actions).
>>
>> Regards,
>> --Paul
>>
>>     
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> 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