Re: [xacml] Passing parameters to the attribute designator

[Erik Rissanen <erik@axiomatics.com>]

Anil and all,

This issue falls under the broader issue of attribute provisioning, 
which I think is very important and currently somewhat underspecified in 
the XACML world. But this is much because by design XACML chose to 
abstract away this kind of details. This kind of abstraction makes XACML 
more generally applicable and adaptable to different environments and 
growth over time.

I think that the XACML context handler abstraction is a Good Thing and 
that parameters such as keys for SQL queries or parameters of database 
connections in a particular implementation do not belong in XACML 
policies. Putting such parameters in the policy would break 
interoperability between implementations.

I think that the particular use case you propose is better handled as 
part of the configuration of a particular context handler 
implementation. The attribute id should be all that is in the policy. 
How to look up the attribute is part of the configuration of the 
implementation.

If a more general solution is desired, I think it would be more 
appropriate to do work on standardization on context handlers and their 
configuration for widely used environments. Rich has raised these issues 
in the TC and I am looking forward to pursue them once the XACML 3.0 
core schema is "done". (Though I am not sure if this TC is always the 
best place for such work.)

So I am opposed to the proposed change in the XACML schema.

Best regards,
Erik

Anil Tappetla (atappetl) wrote:
> More thoughts on this issue -
>  
> If say, one had a user based policy, i.e., a policy set with the 
> subject-id in the request matching so and so, stating that -
>  
>                            if 'user-location equals NY' then allow
>  
> where 'user-location' is an attribute external to the request context 
> and can be queried from the database as -
>  
>                            SELECT USER_LOCATION FROM LOCATION_MASTER 
> WHERE USER_TYPE=?
>  
> A context handler, in this case capable of executing DB queries, must 
> be passed the USER_TYPE parameter that may not exist in the request 
> context.
>  
> This parameter may be kept with the policy or it is left to the 
> context handler to figure how to obtain the user-location attribute 
> given the information in the request context. In EPM (Cisco Enterprise 
> Policy Manager), the former is possible, and ofcourse is part of the 
> holistic solution to managing user/group/role(s) and policies. The 
> notion of a context handler per se does not exist in EPM.
>  
> Essentially, the point boils down to how one may view the SQL query, 
> if it should be treated as part of the policy definition or otherwise. 
> If it should be, then in my view, it begs for extensibility of the 
> AttributeDesignator type in XACML by large. If it should not be, even 
> then I believe there may still be a case to pass higher level metadata 
> to the context handler, like the JDBC connection information.
>  
> Regards,
> Anil
>
> ------------------------------------------------------------------------
> *From:* Anil Tappetla (atappetl)
> *Sent:* Friday, June 20, 2008 12:46 PM
> *To:* xacml@lists.oasis-open.org
> *Subject:* [xacml] Passing parameters to the attribute designator
>
> I believe there must be a case when the context handler must be given 
> additional information to retrieve an attribute when using attribute 
> designators. This additional information may be kept within the 
> policies that reference the designator and will serve as parameters to 
> the evaluation procedure of the designator. Naturally, this applies to 
> only those cases when the attribute referenced is not actually present 
> in the request context as XACMLv2.0 specification mentions how 
> the referenced attributes must be matched when present in the request 
> context.
>  
> This additional context passed to the handler can be a property 
> list/name-value pairs as the combiner parameters.
>  
> Thoughts ?
>  
> Regards,
> Anil