Re: [xacml-users] Modelling task partitions in XACML

[Yoichi Takayama <yoichi@melcoe.mq.edu.au>]

Hi Roland,

I am also thinking of applying XACML to workflow, as to how, what and where.

In my opinion, I am inclined to think that using XACML for workflows may not be necessary or useful unless you are dealing with the factors that the workflow programming does not expect to deal with intrinsically with workflow-level execution rules as a part of the workflow capabilities that may be implemented more efficiently.

The transitions from an activity to the next, branching, looping, etc. are all natural part of workflow programming. Although something like AOP or inversion of control may help programming, it may be better to use hard-coded logics than dynamic permission mechanism, like XACML, in most cases.

In your case, however, it may be the case of trying to make flexible rules for workflow to behave quite differently than usual. I can see that it may be hard to express the conditions and the effect of the decisions to workflow execution logic.

I think that you have to think about how you are implementing "he must not execute any task from all the other partitions". I presume, although the user has done one of the tasks, you are expecting the workflow to take the user to the branching point which has all tasks to choose from again. Then,  presumably you want to ask PEP what partitions to show. If no task was done before, it should show all partitions. If any task was done before, it is going to show only the tasks in that partition which was used before. Since PDP can answer only Yes/No questions, this may be asked as, Is Partition 1 used? Is Partition 2 used? and Is Partition 3 used? Then, either PEP gives the answer What Partition(s) to show to the workflow system or it can pass on the 3 answers to the system, and the system can decide what Partition(s) to show. This depends on the programming of PEP to know what questions ask and what it is supposed to do with the workflow. Workflow also must know how to deal with the PEP.

Alternatively, the workflow system shows all tasks but when the user chooses a task, it stops the user going there if that does not belong to the partition that was used before unless the history is NULL. This may be the easiest to do.

So, whatever you are doing, this does not only involve XACML but the capability of the workflow to implement all necessary logics with it. For example, Check what's Next -> Check what XACML question it wants to ask -> Ask the question -> enforce the answer. Unless it is as simple as, If the answer is Yes, proceed to the Next, but if it is No, skip to one after the Next. Or, everything is programmed as Show or Hide, including what's Next, or even elements of GUI can be shown/hidden separately by the XACML PEP.

The advantage of using a workflow is that it provides all logics you want to use with it that other models do not provide easily. In my opinion, that is a navigation of desired flows the end users can program with the system. So, the rule that you want to use probably must be a part of the workflow model or language. I think that using XACML as a built-in rule engine requires that you can express the rule in the workflow model/language and that the workflow engine may internally delegate some difficult to code types of decisions to the XACML engine.

I think Tyson means this by saying that "it would be best if you could generate the policy from the workflow". But in my opinion, it does not do good to have rules for a particular workflow design. If you can pre-define rules which applies to any workflow construct that have this kind of requirement would be good. That is, to use task names or the number of partitions all as variables, not hard-coded.

I think that an exception is that, if the rule is external to the workflow language or dynamic, this may not be the case. External access control rules are not known at the programming time and may not be built into workflow system. Such should be enforced by an add-on access control mechanism. Such mechanism probably just returns OK/Forbidden kind of response and the workflow system must deal with it accordingly.

Any thoughts?

Thanks,
Yoichi

--------------------------------------------------------------------------
Yoichi Takayama, PhD
Senior Research Fellow
RAMP Project
MELCOE (Macquarie E-Learning Centre of Excellence)
MACQUARIE UNIVERSITY

Phone: +61 (0)2 9850 9073
Fax: +61 (0)2 9850 6527
www.mq.edu.au
www.melcoe.mq.edu.au/projects/RAMP/
--------------------------------------------------------------------------
MACQUARIE UNIVERSITY: CRICOS Provider No 00002J

This message is intended for the addressee named and may contain confidential information.  If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of Macquarie E-Learning Centre Of Excellence (MELCOE) or Macquarie University.

On 03/03/2009, at 1:26 AM, Roland Illig wrote:

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

smime.p7s