posted on Saturday, March 26, 2005 2:37 PM
by
davidboschmans
Using and troubleshooting Authorization Manager
Last week at customer site we deployed a new release of our web-based line-of-business application. This major release includes besides some business services, role-based security. As the design of the application was done without security, it took quite some effort to build the security smoothly into the architecture and design of the application.
We used Authorization Manager (AzMan) to take care of the administration of our role-based security. Access to the application is provided by the administrator through user roles that relate to job functions. Our application stores the defined authorization policy in the form of an authorization store that is stored in an XML file. This authorization policy is applied at run time and manageable through the AzMan interface. Applications call a run-time access check method that checks access against the policy information in the authorization store.
After validation of the role-based security implementation by our testing-team, we planned and deployed the application into the production environment. Some smoke tests showed us that we got it right. Big was my surprise when two days later I was called, saying a user had an "Access Denied" error-page. After having checked the user's authorization policy, we turned on logging on the AzMan wrapper class (which also provides some other features like caching etc.). Simulating the "Access Denied" application error was difficult because it appeared randomly. After successfully reproducing the error the logfile showed the message "The specified domain either does not exist or could not be contacted". Some googling directed us to the Microsoft Help and Support site. As described here, this error message is thrown when the AuthzInitializeContextFromSid function passes a non-null-terminated string to the DsGetDcName function. This problem can be resolved by installing a hotfix provided by Microsoft. Instructions to download and install the patch can be requested here.
Once the patch was installed the error was not encountered anymore. Problem solved!
After all, implementing role-based security through AzMan was pretty straightforward. However, critical for the success in my opinion is:
- making good choices for roles, tasks and operations.
- having a clear view on how to implement security in your application is key.
- as a lot of security checks will have an impact on the application performance, caching security information and retrieving it when required is worth considering.
Worth thinking about:
- if possible within your environment consider using the Enterprise Library Security Application Block for building common security-related functionality into applications.
- if you're building Visual Studio 2005 applications, also have a look at the Permission Manager for ASP.Net 2.0 on the GotDotNet workspace. It's a provider based solution and with this manager you can add permission to object for roles and users. The Permission Manager will also use the Roles manager if it's enabled. A new version also includes Authorization Manager.
Here are some good resources on implementing role-based security in multi-tier applications using Authorization Manager: