Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Customizing Authentication and Authorization in WSE Using AzMan : Page 2

Web Services Enhancements (WSE) supports message-based security, policy-based administration, and has the flexibility to move message-exchange out of the HTTP-only world. But despite the combination of support for authentication and authorization for cross-platform principals there's still the question of how to deal with custom principals. AzMan can help.


advertisement
WSE Authorization
Before digging into Web service Authorization part of Web services, I must tell you about an incredible and simplified Application Authorization Model called AzMan (Authorization Manager) available on the Windows platform. AzMan ships with the Windows Server 2003 family but you can use it even if you're running Windows XP or Windows Server 2000 by downloading it from this URL.

 
Figure 3. The AzMan Administration GUI: The administration application provides a hierarchical view of Groups, Roles, and other AzMan entities, is an MMC snap-in that you can try out by running AZMAN.MSC or by adding the Authorization Manager snap-in to your MMC console of choice.
AzMan goes far beyond the Private Object Security API of the ACL (Access Control List) model in Windows NT Server 4.0., but AzMan is a set of COM-based interfaces for managing and verifying client requests to perform application operations. AzMan provides a Microsoft Management Console (MMC) snap-in to simplify managing user roles and permissions. I've found AzMan to be the solution for managing role-based security in Windows applications.

AzMan has two parts: a runtime and an administrative UI. The runtime, provided by AZROLES.DLL, exposes a set of COM interfaces used by applications that employ role-based security. The administration UI is an MMC snap-in that you can try out by running AZMAN.MSC or by adding the Authorization Manager snap-in to your MMC console of choice.

AzMan Administration
The first thing you'll notice when you run the AzMan admin tool shown in Figure 3 is that it's much more complex than that offered by COM+. You no longer have only roles and role assignments; you can also assign low-level operations to tasks, which you can then assign to roles. A task is a collection of operations; you might need series of operations to complete one concrete task. Tasks can include other tasks, and roles can include other roles. This hierarchical approach helps you manage the seemingly unrestrained set of roles needed in today's multifaceted applications.

For the example code, you'll first setup an AzMan store (file) as a part of Active Directory or in a simple XML file. Create an XML file called Agent.xml, and then create a new application in that file called DealerManagementApplication.

Here's an example of an AzMan XML store—built as described in the remainder of this article.

<?xml version="1.0" encoding="utf-8"?> <AzAdminManager MajorVersion="1" MinorVersion="0" Description="Authorization store for Agents"> <AzApplication Guid="087cb402-469a-43ab-ac40-e5808a846640" Name="DealerManagementApplication" Description="Dealer and their Agents Management Application" ApplicationVersion="0.1"> <AzTask Guid="27d4a28b-6e19-4bb4-87f9-7c2a3e67f76f" Name="PremimiumDealer" Description="Premimium Dealers" BizRuleImportedPath="" RoleDefinition="True"> <TaskLink> d1445203-a9ae-4270-a48d-1ff486f51d4e</TaskLink> <TaskLink> e80e81cd-558d-4367-b7d6-2d460b4bab70</TaskLink> </AzTask> <AzTask Guid="d1445203-a9ae-4270-a48d-1ff486f51d4e" Name="tsk_PostpaidActivation" Description="Can activate postpaid customers" BizRuleImportedPath=""> <OperationLink> 3bf97741-cb1f-4f8b-a894-b2cb3f4f16c4 </OperationLink> </AzTask> <AzOperation Guid="3bf97741-cb1f-4f8b-a894-b2cb3f4f16c4" Name="op_ActivatePostpaidCustomer" Description="Activate Postpaid Customer"> <OperationID>1</OperationID> </AzOperation> <AzRole Guid="6802a6dc-6679-407b-b81a-a5f7e6f68eaa" Name="PremimiumDealer"> <TaskLink> 27d4a28b-6e19-4bb4-87f9-7c2a3e67f76f</TaskLink> <AppMemberLink> 31d2b06d-59d8-43a8-ac6a-39739159f4a8 </AppMemberLink> </AzRole> <AzApplicationGroup Guid="31d2b06d-59d8-43a8-ac6a-39739159f4a8" Name="DATApplicationsGrp" Description="Application Group for DAT Applications Access" GroupType="Basic"/> <AzTask Guid="e80e81cd-558d-4367-b7d6-2d460b4bab70" Name="tsk_AccountAdjustment" Description="Task to adjust Postpaid account" BizRuleImportedPath="">

 
Figure 4. Defining Application Operations: Using this dialog, you can add a list of named items and operation numbers to AzMan. Later, you map these names to individual tasks.
<OperationLink> 6567d978-fcfc-4c70-9035-5bee1912e454 </OperationLink> </AzTask> <AzOperation Guid="6567d978-fcfc-4c70-9035-5bee1912e454" Name="op_AccountAdjustment" Description="Account adjustment operation"> <OperationID>2</OperationID> </AzOperation> </AzApplication> </AzAdminManager>
 
Figure 5. Mapping Operations: It's best to create one-to-one task-to-operation mappings to simplify maintenance and improve task reusability.
Next, add all the operations individually for which you need role-based security, giving each a name and a unique integer that represents the operation number as shown in Figure 4.

Note that in naming operations, I've encoded the names with the prefix "op." This is simply to avoid naming collisions later when creating tasks and roles since these names must be unique. The next step is to define a set of tasks that map to these low-level operations. As a best practice, Microsoft recommends that you create tasks that each map to a single operation. Such mappings simplify maintainance and improve task reusability—letting you assign tasks to multiple Roles. So, define a task called tsk_AccountAdjustment and add the operation op_AccountAdjustment defined in the previous step and shown in Figure 4. Figure 5 shows the task-mapping step.

 
Figure 6. Creating an Application Group: Provide a name, description, and the Group type for your new Application Group.
You can also add an authorization script to a task defined as a BizRule. A BizRule is a script added to a task when you plan to apply a known constraint to it. For example, suppose you need to set a maximum adjustment amount of $100. When a caller invokes this task the task treats the parameter value passed as an adjustment amount, which it compares to the maximum value defined here in a script that becomes a BizRule. You can write authorization scripts in either VBScript or JavaScript. Authorization scripts can use information that is available only at runtime, such as "time of day" or "dollar amount requested" to make an authentication decision. Next, you define an Application Group that holds information about the users and groups who will use this application. An Application Group can be either a Basic type or an LDAP Query. This example uses the Basic type because it's not going to assign Windows domain users or groups in this Application Group—it uses a Custom Principal rather than the Windows principal. For this example, create an Application Group as shown in Figure 6.

You don't have to add members in this Application Group because this example uses the custom principal from the code; however, if you're planning to use AzMan with your domain users then you would add domain users or group members in this dialog.

 
Figure 7. Associating Tasks with Roles: The dialog provides a modifiable list of tasks and lower-level roles that you can associate with roles.
The next step is to create roles for the application and assign tasks to those roles as shown in Figure 7.

Define a "PremiumDealer" role in role definition dialog shown above and then add tasks to it so that you can assign roles to users or groups of users who need to perform these tasks. Note that you can chain roles. For example, you can add a role to another higher-level role, which is an extremely convenient feature of AzMan's role-based architecture.

Finally, you assign roles to users or groups. To do this, select the Role Assignments folder (see Figure 3) and choose the Assign Roles action. Note that a role doesn't actually become active in an application until you've added it to this folder. In other words, you first add the "PremiumDealer" role in this folder and then you can assign Application Groups or Windows users and groups to this role. This example assigns the Application Group "DATApplicationsGrp" created earlier to the PremiumDealer role.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date