Using CLR Role-Based Security in Windows

for RuBoard

Within the Common Language Runtime are classes that allow you to further programmatically determine which user account your code will execute under and allow things to happen outside of the rights assigned under a Windows account. In other words, it is possible to have users that are Windows users that have administrative rights within the application but are not actually in the Administrators group on Windows NT/2000/XP. The same is true of assemblies. They may have administrative logic built in, but not be part of the local administrators group .

The main reason for this starts with the principal . Basically, a principal is like a proxy that can act on behalf of a user, but also can assume the identity and role of that user. Within the .NET Framework, there are three basic principals:

• Generic Principals ” These are users that may or may not exist within a Windows 2000 domain and, therefore, may have privileges within an application that they may not otherwise have.

• Windows Principals ” These are Windows users within a role or group on Windows NT and/or Windows 2000. They can impersonate other users, meaning that they can access resources on behalf of another user while presenting that user's credentials.

• Custom Principals ” This group is defined by an application, and the rules are set by that application and/or its configuration.

Now, because principals are used to determine what is in a role or what a user can do, it makes demands to determine whether or not a request can be completed. A demand will succeed only if the user is allowed to perform the task requested ; otherwise, a security exception is thrown. This process is managed by the PrincipalPermission class. The PrincipalPermission class is part of the System.Security namespace. Within this are numerous members that are quite fun to play with and very informative when it comes to managing and recording who does what with what context and when they did it. Listing 14.6 demonstrates creating a new PrincipalPermission and executing a demand. Note that this call could be made imperatively by calling the IPrincipal.IsInRole method as well.

Listing 14.6 Creating a PricipalPermission Code Snippet

 try { String id = "Joe"; String role = "Sales"; PrincipalPermission PrincipalPerm1 = new PrincipalPermission(id, role); PrincipalPerm1.Demand(); } catch(SecurityException e) { ... do something to handle the error } 

Figuring out who the Windows user is during this process can be done under one condition, the user must be authenticated by one of the methods listed at the beginning of this chapter. The following code sample in Listing 14.7 is a complete listing for the file named WebForm1.aspx.cs . This is the "code behind" file that Visual Studio.NET will compile to a DLL. I left everything completely generated as it appears in Visual Studio.NET to illustrate exactly what you may see when developing. The environment for this file to execute in is a Web with Anonymous Access turned off and only Windows Integrated Authentication turned on. This sample also shows how using the authentication mode of Windows allows ASP.NET to automatically wire the User object to your application. The complete sample is included on the book's Web site.

Listing 14.7 WebForm1.aspx.cs (Complete)

 using System; using System.Collections; using System.ComponentModel; using System.Data; using System.Drawing; using System.Web; using System.Web.SessionState; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.HtmlControls; namespace Chapter14 {  /// <summary>  /// Summary description for WebForm1.  /// </summary>  public class WebForm1 : System.Web.UI.Page  {   private void Page_Load(object sender, System.EventArgs e)   {    // Put user code to initialize the page here    if(User.Identity.IsAuthenticated)    {     Response.Write("Authenticated as : " + User.Identity.Name);    }    else    {     Response.Write("You are not authenticated.");    }   }   #region Web Form Designer generated code   override protected void OnInit(EventArgs e)   {    //    // CODEGEN: This call is required by the ASP.NET Web Form Designer.    //    InitializeComponent();    base.OnInit(e);   }  /// <summary>   /// Required method for Designer support - do not modify   /// the contents of this method with the code editor.   /// </summary>   private void InitializeComponent()   {    this.Load += new System.EventHandler(this.Page_Load);   }   #endregion  } } 

As stated before the sample, within IIS, Integrated Windows Authentication is the only option checked under Directory Security. Also, the web.config file is using the default setting of Windows for the authentication element's mode attribute. Listing 14.8 illustrates this.

Listing 14.8 web.config file (Complete)

 <?xml version="1.0" encoding="utf-8" ?> <configuration>   <system.web>     <!--  DYNAMIC DEBUG COMPILATION           Set compilation debug="true" to enable ASPX debugging.  Otherwise, setting this  value to           false will improve runtime performance of this application.           Set compilation debug="true" to insert debugging symbols (.pdb information)           into the compiled page. Because this creates a larger file that executes           more slowly, you should set this value to true only when debugging and to           false at all other times. For more information, refer to the documentation about           debugging ASP .NET files.     -->     <compilation          defaultLanguage="c#"          debug="true"     />     <!--  CUSTOM ERROR MESSAGES           Set customError mode values to control the display of user-friendly           error messages to users instead of error details (including a stack trace):           "On" Always display custom (friendly) messages           "Off" Always display detailed ASP.NET error information.           "RemoteOnly" Display custom (friendly) messages only to users not running           on the local Web server. This setting is recommended for security purposes, so           that you do not display application detail information to remote clients.     -->     <customErrors     mode="RemoteOnly"     />     <!--  AUTHENTICATION           This section sets the authentication policies of the application. Possible  modes are "Windows", "Forms",           "Passport" and "None"     -->     <authentication mode="Windows" />     <!--  APPLICATION-LEVEL TRACE LOGGING           Application-level tracing enables trace log output for every page within an  application.           Set trace enabled="true" to enable application trace logging.  If  pageOutput="true", the           trace information will be displayed at the bottom of each page. Otherwise, you  can view the           application trace log by browsing the "trace.axd" page from your web application           root.     -->     <trace         enabled="false"         requestLimit="10"         pageOutput="false"         traceMode="SortByTime"   localOnly="true"     />     <!--  SESSION STATE SETTINGS           By default ASP .NET uses cookies to identify which requests belong to a  particular session.           If cookies are not available, a session can be tracked by adding a session  identifier to the URL.           To disable cookies, set sessionState cookieless="true".     -->     <sessionState             mode="InProc"             stateConnectionString="tcpip=127.0.0.1:42424"             sqlConnectionString="data source=127.0.0.1;user id=sa;password="             cookieless="false"             timeout="20"     />     <!--  GLOBALIZATION           This section sets the globalization settings of the application.     -->     <globalization             requestEncoding="utf-8"             responseEncoding="utf-8"    />  </system.web> </configuration> 

for RuBoard