Love Others as you love your self!

Learn AzMan in Windows Today!

Authorization Manager:

Simplifies application access control administration in line-of-business applications.

Provides a simplified and natural development model.

Enables flexible and dynamic authorization decisions.

Authorization Policy Storage

When an application that uses Authorization Manager is initialized, it loads the authorization policy information from the store. Authorization Manager provides support for storage of authorization policy in Active Directory or in .xml files.

Important: Because the authorization policy information is stored by Active Directory or in an NTFS file, it is secured with the security capabilities of either Active Directory or NTFS, and the auditing support for changes that are made directly against the storage (without using the Authorization Manager runtime interfaces) is handled by the system on which the store is located. Additionally, administrators on the system that contains the authorization policy store have a high degree of access to the store. For this reason, the authorization policy store must be located on a trusted system.
Active Directory Authorization Manager storage

To use Active Directory to store the Authorization Manager policy, the domain must have a functional level of Windows Server 2003. Active Directory in the Windows Server 2003 family contains schema updates for the Authorization Manager objects. When using the Active Directory store, Authorization Manager creates Active Directory objects for the store itself and child objects for each application group, application, operation, task, role, and scope. The scope object can contain tasks, roles, and groups that were created in that scope.

When using the Active Directory authorization policy store, applications control when application objects are loaded. When an application connects to the policy store, the stores global attributes (including store-level groups) are cached locally, along with header information for each application. When an application initializes its authorization policy using the OpenApplication method, the applications attributes, roles, tasks, operations, application groups, and header information for each scope are loaded into memory. Once an application is loaded, it remains cached in memory until the application object is freed. Scopes are loaded on demand; either the first time the scope is specified in a call to AccessCheck or when the scope is explicitly loaded using the OpenScope method. Once a scope is loaded, it remains cached in memory until the application object is freed.

Deploying an Authorization Manager store in Active Directory

The following gives step-by-step instructions on deploying an Authorization Manager store in Active Directory.

1.

Choose the Authorization Manager Active Directory store location.

To deploy Authorization Manager in an Active Directory store, you must choose a location for the store. It is recommended that the administrator create a new organizational unit (OU) in the domains Program Data container and create a store object in the new OU. This recommendation is not enforced. If the application has data in a container other than Program Data, you can put the Authorization Manager store there.

Authorization Manager cannot be placed in a non-domain naming context, which is also called an application partition.

2.

Create an Authorization Manager store.

Applications can create the Authorization Manager policy store in Active Directory themselves through the Authorization Manager API, or administrators can create a store using the Authorization Manager MMC. In order to do this, the user or application attempting to create a store must have Create Child Object permissions in the container that was chosen in the previous step and they must know the distinguished name of that container.

For more information about creating a store using the Authorization Manager MMC snap-in, see Work with Authorization Stores in Authorization Manager Help.

3.

Roles and authorization store access

If the application administrator creates the store using a program, then they should already have permission to manage the store. If the store is created manually by an Active Directory administrator, permission to manage the store must be given to the application administrator who is using the store. Use the Authorization Manager MMC to grant the application administrator access to manage the authorization policy store. The authorization policy within the store is managed by the application administrator. The Authorization Manager Active Directory store allows the application administrator to delegate management of applications and scopes within the store.

Since application service accounts that use the authorization policy must be able to read the policy store, the application service account must be included in the Readers role in for the appropriate store or application or scope within a store.

4.

Enable the Windows Authorization Access group.

Note: This step is only needed if the application designers use either the InitializeClientContextFromName and InitializeClientContextFromStringSID methods to create client context objects within the application. Applications that use InitializeClientContextFromToken do not require this step. If you are not sure which APIs the application server will use, the application administrator or designer should know.

These methods attempt to read the users token-groups-global-and-universal attribute in Active Directory to get the user’s Active Directory group membership information. To read this information, the application service account must have Read access on this attribute on each user object.

If the domain is configured for Pre-Windows 2000 Compatible Access mode (that is, the Everyone group is in the in the Pre-Windows 2000 Compatible Access group), then the Authenticated Users group will have access to call the InitializeClientContextFromName or InitializeClientContextFromStringSID methods by default. If the domain is set for Windows 2000 and Windows Server 2003 Compatible Access then, by default, only the Authenticated Users group will be in the Pre-Windows 2000 Compatible Access group. In this case, application service accounts will have the required access to call the InitializeClientContextFromName or InitializeClientContextFromStringSID methods. If the domain has been locked down (that is, Active Directory administrators have made the default access permissions more restrictive) it is possible that the Pre-Windows 2000 Compatibility Access group will be empty, in which case application servers may fail when calling the InitializeClientContextFromNameOfSID interfaces.

In this situation, to grant access to the service account, it is recommended that, first, you add the service account to the Windows Authorization Access group, and then grant the Windows Authorization Access group access to each users token-groups-global-and-universal attribute if it does not already have that access. For more information on the Windows Authorization Access group (which is new for the Windows Server 2003 family), search for the term in the Microsoft Knowledge Base at http://support.microsoft.com.
Authorization Manager storage with XML files

Authorization Manager supports storage of the authorization policy in an .xml file that is stored on an NTFS volume. The XML store can be kept on the same computer as the server application using Authorization Manager APIs or it can be stored remotely.

In order to support renaming of objects, the XML format contains globally unique identifiers (GUIDs). Because of this, you should not edit the .xml file directly. Furthermore, the XML schema is not published currently. You can edit the store through the Authorization Manager MMC or through the Authorization Manager interfaces which are available to scripting languages, such as Microsoft Visual Basic Scripting Edition (VBScript) and JScript. The XML store does not support delegation because access to the XML file is controlled by the discretionary access control list (DACL) on the file which grants or restricts access to the entire contents of the file.

It is recommended that application administrators back up their authorization store regularly. The NTFS file system does not support applications issuing a sequence of separate write operations as a single logical write to a file when multiple applications write to the same file. (These operations are sometimes known as transactional operations.) Since an Authorization Manager policy store could be edited simultaneously by two administrative applications, a store could become corrupted.
Top of pageTop of page
Application Administration

After installing an application, the job of the administrator is to add any new roles required, verify the permissions on the initial roles (if present), and assign users to roles. If the application creates a complete set of tasks with meaningful names, the administrators job of setting up initial roles is much easier.

The point of role-based access control is make administration more intuitive and manageable. To do so, administrators must devise a strategy for deploying roles within the application that resembles the user job descriptions. Once the roles are established, the administrative focus is primarily managing memberships within the roles, so it is very important that you verify each roles permissions. Generally, it is safer to grant each role only those permissions that are needed immediately and then add permissions as needed, rather than granting too many permissions and then removing unneeded permissions later.
Managing scopes

Often, the applications manage the creation of scopes and the administrator then creates and manages the roles within a scope. This way, the administrator does not have to know the applications scope syntax and the application logic that is used to associate user access request to a scope.

When applications allow administrators to create scopes, the application must provide documentation so that the administrator understands how to create scopes that are named correctly, since scopes are defined by each application and the application will map each access request to the appropriate scope.

Scopes allow administrators to group application resources into physical or logical collections and specify different authorization policy in each scope. Since tasks and role definitions can be created so that they are global to the application (in other words, visible to all scopes), roles that are created for different scopes can use the same global role definition and have different memberships. This prevents the need to redefine the permissions in each scope. Such a technique is useful when a role or task, such as Administrator or Full Control will have the same permissions in each scope but different people assigned to it.

Important: Authorization Manager applications have a default scope. Permission that is granted to roles in the default scope apply in all scopes in the application. For this reason, the applications default scope should only be used for role assignments that apply to all scopes in the application.
Role inheritance

Since the process of establishing roles involves assigning user permissions, it requires special attention. To minimize the validation and analysis that is required, a hierarchal role model can be designed that leverages the work that was done on establishing existing roles when creating new roles.

Viewer (Permission Required for Viwer Role)
|
Staff (Viewer Role + Permission Required for Staff)
|
Admin (Staff + Permission Required for Admin)

Installation

When an application is installed, it can install authorization policy information into a new or existing authorization store by calling the Authorization Manager API. If the application installs its authorization policy into an existing store, the installation process must give the installing user a way to specify the location of the existing store. After initializing the authorization policy store, the install application uses the CreateApplication method to create an application object in the policy store. Then, for each operation, the installation application calls the CreateOperation method. Initial tasks, scopes and roles are installed using the CreateTask, CreateScope, and CreateRole methods, respectively. The following VBScript creates a store and installs the authorization policy for a simple expense application.

‘— Initialize the admin manager object
Dim pAzManStore
Set pAzManStore = CreateObject(“AzRoles.AzAuthorizationStore”)
‘— Create a new store for expense app
‘ 0 = Open store for Access Checking.
‘ AZ_AZSTORE_FLAG_CREATE = 0x1,
‘ AZ_AZSTORE_FLAG_MANAGE_STORE_ONLY = 0x2, // cannot do access
checking.
‘ AZ_AZSTORE_FLAG_BATCH_UPDATE = 0x4,
pAzManStore.Initialize 1+2+4, “msxml://C:\AzPolicy.xml”
pAzManStore.Submit
Dim App1
Set App1 = pAzManStore.CreateApplication(“Expense”)
App1.Submit
‘— Create operations ———————–
Dim Op1
Set Op1=App1.CreateOperation(“RetrieveForm”)
Op1.OperationID = CLng(61)
Op1.Submit
Set Op1=App1.CreateOperation(“EnqueRequest”)
Op1.OperationID = CLng(62)
Op1.Submit
Set Op1=App1.CreateOperation(“DequeRequest”)
Op1.OperationID = CLng(63)
Op1.Submit
Set Op1=App1.CreateOperation(“UseFormCotnrol”)
Op1.OperationID = CLng(64)
Op1.Submit
Set Op1=App1.CreateOperation(“MarkFormApproved”)
Op1.OperationID = CLng(65)
Op1.Submit
Set Op1=App1.CreateOperation(“SendApprovalNotify”)
Op1.OperationID = CLng(66)
Op1.Submit
‘— Create tasks ——————————
Dim Task1
Set Task1=App1.CreateTask(“Submit Expense”)
Task1.AddOperation CStr(“RetrieveForm”)
Task1.AddOperation CStr(“EnqueRequest”)
Task1.AddOperation CStr(“UseFormCotnrol”)
Task1.Submit
Set Task2 = App1.CreateTask(“Approve Expense”)
Task2.AddOperation CStr(“MarkFormApproved”)
Task2.AddOperation CStr(“SendApprovalNotify”)
Task2.AddOperation CStr(“DequeRequest”)
Task2.BizRuleLanguage = CStr(“VBScript”)
Task2.BizRule = “Dim Amount” & vbnewline & _
“AzBizRuleContext.BusinessRuleResult= FALSE” & vbnewline &_
“Amount = AzBizRuleContext.GetParameter( ” & Chr(34) &_
“Amount” & Chr(34) & “)” & vbNewLine &_
“if Amount Sample Code In VB
~~~~~~~~~~~~~
Step 1) Create and Open Code view of Form1
Step 2) Cut the following code and past it then run
Step 3) You can see the Output in C:\AzPolicys.xml

Private Sub Form_Load()
‘— Initialize the admin manager object
Dim pAzManStore
Set pAzManStore = CreateObject(“AzRoles.AzAuthorizationStore”)
‘— Create a new store for expense app
‘ 0 = Open store for Access Checking.
‘ AZ_AZSTORE_FLAG_CREATE = 0x1,
‘ AZ_AZSTORE_FLAG_MANAGE_STORE_ONLY = 0x2, // cannot do access checking.
‘ AZ_AZSTORE_FLAG_BATCH_UPDATE = 0x4,
pAzManStore.Initialize 1 + 2 + 4, “msxml://C:\AzPolicys.xml”
pAzManStore.Submit
Dim App1
Set App1 = pAzManStore.CreateApplication(“Expense”)
App1.Submit
‘— Create operations ———————–
Dim Op1
Set Op1 = App1.CreateOperation(“RetrieveForm”)
Op1.OperationID = CLng(61)
Op1.Submit
Set Op1 = App1.CreateOperation(“EnqueRequest”)
Op1.OperationID = CLng(62)
Op1.Submit
Set Op1 = App1.CreateOperation(“DequeRequest”)
Op1.OperationID = CLng(63)
Op1.Submit
Set Op1 = App1.CreateOperation(“UseFormCotnrol”)
Op1.OperationID = CLng(64)
Op1.Submit
Set Op1 = App1.CreateOperation(“MarkFormApproved”)
Op1.OperationID = CLng(65)
Op1.Submit
Set Op1 = App1.CreateOperation(“SendApprovalNotify”)
Op1.OperationID = CLng(66)
Op1.Submit
‘— Create tasks ——————————
Dim Task1
Set Task1 = App1.CreateTask(“Submit Expense”)
Task1.AddOperation CStr(“RetrieveForm”)
Task1.AddOperation CStr(“EnqueRequest”)
Task1.AddOperation CStr(“UseFormCotnrol”)
Task1.Submit
Set Task2 = App1.CreateTask(“Approve Expense”)
Task2.AddOperation CStr(“MarkFormApproved”)
Task2.AddOperation CStr(“SendApprovalNotify”)
Task2.AddOperation CStr(“DequeRequest”)
Task2.BizRuleLanguage = CStr(“VBScript”)

‘You can have biz rule also
‘Task2.BizRule = “Dim Amount” & vbnewline & _
‘ “AzBizRuleContext.BusinessRuleResult= FALSE” & vbnewline &_
‘ “Amount = AzBizRuleContext.GetParameter( ” & Chr(34) &_
‘ “Amount” & Chr(34) & “)” & vbNewLine &_
‘ “if Amount

APPROVEDDENIED.

Note: For a sample application using Authorization Manager, see MicrosoftSDKPath\Samples\Security\Authorization\AzMan in the Microsoft Platform SDK. For information on how to install the Microsoft Platform SDK, see http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ on the Microsoft Web site.