27.3. Role-Based Security

Now that you understand how code access security works, we can turn our attention to a related feature included in the .NET Framework that can assist with authorization — role-based security. As you will remember from earlier in this chapter, authorization is how your application controls access to different resources and operations for different identities. At its most basic level, authorization answers the question, "What can a user do within this application?"

Role-based security approaches authorization by defining different application roles, and then building into your application security around those roles. Individual users are assigned to one or more roles, and inherit the rights assigned to those roles. The rights assigned to a role may allow access to certain functions within the application, or limit access to a subset of the data. For example, your application may need to provide full access to a database on sales tenders only to employees who are either managers or lead salespeople. However, the supporting employees involved in a tender may need access to a subset of the information, such as product specifications but not pricing information, which you want to be able to provide from within the same application.

Role-based security enables you to do this by explicitly specifying different levels of approval within the application functionality itself. You can even use this methodology to give different user roles access to the same functionality but with different behavior. For instance, managers may be able to approve all tenders, whereas lead salespeople can only approve tenders under a certain amount.

27.3.1. User Identities

You can implement role-based security in your application by retrieving information that Windows provides about the current user. It is important to note that this isn't necessarily the user who is currently logged on to the system, because Windows allows individuals to execute different applications and services via different user accounts as long as they provide the correct credentials. This means that when your application asks for user information, Windows returns the details relating to the specific user account being used for your application process.

Visual Studio 2008 applications use the .NET Framework, which gives them access to the identity of a particular user account through a Principal object. This object contains the access privileges associated with the particular identity, consisting of the roles to which the identity belongs.

Every role in the system consists of a group of access privileges. When an identity is created, a set of roles is associated with it, which in turn defines the total set of access privileges the identity has. For instance, you might have roles of ViewTenders, AuthorizeTenders, and RestrictTenderAmount in the example scenario used in this section. All employees associated with the sales process could be assigned the role of ViewTenders, while management and lead salespeople have the AuthorizeTenders roles as well. Finally, lead salespeople have a third role of RestrictTenderAmount, which your code can use later to determine whether they can authorize the particular tender being processed. Figure 27-5 shows how this could be represented visually.

Figure 27.5. Figure 27-5

The easiest way to implement the role-based security functionality in your application is to use the My.User object. You can use the IsAuthenticated property to determine whether there is a valid user context under which your application is executing. If there isn't, your role-based security code will not work, so you should use this property to handle that situation gracefully.

If you're using this code in a C# application, you'll need to add the references to the My namespace, as explained in Chapter 14.

Once you've established that a proper user context is in use, use the IsInRole method to determine the methods to which the current user identity belongs. The actual underlying implementation of this depends on the current principal. If it is a Windows user principal (WindowsPrincipal), which means that we have authenticated the current principal against a Windows or Active Directory account, the function checks the user membership against Windows domain or local groups. If the current principal is any other principal, this function passes the name of the enumeration value in role to the principal's IsInRole method.

27.3.2. Walkthrough of Role-Based Security

As with code access security, the best way to understand role-based security is to walk through a simple example of it in practice. This time we will begin by creating a new Visual Basic Windows Forms application with a very simple layout of eight label controls as shown in Figure 27-6. The four labels on the right-hand side should be named lblIsAuthenticated, lblName, lblIsStandardUser, and lblIsAdminUser.

Figure 27.6. Figure 27-6

Add the following code behind this form:

Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) _
                                                                Handles Me.Load
   With My.User
      Me.lblIsAuthenticated.Text = .IsAuthenticated
      If .IsAuthenticated Then
         Me.lblName.Text = .Name
         Me.lblIsStandardUser.Text = _
                  .IsInRole(ApplicationServices.BuiltInRole.User)
         Me.lblIsAdminUser.Text = _
                  .IsInRole(ApplicationServices.BuiltInRole.Administrator)
      Else
         Me.lblName.Text = ""
         Me.lblIsStandardUser.Text = "False"
         Me.lblIsAdminUser.Text = "False"
      End If
   End With
End Sub

When you run this code it should display your current username, and indicate whether the user is a member of the Users and Administrators group. If your computer is a member of a Windows domain, the actual groups it refers to are Domain Users and Domain Administrators. You can experiment with this form by using RunAs to execute it under different users' credentials.

In addition to using the built-in roles that Windows creates, you can also call the IsInRole method, passing in the role name as a string, in order to check the membership of your own custom-defined roles.