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

[Frank Siebenlist <franks@mcs.anl.gov>]

Hi Erik,

The method that you are describing where the attributes are maintained 
by the context handler is the same as keeping them in some global context.

It does not allow you to model the request context as a functional 
interface, which is not very elegant... and diverts from previously 
stated goals (at least I believe it was a noble goal to be able to model 
the xacml evaluation through a functional paradigm (?))

I still haven't heart about any reason not to add the attribute sets to 
the request context.
Is there any practical reason not to do this?

Thanks, Frank.


Erik Rissanen wrote:
> 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
>
>
>
> ---------------------------------------------------------------------
> 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