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

[Erik Rissanen <mirty@sics.se>]

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