How to use the PrincipalPermission Class to check authorization in ASP.NET in VB.NET

.NET provides alternative way to enforce role and user rules. Instead of approach described in the article How to use IsInRole method to check authorization in ASP.NET in VB.NET, you can use the PrincipalPermission class from the System.Security.Permissions namespace. You should follow the next steps:

1. Create a PrincipalPermission object that represents the user or role information you require

2. Invoke the PrincipalPermission.Demand() method.

3. If the current user doesn’t meet the requirements, a SecurityException will be thrown, which you can catch or deal with using a custom error page.


The constructor of the PrincipalPermission provides four overloads, from one up to three parameters, which are in turn evaluated by the Demand() method of the class:

– User name

– Role name

– Flag that asks the PrincipalPermission’s Demand() method to verify if the user is authenticated or not (isAuthenticated).

– PermissionState parameter which is inherited by the base class of the PrincipalPermission class

Note: You can omit either one of these parameters by supplying a null reference in its place

For example with the following code you can test whether the user is a Windows administrator:



Dim PP As PrincipalPermission = New PrincipalPermission(vbNull, “BUILTIN\Administrators”)


‘ If the code reaches this point, the demand succeeded.

‘ The current user is an administrator.

Catch ex As Exception

‘ The demand failed. The current user isn’t an administrator.

End Try


Advantage of this approach:

You don’t need need to write any conditional logic, because you can only demand all the permissions you need. This works well when you need to verify that a user is a member of multiple groups

Disadvantage of this approach:

By using exception handling to control the flow of your application is slower.


Often, PrincipalPermission checks are used in addition to web.config rules as a failsafe. You can call Demand() to ensure that even if a web.config file has been inadvertently modified, users in the wrong groups won’t be allowed.