[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)
Yes, I am proposing that we should leave that to individual implementations, like all attributes currently. It seems to me that the kind of implementation you are talking about would work with both proposals. But if you think you have a better solution, could you provide a concrete proposal for how you want the XML schema and the processing model to be? I think it would help the discussion a lot if there were concrete proposals to consider for everyone. Regards, Erik Frank Siebenlist wrote: > 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 >> >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]