  » overview        
|
|
Constable Authorization Engine Overview
The CAZE class library implements a sophisticated authorization engine that
is driven by an application-defined authorization policy. The authorization
policy is represented as a set of authorization rules associated with
an application-defined business object. The authorization policy consists of:
- Roles
- States
- Actions
- Properties
- Authorization rules
Roles are named sets of users sharing the same set of permissions with
respect to the application and / or the business object. For example,
"Document Authors" can create new documents (application-level permission) and
they can edit their own documents (object-level permission).
States represent the different "constitutions" defined for the type of the
business object, for example "waiting for approval". The usage of states in
the CAZE authorization policy is optional, but at least one state has to be defined.
Actions represent the set of operations defined for the business object; typically,
the set of public methods defined for the business object's class.
Properties are attributes of the business object, for example a document's title.
The use of properties in the authorization policy is optional; you'll use them only if you
want to control access to the business object's individual properties.
Authorization rules associate actions and properties with roles, states and a
boolean "enabled" flag. For example, an authorization rule might say:
"Authors can send existing documents to approval." The rule means that users in the "Author" role
are allowed to execute the "Send" action on an "existing" (state) document.
The authorization policy is brought to life by means of an authorization context,
which is represented by an IPrincipal object associated with the policy and
used to resolve role membership and the current state of the policy.
The functionality of the CAZE authorization policy is encapsulated in the core
AuthorizationPolicy
class, which is the primary API you'll use in your application.
The typical usage pattern is as follows:
-
Design the authorization policy by defining roles, states, actions, properties
and authorization rules appropriate for your application and/or business object.
You can create an authorization policy file (a XML file with a
.caze extension) by hand
or you can populate the policy in code using the CAZE API. In most cases you'll
want to use the Policy Designer application, because it's
the most comfortable and efficient way to design,
test and manage authorization policies.
-
Populate an instance of the
AuthorizationPolicy
class by loading the authorization policy from disk, application resource or a database. Alternatively,
you can also populate the authorization policy in code, but this approach is less
flexible than having the policy in a separate XML document.
-
Initialize the authorization context by setting the
CurrentPrincipal
and the
CurrentState
properties.
-
Perform access checks, enumerate available actions and properties and execute actions.
|