This is typical scenario where programmer done want to allow specific user to visit specific page due to functionality which needs to be secure based on user types. The task like managing users should not accessed by a normal user. So we need security based on user types, more precisely we need Authorization. Once user passed thru authentication it is not Authorization who decide the access of current logged user to perform some task.
Before introductions of ASP.NET Rolebase providers, people used to check on each page for the role, and if it does not have that role then redirection process, here all data related to user role kept in session.
This functionality is much more simpler after introduction of Rolebase provider, we just need to define roles and access to that roles. We can restrict users based on either role or userid itself, its depend how the application needs the functionality. This is for particular page, now what if I need to restrict user at operation level? Mean I don't allow Account user to manage users personal details, he just need to play with user's account, he does not need to update personal details of user. Here we can use Rolebase provider to check whether logged in user have rights to perform that operation or not.
Rolebase page Access: After setting roles and mapping, you just need to add few settings into configuration file which rolebase provider will use to perform authorization. Typical example of such web.config is as following.
Lets understand the setting.
- location tag in which you have to specify path of resource. If path is directory then the authorization will consider on all the pages inside that directory.
- authorization tag will contains the allow or deny user/roles listing.
- allow tag contains the roles attribute, in which you have to put role name. So you are allowing user having SiteAdmin to access ManageUser page. In the same way if you write deny roles then it will deny that particular role to access ManageUser page.
- deny tag contains roles or user. In typical setting we are putting selected roles/users in allow list and for rest we kept as deny, so in deny you may always find * which means all user or all roles.
Typically we have more then one configuration files kept in different-different directories to manage folder separately.
Now let's see how we can implement operation level security using Rulebase provider. Microsoft Enterprise Library Security Application Block helps developers implement common authorization-related functionality in their applications. We just need to set some configuration setting using which you can identify the operation level access. Following is the typical configuration to implement rulebase provider.
You can see the how rule has been added here along with expression. You can add new rule by adding name and expression, expression is simple string which contains set of Role name and expression. There are list of more expression you can find bellow. First lets try to understand EditPersonalInfo rule, it has two role SiteAdmin or Superuser or User, so all user having these roles can perform EditPersionInfo operation.
Rule Expression can contains I, R, AND, OR, NOT, (, ), ?, *.
- I: It will authorize to identity which is supplied with I
- expresson="I:Imran" will allow a user with identity Imran
- R: It will authorize to role which is supplied with R
- Rest will be operator you can use at any time
- expression="((R:Superuser OR R:AccountAdmin) AND (NOT R:SiteAdmin))"
Now this is all about configuring rules. Will see how to apply these rules in our coding.
Just two lines of code to know weather user is authorize to do that action or not.