dynamic tools for .net developers™  LaMarvin Home
home » constable » faq » role resolution

How the CAZE role-resolution process works

The CAZE's role resolution process might seem a bit complex at first, but it offers great flexibility and allows for modeling almost any imaginable authorization scenario.

The process works as follows:
  1. The application calls one of the AuthorizationPolicy's authorizing methods, such as ExecuteAction.
  2. The AuthorizationPolicy retrieves the set of authorization rules applicable to the current state.
  3. For each of the rule retrieved in the previous step, role membership is determined to the rule's associated role by calling the Role.IsMember method passing the current principal as the argument.
  4. The Role.IsMember in turn, calls the passed in IPrincipal.IsInRole method passing it the value of the Role.Id property as the role name, and returning the return value of the IPrincipal.IsInRole call.
  5. If the Role.IsMember call returns false, the current principal is not member of the role and the associated authorization rule is eliminated.
Actually, the implementation described by the fourth step is used only by the base Role class. The derived classes override the method to accomplish their specific role resolution mechanisms:

The WindowsRole maps the WindowsRole.Id property value to a name of a Windows group and uses the WindowsPrincipal.IsInRole method to determine membership in the WindowsRole.WindowsGroupName windows group.

The ComPlusRole maps the ComPlusRole.ComPlusRoleName property value to a name of a role defined in the COM+ catalog. Uses the ContextUtil.IsCallerInRole method to determine role membership (the current principal is not used for the role resolution).

The DynamicRole allows to control membership to the role by setting the DynamicRole.IsMemberResult property independently of the current principal.

The flexibility of the CAZE's role resolution process is apparent if you realize that a single instance of the AuthorizationPolicy class can contain different types of roles, for example:
[Visual Basic]
Dim policy As New Policy()

policy.Roles.Add(New Role("User"))
policy.Roles.Add(New WindowsRole("Admin", "BUILTIN\Administrators"))
policy.Roles.Add(New ComPlusRole("Superuser", "COM+ Superuser"))



policy.ActionRules.AddNew("Logoff", "User")
policy.ActionRules.AddNew("Shutdown", "Admin")
policy.ActionRules.AddNew("Shutdown", "Superuser")
policy.ActionRules.AddNew("FormatDrive", "Superuser")

policy.CurrentPrincipal = _
  New WindowsPrincipal(WindowsIdentity.GetCurrent())


AuthorizationPolicy policy = new AuthorizationPolicy();

policy.Roles.Add(new Role("User"));
policy.Roles.Add(new WindowsRole("Admin", @"BUILTIN\Administrators"));
policy.Roles.Add(new ComPlusRole("Superuser", "COM+ Superuser"));



policy.ActionRules.AddNew("Logoff", "User");
policy.ActionRules.AddNew("Shutdown", "Admin");
policy.ActionRules.AddNew("Shutdown", "Superuser");
policy.ActionRules.AddNew("FormatDrive", "Superuser");

policy.CurrentPrincipal = 
  new WindowsPrincipal(WindowsIdentity.GetCurrent());

The "User" role is the default CAZE Role type. The Role.Id property is used for membership checking; the Role.Id is passed to the IPrincipal.IsInRole method so the role membership is determined by the IPrincipal implementation performing the role check.

The "Admin" role is a WindowsRole instance. Only WindowsPrincipals in the group specified by the WindowsRole.WindowsGroupName are resolved as members of the role.

The "Superuser" role is a ComPlusRole instance. The .NET's IPrincipal is not used for role membership chesk. Instead, the COM+ call context is used to determine if the current COM+ identity is member of the role defined by the ComPlusRole.ComPlusRoleName.

© 2002-2007 LaMarvin. All Rights Reserved.     [Terms of use]     [Privacy] This site doesn't open new browser windows.