Hi Roland,
My suggestion would be to try the hierarchical profile w URIs.
In particular, you could define your workflow (w optional //authority)
as:
Then have an environment variable var, also a URI, which would be "*"
if no task has yet been executed, and if a task has been executed would
be filled with URI of partition from which task was executed. For
example if user had executed t3, then the variable would be:
Then you would have a policy test for env-var and requested task and
only allow access if the URI in the env-var is in the requested task
URI. Presumably initial env-var "*", would always succeed, and any
partition URI in env-var would only allow access if partition matched
requested partition, so users who executed t3, could execute any other
t*, but not the sign*.
You will have to test the specific syntax of the rules, but something
along the lines of:
<Apply FuncionId="∧">
� <Apply FunctionId="&anyURI-regexp-match;">
��� <AttributeValue
DataType="&string;">file://authority/workflow/*</AttributeValue>
��� <Apply FunctionId="&string-one-and-only;">
����� <ResourceAttributeDesignator AttributeId="&resource-id;"
DataType="&string;"/>
��� </Apply>
� </Apply>
� <Apply FunctionId="&anyURI-regexp-match;">
��� <Apply FunctionId="&string-one-and-only;">
����� <ResourceAttributeDesignator AttributeId="&env-var;"
DataType="&string;"/>
��� </Apply>
��� <Apply FunctionId="&string-one-and-only;">
����� <ResourceAttributeDesignator AttributeId="&resource-id;"
DataType="&string;"/>
��� </Apply>
� </Apply>
</Apply>
Possibly, if one were clever, one could do it with one expression since
the first expression just tests for the workflow itself, which would be
contained in env-var, so 2nd expression, in theory could be sufficient.
btw, the form of these expressions is derived from section 4.3 of the
long lost and slightly obsolete:
http://www.oasis-open.org/committees/document.php?document_id=7315&wg_abbrev=xacml
Note: this document and related issues are currently under discussion
in XACML TC. However, I believe based on existing hierarchical 2.0
profile, this scenario should exactly be supported. In fact, with this,
I don't believe you even need to declare hierarchical profile since out
of box URI capabilities should solve problem as above.
��� Thanks,
��� Rich
��� Thanks,
��� Rich
�
Roland Illig wrote:
49ABEC8A.4020507@gmx.de" type="cite">
Hi,
I want to use XACML to implement access control in a workflow system. A
workflow is separated into several tasks. Some of these tasks will be
split into partitions, and now the fun begins: If a user has executed a
task from one of the partitions, he must not execute any task from all
the other partitions. For example:
workflow = (t1, t2, t3, t4, t5, sign1, sign2)
partitioning = {{t1, t2, t3, t4, t5}, {sign1}, {sign2}}
Assuming that there is an environment attribute called "history" that
returns all the tasks that the user has already executed, can I
implement this restriction using only plain XACML 1.0 or 2.0?
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-users-help@lists.oasis-open.org
|