OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

Re: [xacml] saml authz request vs request context (Re: [xacml] Issuesfor the next delegation draft)

  • 1.  Re: [xacml] saml authz request vs request context (Re: [xacml] Issuesfor the next delegation draft)

    Posted 11-02-2005 07:50
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

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


    Subject: Re: [xacml] saml authz request vs request context (Re: [xacml] Issuesfor the next delegation draft)


    Hi Frank,
    
    I have trimmed some more of the message history to keep it short.
    
    Frank Siebenlist wrote:
    
    > Hi Erik,
    >
    > I've split the email to focus the discussion on the saml authz request
    > vs request context.
    >
    > Erik Rissanen wrote:
    >
    >>
    >>
    >> It was decided that the additional attributes and policies would be
    >> added to the xacml-saml authorization query interface, but _not_ to the
    >> request context. The request context is not a transport format. It is an
    >> abstract model for describing the processing model. It was reused as a
    >> transport format in the current saml profile because that was an easy
    >> and quick solution, but since the addition of additional attributes in
    >> the request context does not fit the request context from the processing
    >> point of view, it was decided to instead redo the saml authz request.
    >>
    >> The saml authz request would contain mechanisms for passing additional
    >> attributes as well as indicating the primary keys among them. The
    >> attributes would migrate from the saml request to the context handler in
    >> an implementation specific manner. From the context handler, they will
    >> become available in the request context in the same form as "normal"
    >> attributes that were not coming from "outside".
    >>
    >> The F2F minutes are a bit confusing, as you say, since we did not know
    >> for sure exactly what your requirements are. I suppose what would be
    >> good is if you could propose concrete syntax for the saml authz request.
    >>   
    >
    >
    > Could you comment on issue# 31?
    >
    > It discusses the problem of not having the attributes available in the
    > nested eval calls without some global knowledge.
    >
    > Personally I'd like to see the request context as a "functional"
    > interface that you pass all the information that can be used in the
    > evaluation.
    >
    > Note that a call-back like "findAttribute(URI)" doesn't break that
    > functional paradigm (for me it's kind of a hack that allows lazy
    > attribute fetching ;-) )
    > Furthermore, such a call-back only works if you can name the attribute
    > through the URI, which consists of a path through the current request
    > context - the latter, however, changes when you recursively call the
    > eval function...which would imply that the findAttribute() has to work
    > in a context of the last caller.
    >
    > Actually, I don't even understand how an implementation would work if
    > you do not pass all the attribute sets through the request context...
    > could you walk me through that?
    >
    > Lastly, what is the argument against passing all the arguments in the
    > request context and by having the saml-xacml authz call use the 
    > identical request context?
    
    
    It was Hal who suggested to move this to the SAML profile, so perhaps he
    would be best suited to explain the motivation, but I agree with him, so
    I will try to give my explanation here.
    
    The request context will support your requirements as it is, without
    extension. Let's assume that we add new elements to the SAML
    authorization query. It would look something like this:
    
    <SAMLAuthorizationThingy>
      <RequestCtx>
        <Subject>...</>
        <Resource>...</>
        <Action>...</>
        <Environment>...</>
      </RequestCtx>
      <AdditionalAttributes>
        <Entity>
          <Attribute id="group"><AttributeValue>administrator</></>
          <Attribute id="hairColor"><AttributeValue>red</></>
          <Attribute id="x509_id"
    identityAttribute="true"><AttributeValue>john</></>
        <Entity>
        <Entity>
          <Attribute id="group"><AttributeValue>supervisor</></>
          <Attribute id="driversLicense"><AttributeValue>true</></>
          <Attribute id="x509_id"
    identityAttribute="true"><AttributeValue>lisa</></>
        <Entity>
      </AdditionalAttributes>
      <Policy>...</>
      <Policy>...</>
      <Policy>...</>
    </SAMLAuthorizationThingy>
    
    Here the request context is the access request with which to start the
    process. It contains attributes of the access subject, resource, action
    and environment. The additional attributes are attributes that may be
    needed later in the processing. The policy elements are additional
    policies that are to be used during the evaluation of this request.
    
    Now, the above is the transport format. The PDP server has an interface
    which is used by a PEP. The server interface will split the transport
    format: The additional attributes will be sent to the context handler
    and the policies will be sent to the policy repository/finder of the
    PDP. The reqeust context is sent to the PDP for processing. Now suppose
    that later on during the processing we arrive at the following
    administrative request:
    
    <RequestCtx>
      <Subject>...</>
      <Resource>...</>
      <Action>...</>
      <Environment>...</>
      <Delegate>
        <Attribute id="x509_id"
    identityAttribute="true"><AttributeValue>john</></>
      </Delegate>
    </RequestCtx>
    
    In this case the delegate attribute comes from a PolicyIssuer element in
    a policy that is being reduced. Since the additional attributes from the
    transport format are available in the context handler, the request
    context can be expanded to include the additional attributes:
    
    <RequestCtx>
      <Subject>...</>
      <Resource>...</>
      <Action>...</>
      <Environment>...</>
      <Delegate>
        <Attribute id="group"><AttributeValue>administrator</></>
        <Attribute id="hairColor"><AttributeValue>red</></>
        <Attribute id="x509_id"
    identityAttribute="true"><AttributeValue>john</></>
      </Delegate>
    </RequestCtx>
    
    Also, the context handler might have other attributes available from
    somewhere else than the transport request, so it could expand the
    attributes further:
    
    <RequestCtx>
      <Subject>...</>
      <Resource>...</>
      <Action>...</>
      <Environment>...</>
      <Delegate>
        <Attribute id="clearance"><AttributeValue>top_secret</></>
        <Attribute id="group"><AttributeValue>administrator</></>
        <Attribute id="hairColor"><AttributeValue>red</></>
        <Attribute id="x509_id"
    identityAttribute="true"><AttributeValue>john</></>
      </Delegate>
    </RequestCtx>
    
    As you can see, the request context is already enough to capture the
    scenario. The details of how the context handler works are
    implementation specific. In the case of the sunxacml implementation,
    which I am familiar with, the implementation would consist of an
    attribute finder module which has a table of the additional attributes
    indexed by the identity attributes. In the module there would be a
    method to add the attributes to the finder module before the request
    evaluation is started. When the finder module is called during the
    processing, it has access to the request context object, where it can
    find the identity attributes with which to look for additional attributes.
    
    In my opinion there is no need to add additional XML to the request
    context in order to make it the storage point for these additional
    attributes during processing. The argument against doing it is that
    there is already the concept of the context handler in the processing
    model and there is no need to make treatment of these attributes that
    arrive to the server with a request any different from those attributes
    that the server receives by some other channel, for instance by querying
    an LDAP directory. The SAML authz request is just another channel for
    attributes which are made available for the context handler. The context
    handler is already the global state you are looking for.
    
    Best regards,
    Erik
    
    
    


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