Re: [xacml] #31: Passing arbitrary sets of Attributes in the request(Re: [xacml] Minutes of 27 April 2006 XACML TC Meeting)

[Frank Siebenlist <franks@mcs.anl.gov>]

You're using the word "clean" quite a bit...

In our java-implementation, we have the equivalent of a request context
that has a set of attribute-set's, and "admin,subject,resource,action"
artifacts that each refer to one of those attribute-sets through a
direct (pointer-)reference. If the evaluation has to go recursively down
to resolve delegation chains, you essentially re-wire the references of
the actors to the attribute-sets for each new eval.

Now that's what I call clean ;-)

My hope was that we could mimic this in the XML-representation also.

If you pass those attribute-sets essentially out-of-band, then you make
them second-class citizen and leave it to individual implementations to
figure out how to deal with them. That doesn't sound clean to me.

-Regards, Frank.


Erik Rissanen wrote:
> The description of the processing model would be more complex since it
> has to refer to two distinct ways to find attributes. First, through the
> Delegate section of the current request context, and second, through
> this new proposed special section in the request context. I just don't
> see why it necessary to treat attributes passed with the request
> differently from other attributes. We don't have  a special section in
> the request for attributes found in a directory, another section for
> attributes provided by the PDP (for instance time of day), another
> section for attributes loaded from a file on disk, etc.
>
> Specifically section 7.2.5 of the standard would have to be made more
> complex. If we do not modify the request context, then there are no
> needed changes.
>
> Yes, I agree that you end up with the equivalent processing in either
> case, but the difference is in that the standard and the XACML schema
> will be cleaner if we do not introduce special constructs.
>
> Yes, an implementation would need to have a special structure with a
> pointer to the attributes provided while it evaluates a request, but
> this is the case in any way, since no PDP implementation would work with
> the XML form of request context. It's all internal data structures by
> that stage. This state is not global. It is per request.
>
> The PDP will still be "functional" if you don't implement any other ways
> to find attributes besides the attributes provided in the SAML request.
>
> There is one benefit with Frank's approach. It is that if there are
> multiple interfaces for invoking a PDP, say the SAML profile and then
> maybe also a WS-*-profile, then having this functionality in the xacml
> schema, then both of these interfaces could potentially inherit the new
> functionality.
>
> Personally, I think the benefit of a cleaner processing model is bigger.
> Anyway, this is my opinion, and I can live either way. :-) I suggest
> that the TC should make an informed decision on this issue so we can put
> it at rest. We have been discussing it since the Ottawa F2F now. Perhaps
> it would be good if you Frank join the discussion on the phone with us?
> What do you see as the big benefits of changing the Request context?
>
> Regards, Erik
>
> Frank Siebenlist wrote:
>
>   
>> #31: Passing arbitrary sets of Attributes in the request
>>         (for use with subsequent potential delegates).  Erik
>>         thinks it would just make the request and its evaluation
>>         more complex; would need a way to refer to these
>>         "potential attributes".  Are the Attributes "invisible"
>>         until the associated delegate appears in the reduction?
>>         Erik proposes passing such Attributes would be outside
>>         the core specification.  Implementation-specific Context
>>         Handler is responsible for making these available when
>>         appropriate.  Erik thinks these should be added to the
>>         SAML Profile.  Alternative would be putting them in the
>>         XACML Request.  Profile would provide way to pass
>>         Attributes in XACML Attribute format, so they don't have
>>         to be converted back to SAML Attributes.  Profile will
>>         also need an ID element structure so Context Handler can
>>         tell which identity various Attributes are associated
>>         with.
>>
>>
>> Could Erik maybe elaborate on the issues raised?
>>
>> I do not understand arguments that passing the attribute sets in the
>> request context makes the evaluation more complex.
>> What is the alternative? Wouldn't you always end-up with the equivalent
>> processing no matter how you pass them?
>>
>> If you do not pass them in a "functional" argument, then you have to
>> rely on global state to pass those attribute sets, which is most of the
>> time undesirable.
>>
>> We have the equivalent working in our Globus Toolkit authorization
>> Java-code for some time now...
>>
>> Regards, Frank.
>>
>>  
>>
>>     
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>   

-- 
Frank Siebenlist               franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory