Professional ASP.NET 3.5 in C# and Visual Basic Part 107 pps

Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1018
Chapter 21: Security
❑
IsInRole
: This method takes a single parameter, a string representation of the system role. It
returns a Boolean value that indicates whether the user is in the role specified.
Working with User.Identity
The
User.Identity
property enables you to work with some specific contextual information about the
authorized user. Using the property within your ASP.NET applications enables you to make resource-
access decisions based on the information the object provides.
With
User.Identity
, you can gain access to the user’s name, his authentication type, and whether he is
authenticated. The following table details the properties provided through
User.Identity
.
Attribute Description
Authentication
Type
Provides the authentication type of the current user. Example values include
Basic
,
NTLM
,
Forms
,and
Passport
.
IsAuthenticated

Returns a Boolean value specifying whether the user has been authenticated.
Name
Provides the username of the user as well as the domain of the user (only if he
logged on with a Windows account).
For some examples of working with the
User
object, take a look at checking the user’s login name. To do
this, you use code similar to that shown in Listing 21-12.
Listing 21-12: Getting the username of the logged-in user
VB
Dim UserName As String
UserName = User.Identity.Name
C#
string userName;
userName = User.Identity.Name;
Anothertaskyoucanaccomplishwiththe
User.Identity
object is checking whether the user has been
authenticated through your application’s authentication methods, as illustrated in Listing 21-13.
Listing 21-13: Checking whether the user is authenticated
VB
Dim AuthUser As Boolean
AuthUser = User.Identity.IsAuthenticated
C#
bool authUser;
authUser = User.Identity.IsAuthenticated;
This example provides you with a Boolean value indicating whether the user has been authenticated.
You can also use the
IsAuthenticated
method in an

If
/
Then
statement, as shown in Listing 21-14.
1018
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1019
Chapter 21: Security
Listing 21-14: Using an If/Then statement that checks authentication
VB
If (User.Identity.IsAuthenticated) Then
’ Do some actions here for authenticated users
Else
’ Do other actions here for unauthenticated users
End If
C#
if (User.Identity.IsAuthenticated) {
// Do some actions here for authenticated users
}
else {
// Do other actions here for unauthenticated users
}
You can also use t he
User
object to check the authentication type of the user. This is done with the
AuthenticationType
property illustrated in Listing 21-15.
Listing 21-15: Using the AuthenticationType property
VB
Dim AuthType As String
AuthType = User.Identity.AuthenticationType

C#
string authType;
authType = User.Identity.AuthenticationType;
Again, the result is
Basic
,
NTLM
,
Forms
,or
Passport
.
Working with User.IsInRole()
If you are using Windows-based authentication, you can check to make sure that an authenticated user is
in a specific Windows role. For example, you might want to show specific information only for users in
the
Subscribers
group in the Computer Management Utility. To accomplish that, you can use the
User
object’s
IsInRole
method, as shown in Listing 21-16.
Listing 21-16: Checking whether the user is part of a specific role
VB
If (User.IsInRole("ReutersServer
\
Subscribers")) Then
’ Private information for subscribers
Else
’ Public information

End If
C#
if (User.IsInRole("ReutersServer
\\
Subscribers")) {
// Private information for subscribers
Continued
1019
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1020
Chapter 21: Security
}
else {
// Public information
}
The
IsInRole
method’s parameter provides a string value that represents the domain and the group
(Windows role). In this case, you specify that any user in the
Subscribers
Windows role from the
ReutersServer
domain is permitted to see some information not available to users who don’t belong
to that specific role.
Another possibility is to specify some of the built-in groups available to you. Ever since Windows 2000,
Windows has included a series of built-in accounts such as Administrator, Guest, PrintOperator, and
User. You can access these built-in accounts in a couple of ways. One is to specify the built-in account
with the domain directly:
User.IsInRole("ReutersServer
\
Administrator")

The other possibility is to use the
BUILTIN
keyword:
User.IsInRole("BUILTIN
\
Administrator")
Pulling More Information with WindowsIdentity
So far, in working with the user’s identity information, you have used the standard
Identity
object that
is part of ASP.NET by default. If you are w orking with Windows-based authentication, you also have
the option of using the
WindowsIdentity
object and other objects. To gain access to these richer objects,
create a reference to the
System.Security.Principal
object in your application.
Used in combination with the
Identity
object from the preceding examples, these additional objects
make certain tasks even easier. For instance, if you are working with roles,
System.Security.Principal
provides access to the
WindowsBuiltInRole
enumeration.
Listing 21-17 is an example of using the
WindowsBuiltInRole
enumeration.
Listing 21-17: Using the WindowsBuiltInRole enumeration
VB

Dim AdminUser As Boolean
AdminUser = User.IsInRole(WindowsBuiltInRole.Administrator.ToString())
C#
bool adminUser;
adminUser = User.IsInRole(WindowsBuiltInRole.Administrator.ToString());
Instead of specifying a string value of the domain and the role, you can use the
WindowsBuiltInRole
enumeration to easily access specific roles on the application server. When working with this and other
enumerations, you also have IntelliSense (see Figure 21-11) to help you make your selections easily.
1020
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1021
Chapter 21: Security
Figure 21-11
The roles in the
WindowsBuiltInRole
enumeration include the following:
❑ AccountOperator
❑ Administrator
❑ BackupOperator
❑ Guest
❑ PowerUser
❑ PrintOperator
❑ Replicator
❑ SystemOperator
❑ User
1021
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1022
Chapter 21: Security
Using
System.Security.Principal

, you have access to the
WindowsIdentity
object, which is much
richer than working with the default
Identity
object. Listing 21-18 lists some of the additional informa-
tion you can get through the
WindowsIdentity
object.
Listing 21-18: Using the WindowsIdentity object
VB
<
%@ Page Language="VB" %
>
<
%@ Import Namespace="System.Security.Principal" %
>
<
script runat="server"
>
Protected Sub Page_Load(ByVal sender As Object, _
ByVal e As System.EventArgs)
Dim AuthUser As WindowsIdentity = WindowsIdentity.GetCurrent()
Response.Write(AuthUser.AuthenticationType.ToString() & "
<
br
>
"&_
AuthUser.ImpersonationLevel.ToString() & "
<

br
>
"&_
AuthUser.IsAnonymous.ToString() & "
<
br
>
"&_
AuthUser.IsAuthenticated.ToString() & "
<
br
>
"&_
AuthUser.IsGuest.ToString() & "
<
br
>
"&_
AuthUser.IsSystem.ToString() & "
<
br
>
"&_
AuthUser.Name.ToString())
End Sub
<
/script
>
C#
<

%@ Page Language="C#" %
>
<
%@ Import Namespace="System.Security.Principal" %
>
<
script runat="server"
>
protected void Page_Load(object sender, EventArgs e)
{
WindowsIdentity AuthUser = WindowsIdentity.GetCurrent();
Response.Write(AuthUser.AuthenticationType.ToString() + "
<
br
>
"+
AuthUser.ImpersonationLevel.ToString() + "
<
br
>
"+
AuthUser.IsAnonymous.ToString() + "
<
br
>
"+
AuthUser.IsAuthenticated.ToString() + "
<
br
>

"+
AuthUser.IsGuest.ToString() + "
<
br
>
"+
AuthUser.IsSystem.ToString() + "
<
br
>
"+
AuthUser.Name.ToString());
}
<
/script
>
In this example, an instance of the
WindowsIdentity
object is created and populated with the current
identity of the user accessing the application. T hen you have access to a number of properties that are
written to the browser using a
Response.Write()
statement. The displayed listing shows information
about the current user’s credentials, such as if the user is authenticated, anonymous, or running under
a guest account or a system account. It also gives you the user’s authe ntication type and login name. A
result is shown in Figure 21-12.
1022
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1023
Chapter 21: Security
Figure 21-12

Identity and Impersonation
By default, ASP.NET runs under an account that has limited privileges. For instance, you may find that
although the account can gain access to a network, it cannot be authenticated to any other computer on
the network.
The account setting is provided in the
machine.config
file:
<
processModel
enable="true"
userName="machine"
password="AutoGenerate" /
>
These settings force ASP.NET to run under the system account (ASPNET or Network Service). This is
really specified through the
userName
attribute that contains a value of
machine
. The other possible value
you can have for this attribute is
system
. Here’s what each entails:
❑
machine
: The most secure setting. You should have good reasons to change this value. It’s the
ideal choice mainly because it forces the ASP.NET account to run under the fewest number of
privileges possible.
❑
system
: Forces ASP.NET to run under the local SYSTEM account, which has considerably more

privileges to access networking and files.
It is also possible to specify an account of your choosing using the
<
processModel
> element in either the
machine.config
or
web.config
files:
1023
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1024
Chapter 21: Security
<
processModel
enable="true"
userName="MySpecifiedUser"
password="MyPassword" /
>
In this example, ASP.NET is run under a specified administrator or user account instead of the default
ASPNET or Network Service account. It inherits all the privileges this account offers. You should consider
encrypting this section of the file. Encrypting sections of a configuration file are covered in Chapter 32.
You can also change how ASP.NET behaves in whatever account it is specified to run under through the
<
identity
> element in the
web.config
file. The <
identity
> element in the
web.config

file allows you
to turn on impersonation. Impersonation provides ASP.NET with the capability to run as a process using
the privileges of another user for a specific session. In more detail, impersonation allows ASP.NET to
run under the account o f the entity making the request to the application. To turn o n this impersonation
capability, you use the
impersonate
attribute in the <
identity
> element as shown here:
<
configuration
>
<
system.web
>
<
identity impersonate="true" /
>
<
/system.web
>
<
/configuration
>
By default, the
impersonate
attribute is set to
false
. Setting this property to
true

ensures that ASP.NET
runs under the account of the person making the request to the application. If the requestor is an anony-
mous user, ASP.NET runs under the IUSR_MachineName account. To see this in action, run the example
shown in Listing 21-18, but this time with impersonation turned on (
true
). Instead of getting a username
of
REUTERS-EVJEN
\
ASPNET
as the user, you get the name of the user who is requesting the page —
REUTERS-EVJEN
\
Administrator
in this example — as shown in Figure 21-13.
Figure 21-13
1024
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1025
Chapter 21: Security
You also have the option of running ASP.NET under a specified account that you declare using the
<
identity
> element in the
web.config
file:
<
identity impersonate="true" userName="MySpecifiedUser" password="MyPassword" /
>
As shown, you can run the ASP.NET process under an account that you specify through the
userName

and
password
attributes. These values are stored as clear text in the
web.config
file.
Look at the root
web.config
file, and you can see that ASP.NET runs under full trust, meaning that it has
some pretty high-level capabilities to run and access resources. Here is the setting:
<
system.web
>
<
location allowOverride="true"
>
<
system.web
>
<
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"/
>
<
/securityPolicy
>
<
trust level="Full" originUrl=""/
>
<
/system.web
>
<
/location
>
<
/system.web
>
Five possible settings exist for the level of trust that you give ASP.NET —
Full
,
High
,
Medium
,
Low
,

and
Minimal
. The level of trust applied is specified through the <
trust
> element’s
level
attribute.
By default, it is set to
Full
. Each one points to a specific configuration file for the policy in which the
level can find its trust level settings. The
Full
setting does not include a policy file because it simply
skips all the code access security checks.
Securing Through IIS
ASP.NET works in conjunction with IIS; not only can you apply security settings directly in ASP.NET
(through code or configuration files), but you can also apply additional security measures in IIS itself. IIS
enables you to apply access methods you want by working with users and groups (which were discussed
earlier in the chapter), working with restricting IP addresses, file extensions, and more. Security through
IIS is deserving of a chapter in itself, but the major topics are explored here.
IP Address and Domain Name Restrictions
You can work with the restriction of IP addresses and domain names in Windows Server 2003, Win-
dows 2000 Server, or Windows NT. Through IIS 6.0, you can apply specific restrictions based on a single
computer’s IP address, a group of computers, or even a specific domain name.
To access this capability, pull up the Internet Information Services (IIS) Manager and right-click on either
the Web site you are interested in working with or on the Default Web Site node to simply apply the
1025
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1026
Chapter 21: Security
settings to every Web application on the server. From the menu, choose Properties and select the

Directory Security tab.
Click the Edit button in the IP Address and domain name restrictions box and a dialog appears. The
resulting dialog enables you to grant or restrict access based on an IP address or domain name. These
dialogs are shown in Figure 21-14.
Figure 21-14
Figure 21-15
1026
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1027
Chapter 21: Security
Think t wice about restricting based on a domain name. It can hinder performance when the reverse DNS
lookup is performed on each request to check the domain.
You not only can restrict specific IP addresses and domain names, but you can also restrict everyone and
just allow specified entities based on the same items. Although Figure 21-14 shows restricting a specific
IP address, you can restrict or grant access to an entire subnet as well. Figure 21-15 shows how to grant
access just to the servers on the 192.168.1.0 subnet (defined by a Linksys router).
Working with File Extensions
You can work with many types of files in ASP.NET. These files are defined by their extensions. For
example, you know that
.aspx
is a typical ASP.NET page, and
.asmx
is an ASP.NET Web service file
extension. These files are actually mapped by IIS to the ASP.NET DLL,
aspnet_isapi.dll
.
Figure 21-16
To access the dialog in IIS 6.0 that maps t he file extensions, pull up the Properties dialog of your Web
application in IIS or pull up the Default Web Site Properties. In a specific Web application, you must
work from the Directory tab; but if you are working with the Default Web Site Properties dialog, you
can instead use the Home Directory tab. From these tabs, click the Configuration button in the Applica-

tion Settings box. The Application Configuration dialog includes a Mapping tab, where the mappings
1027