[UseCase:] Workflow

[Carlisle Adams <carlisle.adams@entrust.com>]

Title: [UseCase:] Workflow

Hi,

I suppose this is the electronic equivalent of "the dog ate my homework", but just as I was about to send this use case write-up late yesterday, our Exchange server stopped responding (i.e., crashed).  Not only was I unable to send the message to the list, but I lost the message altogether (due to killing the process in order to un-freeze my screen) and had to reconstruct it from (vague) memory this morning.

Anyway, apologies for the lateness of this submission.  It's not quite complete (some of the template fields are not yet filled in), but there's enough there to kick-start some discussion.

Carlisle.

8<----------------------------------------------------

XACML v1.0 Use Case

Title:  [useCaseTitle]

Security Policies for Workflow

Terse Description:  [One line description of Use Case]

Workflow is a multi-step electronic transaction in which several security policies may participate at each stage.

Version: [v#.#]

1.0

Submitted By:  [orignalSubmitter]

Carlisle Adams

Date:  [lastModifiedDate]

September 5, 2001

Summary [Simple description of the Use Case]

In an e-business environment, some transactions may take place over multiple steps, involving several processes, several platforms, and one or more interactions with human entities (although typically the goal is to automate as much of the transaction as possible).  Each step in the transaction may be envisioned as one or more input values (data, request, etc.), a data processing or data transformation stage, and an output result sent to one or more next steps.  Each of these three sub-steps may be governed by an appropriate security policy.  XACML may encompass all such relevant security policies in its language, but at the very least needs to acknowledge their potential existence in its model.

Scope:  [The boundaries for which the Use Case represents a Process]
Actors:  [For lack of a better term, the NOUNs by which the verbs act
upon]
Assumptions:  [What preconditions and/or in-process assumptions were
made in developing the Use Case?]
Non-technical Factors: [List any non-technical issues that may have an
effect on the process: legal, regulatory, industry standards, etc.]

Process Sequence
----------------
Primary Process Flow:  [Detailed description of the entities and actions
comprising the Process Flow]

1) Input data at a step in the transaction needs to be of the "proper" form, with respect to security operations.  [Has it been signed by the appropriate entities or roles?  Has it been encrypted for the appropriate entities or roles?  Has it been time-stamped?  Is it accompanied by a receipt from an archive service?  Is the sender authenticated and authorized to have sent this data?  Are the required SAML assertions or other relevant data available?]  This is analogous to checking an input XML document against a schema for that document type, but the focus is on the security properties of the document, rather than merely its syntax.

2) The data needs to be processed or transformed in some way.  [Does it (all of it, or selected elements) need to be signed or encrypted?  By whom or for whom?  Does it need to be time-stamped or archived?  Do SAML assertions or artifacts need to be generated and sent with the output data?  How does the data need to be transformed (e.g., is any filtering of the elements necessary)?  Are there conditions or conditional actions that need to be checked or performed?]  This is similar to some of the access control rules already under consideration in other use cases, but is somewhat richer and more general because it needs to embrace a greater set of security operations and needs to account for the fact that the "requester" and the "recipient" are different entities (with their own policies).

3) The resulting data needs to be sent to the next step(s) in the transaction.  [Does the potential receiver need to be authenticated?  Does the receiver's authorization to receive the data need to be checked?  Has the requester stipulated any constraints on the audience or use of this data, and does this match the potential receiver and the uses to which it claims received data will be put?  If any of the conditions or conditional actions fail, does this process need to be "rolled back" to some previous step in the transaction (how far, and how is this done)?]  Again, this is similar to some of the relevant considerations in other use cases, but is richer and more general.

Flow Diagram: (optional?)
Key Points:  [Issues that the Author wishes to explicitly identify as
goals to be met, issues to be resolved or other information that
warrants particular attention]

The main point is that several security policies may participate at each step in the workflow transaction:
 - requester policy describing who can receive the data and what they can do with it;
 - receiver policy describing what data sent to them should look like and what they intend to do with it;
 - policy describing "proper" input data (with respect to security properties);
 - policy describing the required security processing or transformations of data at that step; and
 - policy describing what checks need to be made prior to sending data out (including conditional actions and roll-back procedures).

XACML may consider developing a language rich enough to support all these types of policies, or may decide that some of this work is being done elsewhere (e.g., W3C P3P).  In any case, however, XACML needs to be aware of these concepts and acknowledge them in its overall policy model.

Alpha Process Variant:  [Detailed description of the entities and
actions comprising a Process Flow variant that introduces a new or
different interpretation of Primary Process Flow]
Flow Diagram: (optional?)
Key Points:  [Issues that the Author wishes to explicitly identify as
goals to be met, issues to be resolved or other information that
warrants particular attention]

Beta Process Variant:  [Detailed description of the entities and actions
comprising a Process Flow variant that introduces a new or different
interpretation of  the Process Flow]
Flow Diagram: (optional?)
Key Points:  [Issues that the Author wishes to explicitly identify as
goals to be met, issues to be resolved or other information that
warrants particular attention]

[...]

Glossary: [Definition of terms used]

References: [List of references used - URLs are a good way to make
friends!]