CAZE and different types of roles
One common way we can categorize roles is according to the mechanism role
membership is determined:
Windows roles, for example, represent Windows
user groups and the group membership is managed by the built-in
Windows' APIs and administrative tools.
COM+ roles are stored in the COM+ catalog and the membership is managed by
means of the COM+ APIs or the Component Services MMC snap-in.
Roles that use other mechanisms to determine membership are commonly called
custom, or application-specific roles. Obviously, custom roles use custom mechanisms
to determine role membership. These custom mechanisms commonly involve
organizational hierarchies and other organization-specific or application-specific data.
As an example, suppose that the Reviewer role of the Document Approval
application discussed in the tutorial
should be defined in such a way that the Reviewer is member of a specific
department within the company using the application. The organizational
hierarchy must be used to determine the Reviewer role membership, perhaps
by using ADSI, LDAP or a custom API. You can implement such scenario
by defining a custom role class derived from the CAZE
class and overriding the
method, for example:
Public Class ReviewerRole
Public Overrides Function IsMember(principal As IPrincipal) As Boolean
If principal Is Nothing Then
' Consult the custom directory service to determine if the
' principal.Identity.Name is member of the required
' organizational unit.
public class ReviewerRole : Role
public override bool IsMember(IPrincipal principal)
if (principal == null)
// Consult the custom directory service to determine if the
// principal.Identity.Name is member of the required
// organizational unit.
IsMember implementation calls a custom directory service API and passes it the
current principal's identity name. The directory service determines if the
passed-in identity is member of the required organizational unit and the result
is returned as the
IsMember's return value.
If a custom role resolution mechanism depends on the state of a business object, it is
often simpler to use the provided
class and implement the custom role resolution logic in such a way that it dynamically adds
or removes roles from the
collection. In order to illustrate this technique, let's redefine the Reviewer role
of the Document Approval application once again: Reviewer is either a member
of the "Administrators" local Windows group or, it can be any user as long as the
document's title contains the word "public":
documentRow As DataRow = <load the document row from database>
Dim docPolicy As AuthorizationPolicy = LoadDocPolicy()
docPolicy.CurrentState = _
Dim principal As New ExtendedPrincipal()
If documentRow("title").ToString().IndexOf("public") >= 0 Then
docPolicy.CurrentPrincipal = principal
DataRow documentRow = <load the document row from database>;
AuthorizationPolicy docPolicy = LoadDocPolicy();
ExtendedPrincipal principal = new ExtendedPrincipal();
if (documentRow["title"].ToString().IndexOf("public") >= 0)
docPolicy.CurrentPrincipal = principal;
We've loaded a document from database and loaded and initialized the associated
After that, we've created an instance of the
class and, based on the value of the document's title property, we've added the "Reviewer"
role to the
collection. By associating the
ExtendedPrincipal with the policy, we've ensured that
the policy gives the principal all permissions associated with the "Reviewer" role.