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 authorization policy.
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 business logic.

Overview

We'll consider a simple document approval application with the document being the application's sole business object type.

Roles

There are obviously authors that create documents and reviewers that review them, so we'll define the roles Author and Reviewer.

States

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" and "Rejected"¹.

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.

Properties

To keep things simple, we'll define only two document properties - the document's Title and Content.

Actions

The actions represent operations defined for the document. Typically, the actions correspond to public methods exposed by the business object's class, for example CreateDocument or SendDocumentToApproval.

For our document approval application, we've identified the following actions:

Action	Description
Create	Creates a new document.
Update	Updates document's properties.
Send	Sends the document to reviewer for approval.
Review	Starts reviewing the document.
Accept	Approves the document.
Reject	Rejects the document.

Authorization rules

CAZE implements two types of authorization rules: an action authorization rule and a property authorization rule.

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:

Document Approval FSM diagram

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

Next >>

¹Terminology 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..

This site doesn't open new browser windows.