One of the challenges presented when developing Service-Oriented
application is how to setup the authorization for services. That means
"Role salesman is granted to access CreateOrder service"
The ideal would be:
- to have a pipe & filters pluggable architecture where you
could add/remove components without affecting the code of the services
(this is also called cross-cutting concerns)
- to have a nice GUI to manage Tasks and Roles
- to have a programmatic API to do the access check in an agnostic
provider way so if we want to change the Authorization provider in the
future, make it painless.
Luckily these days of continous innovation we have all of these to support it:
- WSE 3 and it Policy Assertions
- AzMan (Authorization Manager)
- Enterprise Library or RoleProvider of ASP.Net 2
Regards (1) I've already written in a previous post about the Policy
Assertions and its purpose. The idea would be to plug a Policy
Assertion that would call AzMan through EntLib or RoleProvider. In this
assertion we take the Action name of WSE using envelope.Context.Addressing.Action.Value and the WindowsPrincipal if we are using KerberosToken in WSE.
In (2) we have this great GUI (Azman.msc) to manage Tasks and Roles.
To install AzMan on Windows XP Professional
Install the Windows Server 2003 Administration Tools Pack, which you
can download from
This tools pack enables remote server management of Windows Server
2003, but it also includes AzMan.
Note that if you are running Windows XP Service Pack 2 or later, you
must also install Service Pack 1 or later of the Windows Server 2003
Administration Tools Pack.
To install AzMan on Windows 2000
Install the Windows 2000 Authorization Manager Runtime, which you can
You must be running Windows 2000 Server Service Pack 4 or later. You
must also install MSXML 4.0 or later.
Note that this installs the runtime components only; it does not
install the AzMan administration MMC snap-in. You can still use the MMC
snap-in on a Windows Server 2003 system, or on a Windows XP system that
has the Windows Server 2003 Administration Tools Pack installed, to
remotely administer AzMan on a Windows 2000 Server.
On Windows XP and Windows 2000, you must install the primary interop
assembly for the AzMan COM object into the global assembly cache. This
assembly is already installed in the global assembly cache on Windows
Server 2003 systems.
Finally regards (3) we could use Enterprise Library Security Application Block which implements an AuthorizationProvider based on Azman. I show in this post
how to use it. Using EntLib will abstract us from the store which in
this case is AzMan and this will lead to more flexibility because in
the future we could use another store (SQL Server, ADAM, AD, etc).
The thing I didn't like about AzMan was that it is bounded to Windows
Tokens. But after some research I found the Custom SID story.
Read this article for an indepth on this post: Combine the Powers of AzMan and WSE 3.0 to Protect Your Web Services from the November 2005 of MSDN Magazine