Constable Authorization Engine Tutorial
This tutorial will show you how to define a CAZE authorization policy and
how to call the CAZE API to perform authorization queries and access checks.
The tutorial consists of these sections:
The overview introduces a simple document approval
application and defines the document approval
The authorization policy section
shows how to use the Policy Designer to visually design the policy,
and how to use the CAZE API to load the policy in code.
The final usage section shows code that queries and
manipulates the authorization policy to help the application implement its
We'll consider a simple document approval application with the document
being the application's sole business object type.
There are obviously authors that create documents and reviewers that review them,
so we'll define the roles Author and Reviewer.
The approval process implies that the document has to be first authored, then reviewed
and, based on the result of the review, it is either accepted or rejected. We can
therefore derive the states "Authoring", "Sent", "Reviewing", "Accepted"
Experience has shown that in order to maintain simplicity and clarity of the
authorization policy (and the application code using it), it is useful to extend
the policy with additional (virtual) "New" state. The "New" state represents an
object that has already been created but that hasn't been stored in a database yet.
More often than not, a business object has different
set of permissions associated with new and persisted objects. For example a document
cannot be sent to approval if it is not persisted in a database.
To keep things simple, we'll define only two document properties - the
document's Title and Content.
The actions represent operations defined for the document. Typically,
the actions correspond to public methods exposed by the business object's
class, for example
For our document approval application, we've identified
the following actions:
CAZE implements two types of authorization rules: an action authorization rule and
a property authorization rule.
Creates a new document.
Updates document's properties.
Sends the document to reviewer for approval.
Starts reviewing the document.
Approves the document.
Rejects the document.
An action authorization rule represents an action that can be executed by an user
in the given role on an object in the given state.
The target state of the action represents the
state of the business object after the action is executed.
The following image contains a FSM diagram depicting action authorization rules for our
document approval application:
The horizontal black lines represent the states, the vertical brown lines with
arrows represent the action authorization rules. The action is shown in the label;
the associated role is in parentheses. The line starts in the
associated (originating) state. The arrow points to the action's target state.
A property authorization rule represents a property that is accessible by an user
in the given role on an object in the given state. Accessible in this context means
that the property is visible and / or modifiable.
Concerning the property authorization rules for the document approval sample, let's assume
that only the author can modify
the properties while in the "New" and "Authoring" states.
Let's have a look at how this simple policy
can be translated to actual code...
1Terminology note: The employed convention for naming states is that a typical wait
state is named with a verb in past tense, i.e. accepted, solved, killed. States that
represent an action that is being carried out are named using past continuous tense,
i.e. reviewing, preparing, solving, etc..