Sorry for the delay, but here is the source for the WSE 3.0 and Azman authorization sample that went with my MSDN Magazine article on service authorization using WSE 3.0 custom policy assertions and Microsoft Authorization Manager, Azman.

It has been updated to use the released versions of .Net 2.0, WSE 3.0 and Enterprise Library 2.0.

Please download from here, and follow the steps of the README file (40,1 KB, RTF). Note though, that the current sample runs on Windows 2003 only, as it is based on Kerberos which is much easier to make work on IIS 6. (Network Service is the default account for IIS 6.0 App pools, and has access to AD).  The README file has a comment on what it will take to make it work on XP with IIS 5.

The source may be downloaded from here (237,5 KB).

Disclaimer: This code has not been thoroughly tested and is meant as inspiration and illustration only.  Our company, Safewhere, makes the industrial scale version which includes a different modeling approach and support for multiple types of credentials - among other things.

This is the first post on what we are working on at Safewhere™, formerly CI Networks.  (And we're not working on our web site either - will just have to wait for the designers to start work in January.)

The problem is with authorizations in a world of autonomous and loosely coupled web services.  Autonomous in the sense that they live their own life and may contact any other service they see fit, although most likely constrained to some extent by the hosting environment. And loosely coupled in the sense that they participate in higher level processes, that may be reconfigured or extended - or new ones may be created and wired to use our service.

It used to be that users would be authenticated basically once and then the user interface would restrict what a given user was able to do.  And if things get a little more complicated, which they normally do, the backend will check again in more detail to see if a given request or transaction should be allowed to proceed.  Determining if a user is authorized to perform an action is mostly a matter of checking membership of a group, and more rarely also of checking e.g. if the amount requested is below the maximum allowance of a given user.

Enter SOA.  (And no matter what your more precise interpretation turns out to be, the above scenario of autonomy and loose coupling probably sounds familiar.)  How do you make sure that the entity or person sending you (as a service) a message is actually authorized to request you to carry out the implied actions?  Messages may arrive from any other service and user on the network. 

Two issues here: Unauthorized context or just plain unauthorized.  The latter we are used to dealing with at a basic level, whereas the former is a somewhat new experience.

The problems with just plain unauthorized are many, but as both the number and distribution of services increases so does the difficulty of defining, managing, and understanding access requirements.  And in a world of messages, the message must carry sufficient and credible proof of identity - or some other claim of right.  This is not to be left up to the transport (e.g. SSL), as there is no knowing where and how a message may travel on its way.

As illustrated here it seems the context issue is simply matter of asking "as part of which process are you trying to do this?", but it may really be broadened to include also situations where

• Authorization depends on contents of the message. This would be the case when the message holds a request to transfer a sum of money, which may or may not be too large relative to the allowance of the given user or service initiating the request.
• Authorization depends on something that really is not known until sometime after the internal service logic starts to do its work.  This would be the case when the request message simply says transfer the remaining sum for this customer, and the service logic would then dig out the amount and go to work. 

In the case of all but the last type of authorization, the actual authorization check may be moved into the infrastructure and out of the hands of the developer with two immediate benefits: No need to worry about or decide on this issue at development time.  And authorization may possibly be configured after service deployment, provided the infrastructure knows how.  (The latter is illustrated in a limited scope by my MSDN article on AzMan and WSE 3.0)

So if you think this is an issue worth dealing with, please let me know - or if you have opposing or clarifying views even more please let me know.

- and Merry Christmas, which around here is tomorrow night.

Havde i dag mulighed for at præsentere OIO-udviklerforum i Videnskabsministeriet for udfordringer og koncepter i forbindelse med autorisation og rettighedsstyring i en service orienteret infrastruktur. 

Præsentationen kan hentes her (553,5 KB).

My new article, What Gives You the Right? Combine the Powers of AzMan and WSE 3.0 to Protect Your Web Services, on Web Service Enhancements 3.0 combined with AzMan for controlling access to individual end points is now available in the November issue of MSDN Magazine.

Authorization Manager, or just AzMan , is authorization feature available with Windows 2003 and backported to Windows XP and Windows 2000 of appropriate service pack levels.

For details, please refer to other articles such as the MSDN Magazine November 2003 article Authorize It: Use Role-Based Security in Your Middle Tier .NET Apps with Authorization Manager which explains well what AzMan does and how to use it.

Still I would like to point to a few areas of AzMan worth noting before deciding to use it in a production setup. AzMan is basically a rather simple feature based on a great concept. Still, as implemented in the current versions of Windows its adoption is probably held back by a few missing details.

AzMan in its current incarnation will ride on top of an authorization store hosted in either a simple XML file (with no associated schema), in Active Directory or in Active Directory Application Mode, ADAM. Using a file based store is not advised except for your development setup – in which case it is great. Using Active Directory gets you the performance and robustness you need, but requires that you raise the domain level to Windows 2003 functional level. Using ADAM is a fine choice, and presents only a few challenges in more advanced combinations with AzMan.

The biggest challenge with AzMan is defining your application in terms of Operations, Tasks, and Roles in a way that lets you move that definition forward through the stages of development and deployment. Following a common path you start out with a file based XML store, where you configure and test the setup. But as soon as you want to move the contents of the XML file forward into another environment with an AzMan store based instead on e.g. Active Directory, the missing export/import facility is brought to your attention. As it turns out you are left with only two options: either you manually configure the AzMan application definition for each deployment stage in each and every cycle, or you write you own service (preferably an MSI Installer custom action) capable of treating an AzMan XML store to a new home inside Active Directory.