OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: RE: [xacml] Passing parameters to the attribute designator

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

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 ?

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