Role-Based Security checks in ASP.net

Always use an authentication method before letting a user access your application. Authentication, in any shape or form, is the only way to establish an identity. Without it, you are not able to implement role-based security.

Let’s assume that your application requested a username and password from the user, checked it against the application’s own authentication database, and established the user’s identity. You then have to create the GenericPrincipal to be able to perform role-based verifications in your application:

• 1. Create a GenericIdentity object for the User1 you just authenticated:

     1. C#: GenericIdentity GenIdent = new GenericIdentity("User1"); VB.NET: Dim GenIdent As New GenericIdentity("User1")

  2. Create the GenericPrincipal object, bind the GenericIdentity object to it, and add roles to the GenericPrincipal:

     2. 1. C#: string[] UserRoles = {"Role1", "Role2", "Role5"}; C#: GenericPrincipal GenPrinc = new GenericPrincipal(GenIdent, UserRoles); VB.NET: Dim UserRoles as String() = {"Role1", "Role2", "Role5"} VB.NET: Dim GenPrinc As New GenericPrincipal(GenIdent, UserRoles)

  3. Bind the GenericPrincipal to the thread. Again, you need SecurityPermission:

• • 1. C#: Thread.CurrentPrincipal = GenPrinc; VB.NET: Thread.CurrentPrincipal = GenPrinc

Manipulating Identity

You can manipulate the identity that is held by a principal object in two ways. The first is replacing the principal; the second is by impersonating an identity.

Replacing the principal object on the thread is a typical action you perform in applications that have their own authentication methods. To be able to replace a principal, your code must have been granted the SecurityPermission, or more specifically, the SecurityPermission attribute ControlPrincipal. This will allow your own code to be able to pass on the PrincipalObject to other code. This attribute grants you the permission to manipulate the principal so that the CLR allows you to pass on the principal. You can replace the Principal object by performing these steps:

• 1. Create a new identity and Principal object, and initialize it with the proper values.

  2. Bind the new principal to the thread:

     1. C#: Thread.CurrentPrincipal = NewPrincipalObject; VB.NET: Thread.CurrentPrincipal = NewPrincipalObject

     2. Impersonating is also a way of manipulating the principal, with the intent of taking on another user’s identity user to perform some actions on that user’s behalf. You can identify two variations:

        • The code has to impersonate the WindowsPrincipal that is attached to the thread. This might seem a little odd, but you have to remember that your code is part of an application domain that runs in a process. A user—whether a system account, a service account, or even an interactive user—starts this process on the Windows platform. Although the principal can be used to perform role-based verification within the code, accessing protected resources is still done with the identity of the process user, unless you actively use the user account of principal through impersonation.

        • The code has to impersonate a user who is not attached to the current thread. The first thing you have to do is obtain the Windows token of the user you want to impersonate. This has to be done with the unmanaged code LogonUser. The obtained token has to be passed to a new WindowIdentity object. Now you have to call the Impersonate method of WindowsIdentity. The old identity—hence, token—has to be saved in a new instance of WindowsImpersonationContext.

At the end of the impersonation, you have to change back to the original user account by calling the Undo method of the WindowsImpersonationContext.

Remember, the Principal object is not changed; rather, the WindowsIdentity token, representing the Windows account, is switched with the current token. At the end of the impersonation, the tokens are switched back again, as shown in the following steps:

• 1. Call the LogonUser method, located in the unmanaged code library advapi32.dll. You pass the username, domain, password, logon type, and logon provider to this method, which will return a handle to a token. For the sake of the example, we will call it hImpToken.

  2. Create a new WindowsIdentity object and pass it the token handle:

     1. 1. C#: WindowsIdentity ImpersIdent = new WindowsIdentity(hImpToken); VB.NET:   Dim ImpersIdent As New WindowsIdentity(hImpToken)

  3. Create a WindowsImpersonationContext object and call the Impersonate method of ImpersIndent:

• • • 1. C#: WindowsImpersonationContext WinImpersCtxt = ImpersIdent.Impersonate(); VB.NET:   Dim WinImpersCtxt As WindowsImpersonationContext = ImpersIdent.Impersonate()

• 4. At the end of the call, the original Windows token has to be put back in the Identity object:

• • 1. C#: WinImpersCtxt.Undo(); VB.NET:   WinImpersCtxt.Undo()

You could have done Steps 2 and 3 in one statement that looks like this:

   Dim WinImpersCtct As WindowsImpersonationContext = _              WindowsIdentity.Impersonate(hImptoken)

Remember that you cannot impersonate when you use a GenericPrincipal, because it does not reference a Windows identity. For generic principals, you need to replace the principal with one that has a new identity.

Role-Based Security Checks

Now that we’ve discussed the creation and manipulation of PrincipalObject, it’s time to take a look at how it can assist you in performing role-based security checks. Here is where PrincipalPermission, already mentioned in the beginning of the “Role-Based Security” section, comes into play. Using PrincipalPermission, you can make checks on the active Principal object, whether WindowsPrincipal or GenericPrincipal. The active Principal object can be one you created to perform a one-time check, or it can be the principal you bound to the thread. Like the code access permissions, the PrincipalPermission can be used in both the declarative and the imperative way.

To use PrincipalPermission in a declarative manner, you need to use the PrincipalPermissionAttribute object, as shown in Figures A.17 and A.18.

[PrincipalPermissionAttribute(SecurityAction.Demand, Name = "User1", Role =  "Role1" )]  public int Act2()  {   return 1; } [assembly:PrincipalPermissionAttribute(SecurityAction.Demand, Role =  "Administrator")] 

Figure A.17: Using the PrincipalPermissionAttribute: C#

Public Shared Function _ <PrincipalPermissiobAttribute(SecurityAction.Demand, _      Name := "User1", Role := "Role1")> Act2() As Integer           ' body of the function End Function <assembly: PrincipalPermissionAttribute(SecurityAction.Demand, Role :=  'Administrator')> 

Figure A.18: Using the PrincipalPermissionAttribute: VB.NET

To use the imperative manner, you can perform the PrincipalPermission check, as shown in Figures A.19 and A.20.

PrincipalPermission PrincPerm = new PrincipalPermission("User1", "Role1"); PrincPerm.Demand(); 

Figure A.19: Using PrincipalPermission: C#

Dim PrincPerm As New PrincipalPermission("User1", "Role1") PrincPerm.Demand() 

Figure A.20: Using PrincipalPermission: VB.NET

It is also possible to use the imperative to set the PrincipalPermission object in two other ways, as shown in Figures A.21 and A.22.

PrincipalPermission PrincPerm = new  PrincipalPermission(PermissionState.Unrestricted);  

Figure A.21: C#

Dim PrincState As PermissionState = Unrestricted Dim PrincPerm As New PrincipalPermission(PrincState) 

Figure A.22: VB.NET

The permission state (PrincState) can be None or Unrestricted, where None means the principal is not authenticated. Therefore, the username is Nothing, the role is Nothing, and Authenticated is false. Unrestricted matches all other principals.

bool PrincAuthenticated = true; PrincipalPermission PrincPerm = new PrincipalPermission("User1", "Role1",  PrincAuthenticated); 

Figure A.23: C#

Dim PrincAuthenticated As Boolean = True Dim PrincPerm As New PrincipalPermission("User1", "Role1", PrincAuthenticated) 

Figure A.24: VB.NET

The IsAuthenticated field (Princauthenticated) can be true or false.

In a situation in which you want PrincipalPermission.Demand() to allow more than one user/role combination, you can perform a union of two PrincipalPermission objects. However, this is possible only if the objects are of the same type. Thus, if one PrincipalPermission object has set a user/role, and the other object uses PermissionState, the CLR throws an exception. The union looks like Figures A.25 and A.26.

PrincipalPermission PrincPerm1 = new PrincipalPermission("User1", "Role1"); PrincipalPermission PrincPerm2 = new PrincipalPermission("User2", "Role2"); PrincPerm1.Union(PrincPerm2).Demand(); 

Figure A.25: C#

Dim PrincPerm1 As New PrincipalPermission("User1", "Role1") Dim PrincPerm2 As New PrincipalPermission("User2", "Role2") PrincPerm1.Union(PrincPerm2).Demand() 

Figure A.26: VB.NET

The Demand will succeed only if the principal object has the user User1 in the role Role1 or User2 in the role Role2. Any other combination fails.

As we mentioned before, you can also directly access the Principal and Identity objects, thereby enabling you to perform your own security checks without using PrincipalPermission. Besides the fact that you can examine a little more information, this solution also prevents you from handling exceptions that can occur using PrincipalPermission. You can query the WindowsPrincipal in the same way the PrincipalPermission does this:

• • The name of the user by checking the value of WindowsPrincipal.Identity.Name:

    • • [ C#: if (WinPrinc.Identity.Name == "User1" || C#:   WinPrinc.Identity.Name.Equals("DOMAIN1\\User1")) C#: { C#: } VB.NET:   If (WinPrinc.Identity.Name = "User1") or _ VB.NET:   WinPrinc.Identity.Name.Equals("DOMAIN1\User1") Then VB.NET:   End If 

  • An available role by calling the IsInRole method:

• • • C#: if (WinPrinc.IsInRole("Role1"))  C#: { C#: } VB.NET:   If (WinPrinc.IsInRole("Role1")) Then VB.NET:   End If

• • Determining if the principal is authenticated, by checking the value of WindowsPrincipal.Identity.IsAuthenticated:

• • • C#: if (WinPrinc.Identity.IsAuthenticated)  C#: { C#: } VB.NET:   If (WinPrinc.Identity.IsAuthenticated) Then VB.NET:   End If

Additionally for PrincipalPermission, you can check the following WindowsIdentity properties:

• • AuthenticationType Determines the type of authentication used. Most common values are NTLM and Kerberos.

  • IsAnonymous Determines if the user is identified as an anonymous account by the system.

  • IsGuest Determines if the user is identified as a guest account by the system.

  • IsSystem Determines if the user is identified as the system account of the system.

  • Token Returns the Windows account token of the user.