Contact
Contact
Timothyasir@yahoo.com
My E-mail
AzMan - Windows
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.
Typically, you define access control models with the terms Subject, Resources, and Permissions. A subject is often a user operating upon resources. Access is controlled by a set of permissions that allow the subject to perform specific operations on the resource. Administration of access control rarely deals directly with these constructs but more often involves management of collections of subjects, resources, and permissions. You usually manage subjects or users in groups, but you manage resources in application-specific collections, such as directories or organizational units. Permissions may be granted directly, but are often grouped into higher level permissions such as Full Control. These collections make authorization management possible in environments where there are many subjects, resources, or permissions. Application administrators must use these collections to make an authorization policy for the application so that each subject has the appropriate permissions to use the application resources.
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 < 500 then AzBizRuleContext.BusinessRuleResult=
TRUE"
Task2.Submit
'--- Create role definitions ------------------------------
Set Task3 = App1.CreateTask("Expense Admin")
Task3.AddTask CStr("Approve Expense")
Task3.AddTask CStr("Submit Expense")
Task3.IsRoleDefinition = TRUE
Task3.Submit
Set Task4 = App1.CreateTask("Expense User")
Task4.AddTask CStr("Submit Expense")
Task4.IsRoleDefinition = TRUE
Task4.Submit
'--- Create initial scopes and roles ------------------------------
'--- only one scope in this app (we may instead choose to use no scope)
Dim Scope1
Set Scope1 = App1.CreateScope("AllRoutines")
Scope1.Submit
Set RoleA=Scope1.CreateRole("Expense Administrator")
RoleA.AddTask("Expense Admin")
RoleA.Submit
Set RoleB=Scope1.CreateRole("Expense User")
RoleB.AddTask("Expense User")
RoleB.Submit
'--- Demo - add everyone to ExpenseUser Role --------------------------
RoleB.AddMemberName("Everyone")
RoleB.Submit
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 < 500 then AzBizRuleContext.BusinessRuleResult=
'TRUE"
Task2.Submit
'--- Create role definitions ------------------------------
Set Task3 = App1.CreateTask("Expense Admin")
Task3.AddTask CStr("Approve Expense")
Task3.AddTask CStr("Submit Expense")
Task3.IsRoleDefinition = True
Task3.Submit
Set Task4 = App1.CreateTask("Expense User")
Task4.AddTask CStr("Submit Expense")
Task4.IsRoleDefinition = True
Task4.Submit
'--- Create initial scopes and roles ------------------------------
'--- only one scope in this app (we may instead choose to use no scope)
Dim Scope1
Set Scope1 = App1.CreateScope("AllRoutines")
Scope1.Submit
Set RoleA = Scope1.CreateRole("Expense Administrator")
RoleA.AddTask ("Expense Admin")
RoleA.Submit
Set RoleB = Scope1.CreateRole("Expense User")
RoleB.AddTask ("Expense User")
RoleB.Submit
'--- Demo - add everyone to ExpenseUser Role --------------------------
RoleB.AddMemberName ("Everyone")
RoleB.Submit
End Sub
Accessing Using Asp.NET
~~~~~~~~~~~~~~~~~~~~~~~
ASP.NET
Application servers written in ASP.NET can use the Authorization Manager API through the .NET Interop assembly that ships in the \AuthMan directory in the .NET Framework. To create a trusted subsystem model in ASP.NET, you need to run the application server in a service account. To configure your ASP.NET application server to run in a service account, you create a separate IIS 6.0 worker process which runs in the security context of the service account created for the application server. You can then configure your ASP.NET application to use this dedicated IIS worker process. For more information on IIS 6.0 worker processes, see the Microsoft Internet Information Services page on the Microsoft Web site at http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/default.mspx. Alternatively, you can use ASP.NET to configure the context in which an application runs using the Web.config file for your ASP.NET application. In that case, you should configure the ASP.NET application to run as the dedicated service account.
When your ASP.NET application is initialized, it can call AzAuthorizationStore.Initialize to connect to the Authorization Manager store. It then calls AzApplication.Initialize to load an initial percentage of the applications authorization policy.
At run time, when a client connects, you have the option of initializing a user context from the clients account name or from a token representing the client. The token can be retrieved in ASP.NET by way of the ASP.NET HttpWorkerRequest object. Authorization Manager can also initialize a context from a clients SID, though that is not usually available in ASP or ASP.NET. It is recommended that you initialize the Authorization Manager context from a token when possible because, when initializing from a token, you do not have to potentially query the users account object. That may require network-bound queries to Active Directory.
The following code calls the Authorization Manager API through ASP.NET, using a .NET Interop assembly to approve an expense approval. This code is a simple Web expense application that runs in a dedicated service account. The Authorization Manager policy store for this application can be created from the VBScript install script that appeared earlier in this paper.
<%@ Page Language="C#" Debug="True"%>
<%@ Assembly Name ="Microsoft.Interop.Security.AzRoles"%>
<%@ Import Namespace="Microsoft.Interop.Security.AzRoles"%>
<%@ Import Namespace="System.Runtime.InteropServices" %>
<%
Microsoft.Interop.Security.AzRoles.AzAuthorizationStoreClass
AzManStore =
new
Microsoft.Interop.Security.AzRoles.AzAuthorizationStoreClass();
// Keep the authorization store in a safe place out of the Web
space.
AzManStore.Initialize(0,
@"msxml://D:\SecureDir\MyWebAppsAzStore.xml",
null);
IAzApplication azApp =
AzManStore.OpenApplication("expense",null);
HandleRef token = new HandleRef(this, ((HttpWorkerRequest)
((IServiceProvider)Context).GetService(typeof(HttpWorkerRequest))).GetU
serToken());
//-------------- Create Client Context --------------
IAzClientContext context =
azApp.InitializeClientContextFromToken(
(UInt64)token.Handle,
0);
object[] scope = new Object[1];
scope[0] = "";
object[] operations = new Object[1];
operations[0] = 55;
//--------------- Do access check --------------------
//Set up BizRule params. To optimize performance, name/value pairs must
//be placed in array alphabetically
Object[] BRNames = new Object[1];
BRNames[0] = "ExpAmount";
Object[] BRValues = new Object[1];
BRValues[0] = Convert.ToInt32(Request.QueryString["Amount"]);
object[] results = (object[]) context.AccessCheck("Approve",
scope,
operations,
BRNames,
BRValues,
.null,null,null);
bool bAuthorized = true;
foreach (int iResCode in results)
{
if ( iResCode != 0 ) // zero = no error
{
bAuthorized = false;
break;
}
}
Response.Write((string)context.UserSamCompat + "
");
Response.Write(
"Approval of " + Convert.ToString(BRValues[0]) + " was");
if (bAuthorized) {
%>APPROVED<%
} else {
%>DENIED.<%
}
%>
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.
•
Simplifies application access control administration in line-of-business applications.
•
Provides a simplified and natural development model.
•
Enables flexible and dynamic authorization decisions.
Typically, you define access control models with the terms Subject, Resources, and Permissions. A subject is often a user operating upon resources. Access is controlled by a set of permissions that allow the subject to perform specific operations on the resource. Administration of access control rarely deals directly with these constructs but more often involves management of collections of subjects, resources, and permissions. You usually manage subjects or users in groups, but you manage resources in application-specific collections, such as directories or organizational units. Permissions may be granted directly, but are often grouped into higher level permissions such as Full Control. These collections make authorization management possible in environments where there are many subjects, resources, or permissions. Application administrators must use these collections to make an authorization policy for the application so that each subject has the appropriate permissions to use the application resources.
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 < 500 then AzBizRuleContext.BusinessRuleResult=
TRUE"
Task2.Submit
'--- Create role definitions ------------------------------
Set Task3 = App1.CreateTask("Expense Admin")
Task3.AddTask CStr("Approve Expense")
Task3.AddTask CStr("Submit Expense")
Task3.IsRoleDefinition = TRUE
Task3.Submit
Set Task4 = App1.CreateTask("Expense User")
Task4.AddTask CStr("Submit Expense")
Task4.IsRoleDefinition = TRUE
Task4.Submit
'--- Create initial scopes and roles ------------------------------
'--- only one scope in this app (we may instead choose to use no scope)
Dim Scope1
Set Scope1 = App1.CreateScope("AllRoutines")
Scope1.Submit
Set RoleA=Scope1.CreateRole("Expense Administrator")
RoleA.AddTask("Expense Admin")
RoleA.Submit
Set RoleB=Scope1.CreateRole("Expense User")
RoleB.AddTask("Expense User")
RoleB.Submit
'--- Demo - add everyone to ExpenseUser Role --------------------------
RoleB.AddMemberName("Everyone")
RoleB.Submit
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 < 500 then AzBizRuleContext.BusinessRuleResult=
'TRUE"
Task2.Submit
'--- Create role definitions ------------------------------
Set Task3 = App1.CreateTask("Expense Admin")
Task3.AddTask CStr("Approve Expense")
Task3.AddTask CStr("Submit Expense")
Task3.IsRoleDefinition = True
Task3.Submit
Set Task4 = App1.CreateTask("Expense User")
Task4.AddTask CStr("Submit Expense")
Task4.IsRoleDefinition = True
Task4.Submit
'--- Create initial scopes and roles ------------------------------
'--- only one scope in this app (we may instead choose to use no scope)
Dim Scope1
Set Scope1 = App1.CreateScope("AllRoutines")
Scope1.Submit
Set RoleA = Scope1.CreateRole("Expense Administrator")
RoleA.AddTask ("Expense Admin")
RoleA.Submit
Set RoleB = Scope1.CreateRole("Expense User")
RoleB.AddTask ("Expense User")
RoleB.Submit
'--- Demo - add everyone to ExpenseUser Role --------------------------
RoleB.AddMemberName ("Everyone")
RoleB.Submit
End Sub
Accessing Using Asp.NET
~~~~~~~~~~~~~~~~~~~~~~~
ASP.NET
Application servers written in ASP.NET can use the Authorization Manager API through the .NET Interop assembly that ships in the \AuthMan directory in the .NET Framework. To create a trusted subsystem model in ASP.NET, you need to run the application server in a service account. To configure your ASP.NET application server to run in a service account, you create a separate IIS 6.0 worker process which runs in the security context of the service account created for the application server. You can then configure your ASP.NET application to use this dedicated IIS worker process. For more information on IIS 6.0 worker processes, see the Microsoft Internet Information Services page on the Microsoft Web site at http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/default.mspx. Alternatively, you can use ASP.NET to configure the context in which an application runs using the Web.config file for your ASP.NET application. In that case, you should configure the ASP.NET application to run as the dedicated service account.
When your ASP.NET application is initialized, it can call AzAuthorizationStore.Initialize to connect to the Authorization Manager store. It then calls AzApplication.Initialize to load an initial percentage of the applications authorization policy.
At run time, when a client connects, you have the option of initializing a user context from the clients account name or from a token representing the client. The token can be retrieved in ASP.NET by way of the ASP.NET HttpWorkerRequest object. Authorization Manager can also initialize a context from a clients SID, though that is not usually available in ASP or ASP.NET. It is recommended that you initialize the Authorization Manager context from a token when possible because, when initializing from a token, you do not have to potentially query the users account object. That may require network-bound queries to Active Directory.
The following code calls the Authorization Manager API through ASP.NET, using a .NET Interop assembly to approve an expense approval. This code is a simple Web expense application that runs in a dedicated service account. The Authorization Manager policy store for this application can be created from the VBScript install script that appeared earlier in this paper.
<%@ Page Language="C#" Debug="True"%>
<%@ Assembly Name ="Microsoft.Interop.Security.AzRoles"%>
<%@ Import Namespace="Microsoft.Interop.Security.AzRoles"%>
<%@ Import Namespace="System.Runtime.InteropServices" %>
<%
Microsoft.Interop.Security.AzRoles.AzAuthorizationStoreClass
AzManStore =
new
Microsoft.Interop.Security.AzRoles.AzAuthorizationStoreClass();
// Keep the authorization store in a safe place out of the Web
space.
AzManStore.Initialize(0,
@"msxml://D:\SecureDir\MyWebAppsAzStore.xml",
null);
IAzApplication azApp =
AzManStore.OpenApplication("expense",null);
HandleRef token = new HandleRef(this, ((HttpWorkerRequest)
((IServiceProvider)Context).GetService(typeof(HttpWorkerRequest))).GetU
serToken());
//-------------- Create Client Context --------------
IAzClientContext context =
azApp.InitializeClientContextFromToken(
(UInt64)token.Handle,
0);
object[] scope = new Object[1];
scope[0] = "";
object[] operations = new Object[1];
operations[0] = 55;
//--------------- Do access check --------------------
//Set up BizRule params. To optimize performance, name/value pairs must
//be placed in array alphabetically
Object[] BRNames = new Object[1];
BRNames[0] = "ExpAmount";
Object[] BRValues = new Object[1];
BRValues[0] = Convert.ToInt32(Request.QueryString["Amount"]);
object[] results = (object[]) context.AccessCheck("Approve",
scope,
operations,
BRNames,
BRValues,
.null,null,null);
bool bAuthorized = true;
foreach (int iResCode in results)
{
if ( iResCode != 0 ) // zero = no error
{
bAuthorized = false;
break;
}
}
Response.Write((string)context.UserSamCompat + "
");
Response.Write(
"Approval of " + Convert.ToString(BRValues[0]) + " was");
if (bAuthorized) {
%>APPROVED<%
} else {
%>DENIED.<%
}
%>
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.
