OASIS eXtensible Access Control Markup Language (XACML) TC

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:04
     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)


    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.
    >
    >  
    >
    
    


    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]