Security is often a key component to a computer system. It is often separated into two components: 1) Authentication – am I who I say I am?; and 2) What am I allowed to do once authenticated?
From an application perspective, once I am authenticated we check the roles in which I am a member. Then in our code, for each method requiring authorization, we check if any of the roles assigned to the method are roles to which I am granted participation.
If you assign the roles necessary to perform a method inside the method itself, you spread the authorization throughout your application, locating roles in all the methods requiring authorization. If you were to try and locate all of the methods a user of some group were able to accomplish, you would have to search throughout your application. If you expand the search to a user, and all the roles in which they participate, the search would become even more complicated.
Reading the article, "Don’t Do Role-Based Authorization Checks; Do Activity-Based Checks", the author, Derick Bailey recommends centralizing the authorization of all methods into an authorization API. The authorization API accepts a request to authorize an activity for a user. It is responsible for determining what roles/users have permission to execute an activity, and determining if the user in context has breturning a pass fail. By creating an authorization API you have a centralizeen granted participation in any of the allowed roles, or explicitly been granted permisions at the user level. The method itself has no knowledge of what roles are required. The API handles what activities can be performed, and by whate roles/users. All authorization is now centralized in a single location, making it easy to establish who can do what.
Using this implementation a method simply asks the authorization API can I execute for the current user? You could even use reflection to pass in the method that is being exercised so that the call to the authorization API is quite simple…IsAllowed() returning a bool. The method to be test is extracted through reflection. The user to authenticate is passed from the request context.
This kind of authorization extends the capabilities higher than that found in SQL Server. While you can authorize activities in a database to Create/Retrieve/Update/Delete on a table level in a database, using an Authorization API you could extend each of those rights down to individual record levels. Derick uses the example of a user can delete a blog record for which they are the owner.
If you are interested in roles based security, it is worth your while to read Derick’s blog and see if his implementation fits your needs.
Cheers,
Ben