Authorization Rules
ScottGu posted an article showing how to add authorization rules to business and data layers.
In his sample code, he shows how easy it is:
using System.Security.Permissions;
[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]
public class EmployeeManager
{
[PrincipalPermission(SecurityAction.Demand, Role = "Manager")]
public Employee LookupEmployee(int employeeID)
{
// todo
}
[PrincipalPermission(SecurityAction.Demand, Role = "HR")]
public void AddEmployee(Employee e)
{
// todo
}
}
The attributes in the code above insure that the user is authenticated, and that for the LookupEmployee method, the user is a member of the role "Manager", and for the AddEmployee method, the user is a member of the "HR" role.
Consider the code above, what would happen if the business wanted to allow the Manager role to execute the AddEmployee method?
What is happening in this code above is that the assignment of permissions to perform actions is compiled in the code. I don't think that's the best place for it. This code is defining what it means to be a member of Manager or HR roles. What if the business wanted to define some new role with some permissions from Manager and some from HR? Again, a recompile of the code is needed.
One day I will get to actually coding this, but I'd like to see this same sort of attribute-based security, except by using Authorization manager (AzMan). The nice thing about AzMan is that is provides one more layer of abstraction to the security model, so that the assignment of permissions to roles is an administrative function, not a coding function. AzMan manages a set of application defined tasks and operations (essentially just string identifiers, a task consisting of zero or more operations) and the assignment of these tasks and operations to roles, and the membership of roles. AzMan stores this information in XML or in ActiveDirectory, and it uses membership from ActiveDirectory or other membership systems so that an administrator can say that the HR role consists of a set of Active Directory groups or users.
The beauty of this is that the application can ask AzMan if the current user can perform a given operation, and get a simple yes or no response. The application doesn't need to know who the current user is, what groups they belong to, or even what roles are defined.
So, to me this is what I would like to see the above code changed to:
using System.Security.Permissions;
[AzManPermission(SecurityAction.Demand, Authenticated = true)]
public class EmployeeManager
{
[AzManPermission(SecurityAction.Demand, Operation = "EmployeeManager.LookupEmployee")]
public Employee LookupEmployee(int employeeID)
{
// todo
}
[AzManPermission(SecurityAction.Demand, Operation = "EmployeeManager.AddEmployee")]
public void AddEmployee(Employee e)
{
// todo
}
}
I'm guessing that I could probably make this simpler by removing the Operation attribute and just derive the operation name from the class and method names instead. And somewhere you would have to initialize the AzMan store at runtime, and create/maintain the operation names (following the class.method pattern) in the AzMan store during development.
If you've seen something like this, please let me know. Or if you write it yourself, I'd love to see it.
AzMan has been available since Windows Server 2003, and I just don't understand why it hasn't been much more widely adopted in the subsequent programming models that have been released since then (like .NET 2.0).
Mike