It’s a nice feeling when things work out the way you planned and designed!
Today I reviewed a newly deployed WCF based credit card service with my manager. Our design included the use of some existing building blocks to speed implementation and take advantage of best practices. The building blocks included Enterprise Library 4.1 and Authorization Manager (AzMan). I enjoyed walking through the implementation for a number of reasons, one of which was the relatively small amount of hand written custom code.
The relatively small codebase was made possible by the use of pre-existing building blocks (AzMan and EntLib). I’ve used them before, but was pleasantly surprised again by them. Many of you are aware of Enterprise Library (EntLib) and I’m sure that many of you have a strong opinion for or against it. I’m going to guess that many of you have not heard of or used Authorization Manager (AzMan). If you have, then I’d love to hear your opinion and experiences with it!
Personally, I think AzMan is an amazing little block that is already built into Windows Server 2003 and above, providing a very nice solution to the ever-present problem of authorization. Many of us have heard of Role Based Access Control (RBAC). This is a good practice and gets you part of the way, but I feel that it falls way short of the ideal. The problem is that you have to hard code the rules in your application (over and over again) that decide whether a given role is granted access. If you want fine grained control, you have to create many “roles”, which in the case of Active Directory means many many groups. You network admin may not like you so much when he get’s your request for all these groups.
Bringing AzMan into the picture solves both of these problems. You can get as fine grained as you want using the AzMan concept of an “operation”. Then you “configure” your rules about what users or groups have permissions to perform the operations. This means that you can change the rules after the solution is deployed. The fact that the technology ships with Windows Server, including a user interface for managing the rules makes it a cinch to sell to the organization and the operations staff.
One addition feature that I find really cool is “scoping”. AzMan’s “scope” feature is proving very useful as a means to support isolation between clients in a multi-tenant implementation. It allows us to easily define a base set of rules and then map those rules to different accounts for each “scope”. In our case, each client is it’s own scope. I’m not aware of any other simple and free block that provides this feature.
EntLib shined in this implementation too. We used a good portion of the blocks to get the solution created in a very short time. We used
- Data access block
- LINQ is not yet approved.
- We used a code gen tool to assist with creating the EntLib code and entities.
- Security block for interfacing with AzMan
- Coding against AzMan is a breeze with this block!
- Cryptography block for encrypting sensitive information
- I was very happy with the crypto block. While the audit is not complete, we think that it will provide a PCI compliant solution. Keys can be protected, exported, and managed appropriately with the EntLib configuration console.
- Logging block
- Exception block
- Caching block
- Used via the built in capability to cache the AzMan stores for improved performance
EntLib provided best practices, a well tested codebase, and a nice administration app for editing the configuration. Writing these areas by hand would have added a significant amount of time while introducing additional risks to the project and more stuff to test.
I am please with the results and happy that the amount of custom code is relatively small. My unit tests covered the core business logic without too much trouble and doing a code review didn’t take all that much time. I felt confident during the walkthrough with my manager because I know that a good portion of the tricky logic was based on existing, well tested code that was highly configurable and manageable.