ASP.Net Application Security Chapter 18 (Freeman and Jones) CS795/895

ASP.Net Application SecurityChapter 18 (Freeman and Jones)

CS795/895

ASP.Net Configuration Files

• ASP.NET configuration data is stored in XML text files, each named Web.config. These include important security settings, such as the user authentication mechanism to use and the code-access security policy to apply to an ASP.net application.

• Web.config files can appear in multiple directories in ASP.NET applications. • It implements a hierarchically configured file structure.

– The main source of configuration is the machine.config file– Each folder in an ASP.net application’s virtual path can contain a configuration file named web.config. It

provides configuration settings for the application resources located in the folder.– Child folders inherit the configuration of their parent folder.– The web.config in a child folder overrides those configured higher up in the folder hierarchy.

ASP.Net Configuration Files (cont.)

• ASP.Net security-related configuration elements

• <location>: Specifies the resource that specified configuration settings apply to.

<configuration>

<location path="Logon.aspx">

<system.web>

<authorization>

<allow users="?"/>

</authorization>

</system.web>

</location>

</configuration>

<configuration>

<location path="UploadPage.aspx">

<httpRuntime maxRequestLength="128"/> /*Max size can be 128K for uploading */

</location>

</configuration>

<configuration>

<location allowOverride="false"/> /* child directory web.config settings cannot override this*/

</configuration>


• <machinekey>: Configures keys to use for encryption and decryption of forms authentication cookie data and view-state data, and for verification of out-of-process session state identification.

• Example to set both the validationKey and decryptionKey attributes to AutoGenerate. The isolateApps value is specified to generate unique keys for each application on the server.

<machineKey

validationKey="AutoGenerate,IsolateApps" [String]

decryptionKey="AutoGenerate,IsolateApps" [String]

validation="SHA1" [SHA1 | MD5 | 3DES | AES]

decryption="Auto" [Auto | DES | 3DES | AES]

/>

– validationKey: Specifies the key used to validate encrypted data. It is is used when enableViewStateMAC is true in order to create a message authentication code (MAC) to ensure that view state has not been tampered with. It is also used to generate out-of-process, application-specific session IDs to ensure that session state variables are isolated between sessions.

– decryptionKey: Specifies the key that is used to encrypt and decrypt data or the process by which the key is generated. This attribute is used for forms authentication encryption and decryption, and for view-state encryption when validation is set to the TripleDES field.

– validation: Specifies the type of encryption that is used to validate data.

– decryption: Specifies the type of hashing algorithm that is used for decrypting data.


• <authentication>: Configures the ASP.NET authentication scheme that is used to identify users who view an ASP.NET application.

<authentication

mode="[Windows|Forms|Passport|None]“

>

<forms>...</forms>

<passport/>

</authentication>

Example:

<configuration>

<system.web>

<authentication mode="Forms">

<forms name="401kApp" loginUrl="/login.aspx"/>

</authentication>

<authorization>

<deny users="?"/>

</authorization>

</system.web>

</configuration>


• <authorization>: determines whether an identity should be granted access to a specific resource. In ASP.NET, there are two ways to authorize access to a given resource.

– File authorization checks the access control list (ACL) of the .aspx or .asmx handler file to determine whether a user should have access to the file. ACL permissions are verified for the user's Windows identity (if Windows authentication is enabled) or for the Windows identity of the ASP.NET process.

– URL authorization maps users and roles to URLs in ASP.NET applications. This module can be used to selectively allow or deny access to arbitrary parts of an application (typically directories) for specific users or roles. --- With URL authorization, you explicitly allow or deny access to a particular directory by user name or role.

<authorization>

<allow verbs="GET" users="*"/>

<allow verbs="POST" users="Kim"/>

<deny verbs="POST" users="*"/>

</authorization>

* means all users, both authenticated and anonymous

? means anonymous users

<authorization>

<allow users="Kim"/>

<allow roles="Admins"/>

<deny users="John"/>

<deny users="?"/>

</authorization>


• <identity>: Configures the identity of the Web application. This element can be declared at any level in the configuration file hierarchy.

– username: Specifies the user name to use, if the impersonate attribute is true.– Password: Specifies the password to use, if the impersonate attribute is true. – Example: userName="registry:HKLM\Software\AspNetProcess,Name"password="registry:HKLM\Software\AspNetProcess,Pwd"

<identity impersonate="true|false"

userName="domain\username"

password="<secure password>"/>


• <securityPolicy>: Defines a collection of mappings between security policy files and the trust level names for the security policy files.

<securityPolicy>

<trustLevel name="Full" policyFile="internal"/>

<trustLevel name="High" policyFile="web_hightrust.config"/>

<trustLevel name="Medium" policyFile="web_mediumtrust.config"/>

<trustLevel name="Low" policyFile="web_lowtrust.config"/>

<trustLevel name="Minimal" policyFile="web_minimaltrust.config"/>

<trustLevel

name="CustomTrustLevel"

policyFile="customtrust.config"/>

</securityPolicy>

ASP.Net Configuration Files (cont.)• <processModel> Configures the ASP.NET process model settings on a Microsoft Internet Information Services

(IIS) Web server. The processModel section can be set only within the Machine.config file and affects all ASP.NET applications that are running on the server.

<processModel

enable="true"

timeout="Infinite"

idleTimeout="Infinite"

shutdownTimeout="00:00:05"

requestLimit="Infinite"

requestQueueLimit="5000"

restartQueueLimit="10"

memoryLimit="60"

webGarden="false"

cpuMask="0xffffffff"

userName="machine"

password="AutoGenerate"

logLevel="Errors"

clientConnectedCheck="00:00:05"

comAuthenticationLevel="Connect"

comImpersonationLevel="Impersonate"

responseDeadlockInterval="00:03:00"

responseRestartDeadlockInterval="00:03:00"

autoConfig="true"

maxWorkerThreads="20"

maxIoThreads="20"

minWorkerThreads="1"

minIoThreads="1"

serverErrorMessageFile=""

pingFrequency="Infinite"

pingTimeout="Infinite"

asyncOption="20"

maxAppDomains="2000"

/>

Configuring ASP.net Worker Process Identity

• http://etutorials.org/Programming/Programming+.net+security/Part+IV+.NET+Application+Frameworks/Chapter+18.+ASP.NET+Application+Security/18.2+Configuring+the+ASP.NET+Worker+Process+Identity/

• ASP.net uses a pool of worker processes to handle ASP.net application requests. • By default, each worker process executes in the context of a special windows account named

ASP.NET.• ASP.NET account is assigned a limited set of Windows privileges and permissions.• We can change the account under which ASP.NET worker processes run by configuring the

username and password attribute of the <processModel> element in the machine.config file. – This change affects all ASP.NET applications running on the machine.– userName =Machine---default value; runs as ASP.NET account– username=System---causes ASP.NET worker process to run as the same account under which

IIS is running; by default this will be the built-in Windows System account.– username=SomeUser---specify the name of an account under which the worker process should

run.

<configuration>

<processModel userName="System" password="AutoGenerate"/>

</configuration>

<configuration>

<processModel userName="SomeUser" password="secret"/>

</configuration>

<configuration>

<processModel userName="registry:HKLM\Software\OReilly\AspNet,Name"

password="registry:HKLM\Software\OReilly\AspNet,Password"/>

</configuration>

ASP.Net authentication: IIS Authentication Modes

• ASP.NET provides the following authentication modes:

– None (No authentication)

– Windows Authentication (needs IIS Authentication)

– Forms Authentication

– Extending Forms Authentication

– .Net Passport Authentication

• The authentication modes for different ASP.NET applications may be configured by settings in the application’s web.config file. It can ONLY be set at the application level.

• Before a client request reaches the ASP.NET application, it must pass through IIS authentication.

• For Windows authentication---IIS authentication provides the application with the information about the authenticated Windows user.

ASP.Net authentication: IIS Authentication Modes (cont.)

• For None, Forms, and Passport authentication modes---IIS authentication is turned off by enabling anonymous access to IIS.

• For Windows authentication mode---IIS authentication is used (with 5 options)

• Unless the impersonation option is enabled, ASP.NET authentication has no effect on the Windows user context under which the ASP.NET application executes.



• Configuring IIS Authentication Modes: Anonymous authentication

– By default, IIS enables anonymous authentication and uses the IUSR_machinename user account with the password controlled by IIS.

– Anonymous authentication gives users access to the public areas of your Web site without prompting them for a user name or password. Here, the client is not required to supply any credentials. Instead, IIS provides stored credentials to Windows using a special user account, IUSR_machinename. By default, IIS controls the password for this account.

– Pros of anonymous authentication

• Offers the best performance because Anonymous authentication imposes no appreciable overhead.

• Does not require management of individual user accounts.

• If IIS does not control the password, can access network resources.

– Cons of anonymous authentication

• Does not authenticate clients on an individual basis.

• If IIS does not control the password, account must have local logon ability.

ASP.Net authentication: IIS Authentication Modes(cont.)

• Configuring IIS Authentication Modes: Basic authentication

– When a client requests a resource protected by Basic authentication, IIS challenges the client to provide a username and a password.

– The client responds by sending the username and password details across the network in clear text. Hence, it is not appropriate for secure applications unless SSL or TLS are used providing a secure connection between the client and the server.

– Procedure: • IIS obtains logon info from an HTTP client via the familiar windows dialog box to

obtain username and password• The information is then transmitted to the web server• It then attempts to login to the windows account with the username and password• It also checks if the account is allowed to access the requested file/directory• If successful, the response rendered by web server is returned to the HTTP client• Weakness: Username + password data between client and server is encoded into a

string that intruders may have access to. So it is preferable to use if SSL-like secure mechanism is used in between.


• Configuring IIS Authentication Modes: Digest authentication

– Similar to Basic authentication, but the client passes a hash of the user’s password across the network instead of the clear text password.

– But this requires the IIS server to be a member of a Windows domain that uses Active Directory to contain its user accounts.

– Only Active directory allows IIS to access a user’s password in such a way as to allow IIS to verify the hashed password provided by the client.

– Procedure:

• Like basic authentication, it requires user to enter username/password.

• Instead of sending the password in clear, it sends a digest of the password.

» The HTTP client creates a hash value of the password, the nonce sent by the HTTP server, and some other values. This hash is the digest

» The HTTP server uses the stored password for the username to generate the hash (digest) and verifies it.


• Configuring IIS Authentication Modes: Integrated Windows authentication

– When IIS challenges a client to provide user credentials, the client application does not prompt the user for account information; instead, it extracts the necessary etails from the OS based on the currently logged-on used.

– Credentials are communicated using Windows authentication protocols.---ensuring that passwords are not sent across the network.

– Procedure:• Most popular among the simple authentication schemes• For users who have already logged into a Windows machine • Provides WAN or LAN based internet applications with an authentication

practice that is virtually invisible to the user• A domain controller provides user credentials to the client station where

user log in.• These credentials are in turn transferred to the IIS at the request server

• Configuring IIS Authentication Modes: Client Certificate authentication

– Requires each client to have an X.509 digital certificate.

– Each certificate maps to a specific Windows user account.

– When a client makes a request, it contains the client’s certificate.

– IIS validates the certificate and determines which Windows user is making the request.

ASP.Net Authentication: No authentication

• No authentication

– If we are not concerned about authenticating users, or intend to use some custom authentication mechanism implemented within the ASP.NET application, we can turn off ASP.NET authentication.

< configuration>

<system.web>

<authentication mode=“None">

</authentication>

</system.web>

</configuration>

– Even if we are not concerned about using ASP.NET authentication mechanisms, we can still enable IIS authentication so that we can allow ONLY permitted Windows users to access the application.

– To truly allow unrestricted access to the application, enable anonymous access to IIS.

ASP.Net Authentication: Windows Authentication

• Windows authentication– Relies on IIS to authenticate any inbound requests. IIS can use any of its built-in Basic, Digest, Integrated, or client

certificate authentication mechanisms before the request reaches the ASP.net application.

– Only if IIS anonymous authentication is not enabled, IIS will ensure that the requesting user has a valid Windows account and pass the authenticated user’s information to the ASP.net application.

– In this case, ASP.net application principal is set to an instance of System.Principal.WindowsPrincipal configured to represent the authenticated Windows user.

< configuration>

<system.web>

<authentication mode=“Windows">

</authentication>

</system.web>

</configuration>

ASP.Net Authentication: Windows authentication (cont.)

• Windows authentication

–Advantages:

• Little work for programmer

• Integrates well with IIS security

• Integration with windows client machine---no need for a user to authenticate for an application if already done so initially by the windows OS

–Disadvantages:

• Tied to windows users

• Tied to windows client M/C

• Lack of flexibility

–Result:

• This creates a WindowsPrincipal object and a WindowsIdentity object, with each request

• User.Identity.Name provides user name

• WindowsPrincipal.IsInRole methods lets us test if the user has a specific role

ASP.Net Authentication: Forms Authentication

• Windows authentication requires users of ASP.net applications to have Windows user accounts. For large web-based and cross-platform applications, this may not be feasible or desirable.

• Forms authentication allows us to implement a custom authentication mechanism where we can authenticate users against any type of authority.

• Note: To use Forms authentication, we should enable IIS anonymous access. Otherwise, IIS will force users to first authenticate with whatever mechanism it is set to.

• It works as follows:– When request is made to a page protected by forms authentication, the user is

redirected to a login page. The URL of the original request is preserved.– Login page contains a form for users to enter their credentials (e.g., username

and password)– If the details the user entered are correct, an “Authentication ticket” is created.

The ticket contains the encrypted details of the user. The ticket is written into a cookie and sent to the client machine. The credentials are authenticated by the application in whichever way it prefers (e.g., database). Thus responsibility to authenticate completely depends on the application developer.

– The user is then redirected back to the URL they originally requested. Now the authentication cookie is added to the request by the browser and picked up by the authentication module.

– The URL authorization module uses the details to verify user and provide access

ASP.Net Authentication: Forms Authentication (cont.)

<authentication mode="Forms">

<forms name="SavingsPlan" loginUrl="/Login.aspx">

<credentials passwordFormat="SHA1">

<user name="Kim"

password="07B7F3EE06F278DB966BE960E7CBBD103DF30CA6"/>

<user name="John"

password="BA56E5E0366D003E98EA1C7F04ABF8FCB3753889"/>

</credentials>

</forms>

</authentication>


For details of steps 1-10, refer to http://msdn.microsoft.com/en-us/library/ff647070.aspx


• Pros: – Keeps all authentication code within the application– We have full control over the appearance of the login form– Works for users with any browser– Allows us to decide how to store user information (by default stored in

web.config file but can be stored anywhere)

• Cons:– We have to create our own interface for users to log in– We have to maintain user details ourselves– Resources protected by forms authentication must be processed

by ASP.Net (i.e., anonymous access bypassing ASP.Net is not possible)


• Procedure:– Step 1: Configure forms authentication in the web.config file: (See Table 18.2,

Freeman&Jones, page 470)

<authentication mode="Forms" >

<forms name="MyASPXFORMSAUTH“--- unique name for the cookie

loginUrl="Login.aspx“---page to which user should be directed

timeout="15“”---length of time in minutes an authentication cookie is valid

path="/ “---path for the cookie for the browsers

protection="All"> ---do both encryption and a MAC for the cookie

<credentials passwordFormat="MD5">

<user name="bethb"

password="26E13F4ECF73413D5DC9A99FDDD34C84" />

</credentials>

</forms>

</authentication>

ASP.Net Authentication: Forms Authentication (cont.)• cookieless ASP.NET 2.0 Forms Authentication can store the forms authentication ticket in either a cookie, or in a cookie-less

representation on the URL. The default value of UseDeviceProfile means that ASP.NET determines where to store the ticket based on pre-computed browser profiles. The AutoDetect option causes ASP.NET to dynamically determine if the browser supports cookies or not. UseUri and UseCookies force cookieless and cookied tickets respectively.

• defaultUrl Specifies the default URL to which the request is redirected after a successful login. This value is used if a redirect URL is not available to Forms Authentication when redirecting after login.

• domain Specifies the value of the Domain property on the HttpCookie containing the forms authentication ticket. Explicitly setting this attribute allows applications to share the same cookie as long as the applications share a common portion of a DNS namespace (e.g. appA.contoso.com and appB.contoso.com could share a cookie if the domain attribute is set to "contoso.com").

• enableCrossAppRedirects In ASP.NET 2.0, Forms Authentication allows you to pass the forms authentication ticket across applications in either a query-string variable or in a forms POST variable. Setting this attribute to true enables the FormsAuthenticationModule to extract the ticket from either the query-string or forms POST variables.

• loginUrl Specifies the URL to which the request is redirected for unauthenticated users. This can be on the same computer or a remote one. If it is on a remote computer, both computers need to be using the same value for the decryptionkey and validationKey attributes found in the machineKey configuration element.

• name Name of the HTTP cookie to use for authentication purposes. Note that if more than one application wants to use forms-based authentication services on a single computer, and each application wants the forms authentication cookie to be isolated by application, then they should each configure a unique cookie value. In order to avoid causing dependencies in URLs, ASP.NET also uses "/" as the Path value when setting authentication cookies, so that they are sent back to every application on the site.

• path Path to use for the issued cookie. The default value is "/" to avoid difficulties with mismatched case in paths, since browsers are strictly case-sensitive when returning cookies. Applications in a shared-server environment should use this directive to maintain private cookies. (Alternatively, they can specify the path at runtime using the APIs to issue cookies.)

• protection Method used to protect cookie data. Valid values are as follows: ##All: Use both data validation and encryption to protect the cookie. The configured data validation algorithm is based on the <machinekey> element. AES is used by default for encryption, and if the key is long enough (48 characters). All is the default (and suggested) value.

• ##None: Use for sites that are only using cookies for personalization and have weaker security requirements. Both encryption and validation can be disabled. Although you should use caution if you use cookies in this way, this setting provides the best performance of any method of doing personalization using the .NET Framework.

• ##Encryption: Encrypts the cookie using AES, TripleDES or DES, but data validation is not done on the cookie. This type of cookie can be subject to chosen plaintext attacks.

• ##Validation: Does not encrypt the contents of the cookie, but validates that the cookie data has not been altered in transit. To create the cookie, the validation key is concatenated in a buffer with the cookie data and a MAC is computed and appended to the outgoing cookie.

• requireSSL If set to true, Forms Authentication sets the secure bit on the forms authentication cookie. Compliant browers will only send the cookie back to ASP.NET over an SSL connection. Note that this setting has no effect when using cookieless forms authentication.

• slidingExpiration If set to true, Forms Authentication will periodically update the time to live for the forms authentication ticket. This occurs regardless of whether or not the ticket is contained in a cookie, or in a cookieless format on the URL.

• timeout Amount of time in integer minutes, after which the cookie expires. The default value is 30. The timeout attribute is a sliding value, expiring n minutes from the time the last request was received. In order to avoid adversely affecting performance and to avoid multiple browser warnings for those who have cookies warnings turned on, the cookie is updated if the time is more than half gone. (This means a loss of possible precision in some cases.)

• http://quickstarts.asp.net/QuickStartv20/aspnet/doc/security/formsauth.aspx


• Procedure:• Step 2: Create a login page. This is the page where ASP.NET redirects all

unauthenticated user requests. • Note that client requests containing a valid authentication cookie are routed directly

to the requested application resource; only those without an authentication cookie are redirected to the login page.

• In the we,config file, under the <forms> element, the loginURL attribute specifies the URL of the login page.form to enable users to enter their credentials.

• (For more info: http://www.ondotnet.com/pub/a/dotnet/2003/01/06/formsauthp1.html)


• C# Code for logon.aspx (http://edc.tversu.ru/elib/inf/0087/0596004427_prognetsec-chp-18-sect-3.html)<html> <script language="C#" runat="server"> void Logon_Click(Object sender, EventArgs e) {

// Perform authentication of the user credentials. // Use the static FormsAuthentication.Authenticate method // to authenticate the credentials against those contained // in the <credentials> element of Web.config. if (FormsAuthentication.Authenticate(Name.Text,Password.Text)) { // Credentials OK, redirect to originally requested page. FormsAuthentication.RedirectFromLoginPage(Name.Text,true);}} </script> <body> <h2>Forms Authentication Example - Logon Page</h2> <form id="LogonForm" method="post" runat="server"> <table> <tr align="right"> <td>User Name : </td> <td><asp:TextBox id="Name" runat="server"/></td> </tr> <tr align="right"> <td>Password : </td> <td><asp:TextBox id="Password" runat="server"/></td> </tr> <tr align="center"> <td colspan="2"> <asp:Button id="Logon" runat="server" Text="Logon" OnClick="Logon_Click"/> </td> </tr> </table> </form> </body></html>

ASP.NET Authorization• Authorization determines whether an authenticated entity can access the resource it

requested.• ASP.Net provides two types of authorizations:

– File authorization– URL authorization

• File authorization:– File authorization is enforced automatically when we enable ASP.NET windows

authentication, and cannot be disabled or configured.– After IIS authenticates the user, but before ASP.NET hands the request to the

File authorization is performed by the FileAuthorizationModule. It checks the access control list (ACL) of the .aspx or .asmx handler file to determine whether a user should have access to the file.

– ACL permissions are verified for the user's Windows identity (if Windows authentication is enabled) or for the Windows identity of the ASP.NET process.

– If the user has permission, ASP.NET will hand the request to the application for processing; otherwise, it will refuse the request.

ASP.NET Authorization: File Authorization1. Create a new web application. Name the form Index.aspx2. Place the following code under the <form> tag: <a href =“AuthorizedFile.aspx”> Click here for AuthorizedFile </a> <br> <a href =“UnAuthorizedFile.aspx”> Click here for UnAuthorizedFile </a>3. Add two new web forms: AuthorizedFile.aspx and UnAuthorizedFile.aspx 4. Under <form> tag in AuthorizedFile type: <h2> You have access to the file </h2> Under <form> tag in UnAuthorziedFile type: <h2> You do not have access to the file

</h2>5. Build the solution and run: Clicking the links, the messages will appear6. Create three different users: user1, user2, user37. Provide the following access rights to UnauthorizedFile.aspx: user1: Full access;

user2: Read and Execute; user3: Deny All8. Login as user3 and click on UnAuthorizedFile link; it will be denied access

ASP.Net Authorization: URL authorization• With URL authorization, you explicitly allow or deny access to a particular directory by user name or role. To

do so, you create an authorization section in the configuration file for that directory. To enable URL authorization, you specify a list of users or roles in the allow or deny elements of the authorization section of a configuration file. The permissions established for a directory also apply to its subdirectories, unless configuration files in a subdirectory override them.

<authorization> //grants access to the Kim identity and members of the Admins role, and denies

//access to the John identity (unless the John identity is included in the Admins role)

//and to all anonymous users:

<allow users="Kim"/>

<allow roles="Admins"/>

<deny users="John"/>

<deny users="?"/>

</authorization>

<authorization>

<allow users="John"/> //allow access to the John identity and deny access to all other users:

<deny users="*"/>

</authorization>

<authorization>

<allow verbs="GET" users="*"/>

<allow verbs="POST" users="Kim"/>

<deny verbs="POST" users="*"/>

</authorization>

ASP.NET Impersonation• When authorizing access to a resource, ASP.NET will only search until it finds the

first <allow> or <deny> element that appears to the current identity. Hence, the order of the elements is important.

• Authorization restrictions created lower down the application hierarchy take precedence over those defines higher up.

• “?” all unauthenticated users• “*” all users, authenticated and unauthenticated• Impersonation:

– Impersonation allows an ASP.NET application to run in the context of the authenticated Windows user that made the web request..

– Thus, all server-side resources accessed by the ASP.net occur in the context of the authenticated user.

<configuration> <system.web> <identity impersonate="true"/> //control impersonation using //the identity configuration element. </system.web>

</configuration><identity impersonate="true" userName="contoso\Jane" password="********" />

ASP.NET Impersonation (cont.)• Impersonation may be configured at any level of the configuration hierarchy; it can be configured differently for

individual applications or application resources, if needed.• When IIS anonymous authentication is used, if impersonation is enabled, the ASP.NET application will

impersonate the user account configured in IIS for anonymous access; by default it is IUSR_MACHINENAME user account.

IPrincipal Interface

• HttpContext.Current.User property returns an instance of IPrincipal

• It is part of System.Security.Principal• Has a single property: Identity: Gets the IIdentity

of the current Principal: Example: HttpContext.Current.User.Identity.Name

• Has single method: IsInRole(roleName As String): Example: if (HttpContext.Current.User.IsInRole(“Admin”) {…..}

IIdentity Interface

• Provides current user’s identity

• Four identity classes included in .Net:– System.Web.Security.WindowsIdentity– System.Web.Security.FormsIdentity– System.Web.Security.PassportIdentity– System.Web.Security.GenericIdentity

How Identity and Principal are used?

• Types of identities: depending on authentication used: WindowsIdentity, FormsIdentity, PassportIdentity, GenericIdentity

• All these implement IIdentity interface (part of System.Security.Principal namespace)

• An application may always find the user attached to the current thread using Identity object

• Principal: a combination of user and groups the user belongs to (Identity+roles)

• Principal types: WindowsPrincipal and GeneraicPrincipal• Both implement IPrincipal interface (part of

System.Security.Principal namespace)• IPrincipal provides the following:

• IIdentity Identity (get): to get the underlying object• IsInRole(string role): to determine whether the user belongs to a certain role

How .Net Security Works• Users who log in to the application are granted a principal and an

identity, based on the credentials they have provided.• Principal object: Represents the group or role membership of the

authenticated user, i.e. security context of the current user. It is possible to create a generic principal object using data from a database. Httpcontext.Current.User property returns an instance of IPrincipal.

• Identity object represents the authenticated user. Windows authentication uses WindowsIdentity while forms authentication uses FormsIdentity object.

• http://www.developerland.com/Web/Security/215.aspx

Role-based Security

• In general, authorization requirements are as follows:– Users should have proper credentials to access a resource– Certain users need to be denied access to particular resources– Only certain users should be allowed to access particular

resources

• If you intend to use RBS, you must either assign an IPrincipal to a thread manually or configure the runtime to create one automatically

• Use System.AppDomain.SetThreadPrincipal to automatically generate for each thread, or – Set current thread’s IPrincipal manually using

System.Thredaing.Thread.CurrentPrincipal property.

Making Role-based Security Demands

• Do not result in a stack walk---based solely on identity and roles of the active thread’s principal

• Imperative role-based security statements:– Commonly used constructor: PrincipalPermission– Each PrincipalPermission can specify only a single role name.

“null” means no matching is needed– Public PrincipalPermission(string name, string role)PrincipalPermission p1 = new PrincipalPermission(“John”, “Manager”);

p1.Demand();

PrincipalPermission p2 = new PrincipalPermission(null, “Programmer”); p2.Demand();PrincipalPermission p3 = new PrincipalPermission(“Kevin”, null); p3.Demand();PrinciplaPermission

Explanationhttp://msdn.microsoft.com/en-us/library/system.security.permissions.principalpermission.aspx

Making Role-based Security Demands (cont.)

• Using Declarative role-based security statements:– PrincipalPermissionAttribute may be applied to

classes, methods, properties, or events to force declarative demands

– This cannot be applied at the assemble level– Demand, LinkDemand, and InheritanceDemand are

the only RBS statements allowed [PrincipalPermission(SecurityAction.Demand, Name=“John”, Role=“Manager”)]

[PrincipalPermission(SecurityAction.Demand, Role=“Programmer”)]

[PrincipalPermission(SecurityAction.Demand, Name=“Kevin”)]

File Authorization• FileAuthorizationModule class uses the underlying ACLs of the

file system to control access to ASPX pages• This works only in conjunction with Windows Authentication• Example:1. Create a new web application. Name the form Index.aspx2. Place the following code under the <form> tag: <a href =“AuthorizedFile.aspx”> Click here for AuthorizedFile </a> <br> <a href =“UnAuthorizedFile.aspx”> Click here for UnAuthorizedFile </a>3. Add two new web forms: AuthorizedFile.aspx and UnAuthorizedFile.aspx 4. Under <form> tag in AuthorizedFile type: <h2> You have access to the file </h2> Under <form> tag in UnAuthorziedFile type: <h2> You do not have access to the file </h2>5. Build the solution and run: Clicking the links, the messages will appear6. Create three different users: user1, user2, user37. Provide the following access rights to UnauthorizedFile.aspx: user1: Full access; user2: Read and

Execute; user3: Deny All8. Login as user3 and click on UnAuthorizedFile link; it will be denied access

• Authorization for a specific file or folder (using web.config):

<location path=“UnAuthorizedFile.aspx”><system.web> <authorization> <deny users = “\localhost\user3” /> </authorization></system.web></location>(This overrides what the OS says about the permissions)

Calculation of Permissions• The default permission is to allow access for all users• Upon calculation of a merged rule set, the system checks the rules

until it finds a match: either allow or deny• When a deny is encountered, the system throws a 401 error:

Unauthorized access• Example: At the application level, include in web.config: <authorization> <allow

users=“localhost\user1, \localhost\user2” /> <deny users = “?”/> </authorization>

At a particular page level, we can add this to web.config:<location path=“UnAuthorizedFile.aspx”> <system.web> <authorization><deny roles = “users” /> </authorization></system.web> </location>Denies access to this page to any windows user.

Authorization Checks in Code

• We can control access even at a button level using checks in the code

• If {user1, user2} are made into a single group called validgroup, then:

if (Thread.CurrentPrincipal.IsInRole(“localhost\validgroup”))

{Response.Write (“You have access”);}else

{Response.Redirect(“AuthorizationError.aspx”);}

Demanding Credentialstry{ PrincipalPermission pp = new PrincipalPermission(“user1”, “validgroup”); pp.Demand(); Response.Write(“PrincipalPermission successful”);}Catch (SecurityException se){Response.Write (“PrincipalPermission Denied”);}

Merging PrincipalPermission objects:try{PrincipalPermission pp1 = new PrincipalPermission(“user1”, “validgroup”);{PrincipalPermission pp2 = new PrincipalPermission(“user2”, “validgroup”);{PrincipalPermission pp3 = (PrincipalPermission)p1.Union (p2); pp3.Demand(); Response.Write(“PrincipalPermission successful”);}Catch (SecurityException se){Response.Write (“PrincipalPermission Denied”);}

PrincipalPermissionAttribute: Another way to Authorize

• Place the following code above the method declaration:

[PrincipalPermissionAttribute(SecurityAction.Demand, Name=“user1”, Role = “validusers”)]

Or[PrincipalPermissionAttribute(SecurityAction.Demand, Role =

“validusers”)]

Documents

ASP.Net Application Security Chapter 18 (Freeman and Jones) CS795/895