OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

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

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

    Posted 04-28-2006 07:53
     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]