MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] #31: Passing arbitrary sets of Attributes in the request(Re: [xacml] Minutes of 27 April 2006 XACML TC Meeting)
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]