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