Chapter 10

ASP.NET Security

Introduction to Web Security

Categories
Issues
Components

Building a Secure Web Site

Three Categories of Web Security:

Content freely available to everyone (public).
Serve the general population but require a login
(application-level security, protected).
Intranet sites for a controlled population of users a
companys employees (private).

Security Issues:
Application-level security (users).
Deployment security (programmers).

Web Security Components:

Authentication identifies the originator of requests (who).
Authorization defines who can access which pages (what).

Authentication

ASP.NET supports three types of authentication:

Forms (Page-wide)
Windows (Machine-wide)
Passport (Internet-wide)
None

Web.config
<configuration> <system.web>
<authentication mode="Forms"/>
</system.web> </configuration>
Note:
The authentication mode is an application-wide setting
that can be set only in the application root and cant be
overridden in subordinate Web.config files.
You cant use Windows authentication in one part of an
application and forms authentication in another.

Setting authentication mode in the root

Web.config

Authorization

ASP.NET supports two forms of authorization:

ACL (access control list) authorization, also
known as file authorization, based on file
system permissions, typically used with
Windows authentication.
URL authorization, relies on configuration
directives in Web.config files, most often used
with forms authentication.

Three Typical Security Scenarios

for Web Applications
Pages can be freely browsed by any: no
application-level security
Intranet application: use Windows
authentication and ACL authorization.
Internet application with secure page access:
use forms authentication and URL
authorization.

Where is the Passport

passport.com
December 1999: Microsoft forgot to pay $35
annual registration fee to Network Solutions.
Michael Chaney paid on the Christmas day
and get the site up next day.
Replaced by Widows Live ID. No more onelogin-for-all.
Changed to Microsoft Account in 2012.

The Internal Working of

IIS and ASP.NET
Security

IIS Security

IIS (Internet Information Services) Server

a Web server
runs in process Inetinfo.exe as SYSTEM
accepts connections
responds to HTTP requests

Web applications are deployed in application directories. Remote

clients cant arbitrarily grab files outside application directories.

IIS assigns every request an access token representing a Windows

security principal. The access token enables the operating system to
perform ACL checks on resources targeted.

IIS supports IP address and domain name restrictions.

IIS supports encrypted HTTP connections using the Secure Sockets

Layer (SSL) family of protocols.

IIS Security

Anonymous access (access by

unauthenticated users)

Request from anonymous users are tagged

with IUSR_machinenames access token.
IUSR_machinename is an Internet guest
account created when IIS is installed,
where machinename is usually the Web
servers machine name.

The relationship between IIS and ASP.NET.

ASP.NET Security

Server Side Processing:

(1) Client accesses .ASPX files =>
(2) Inetinfo.exe (IIS) generates an access token
=> Aspnet_isapi.dll sents the request and the
token through named pipe or local procedure
calls (LPCs) =>
(3) Aspnet_wp.exe (ASP.NET) makes ACL
checks on the requested resource and passes
access token to the targeted application =>
(4) Targeted application uses a HTTP pipeline =>
HTTP modules => HTTP handlers (mapped in
Machine.config).

Two types of access tokens:

Authenticated user: authenticated security principal
Unauthenticated user: IUSR_machinename for
anonymous login
Start->Settings->Control Panel->Administrative Tools>Computer Management->Local Users and Groups>Users
Start->Settings->Control Panel->Administrative Tools>Computer Management->Event Viewer->Security

The ASPNET Account

Created when ASP.NET is installed.

A member of the Users group (hidden now).

Aspnet_wp.exe runs as ASPNET by default.

Requests executed by ASP.NET use Aspnet_wp.exes

identity.

ASP.NET can impersonate to use the requests access

token.

To make Aspnet_wp.exe to run as SYSTEM, change

processModel in Machine.config to
<processModel userName="SYSTEM" ... />

Programming Forms Authentication

Forms Authentication

Forms authentication allows applications to setup web

authentications independently from the authentications of
the operating systems. It works well with URL
authorization, which relies on configuration directives in
Web.config files.

Forms/URL security is useful to protect an e-commerce

site (an external Internet application for servicing customs
of a company).

Forms Authentication: Static Structure

Security settings in an ASP.NET-based web
application are configured in the Web.config
files.
The Web.config file in the root directory (which
must be an application directory) specifies the
authentication mode, application-specific login
page.
The Web.config file in a subdirectory sets the
authorization specifics for the directory.
User credentials can be stored in a database
(preferred) or in the root Web.config file.

Forms Authentication : Dynamic Behavior

The first time a user accesses a protected resource,
ASP.NET redirects the user to the login page.
If the login is successful, ASP.NET then issues the user
an authentication ticket in the form of a cookie (cookies
need to be enabled by the client) and redirects the
user to the page originally requested.
The ticket allows that user to revisit protected portions
without having to login again.
The tickets lifetime can be controlled to determine how
long the login is good for.

A First Look at Forms Authentication

Forms1 Web Application

T:\Xiao\Windows Programming\Examples\C10\Forms1

At the application root

PublicPage.aspx can be viewed by anyone
Web.config
LoginPage.aspx

In the Secret subdirectory

ProtectedPage.aspx is available only to
authenticated users (wp/wp).
Web.config

Deploy Forms1 on Winserv1

Create a web application (Forms1).
C:\inetpub\wwwroot\xiaotest\Forms1
You need to have admin privilege.
On winserv1, use an existing web application directory
already created for you.
Copy everything from
T:\Xiao\Windows Programming\Examples\C10\Forms1
to the above directory
(C:\inetpub\wwwroot\xiaotest\Forms1)
http://winserv1.cs.uakron.edu/xiaotest/Forms1/PublicPag
e.aspx can be viewed by everyone.
(http://winserv1.cs.uakron.edu/Examples/C10/Forms1/Pu
blicPage.aspx)

Deploy Forms1 on Winserv1

http://winserv1.cs.uakron.edu/xiaotest/Forms1/Secret/Pro
tectedPage.aspx is available only to authenticated users
(wp/wp).
Authenticated users means anyone who has
successfully logged in through LoginPage.aspx.
Valid users are stored in Web.config.
The cookie containing the authentication ticket is a
session cookie, destroyed when the browser is closed.
You are not prompted for password again during a
session.

Programming Forms Security

Authentication in the root Web.config

<authentication mode="Forms">
<forms loginUrl="LoginPage.aspx">
<credentials passwordFormat="Clear">
<user name="wp" password=wp"/>
<user name="John" password="redrover" />

Authorization (directory-wise) in Secret/Web.config

<authorization>
<deny users="?" />
URL authorization to deny ? (anonymous) users.

Programming Forms Security

PublicPage.aspx
void OnViewSecret (Object sender, EventArgs e)
{ Response.Redirect ("Secret/ProtectedPage.aspx"); }
LoginPage.aspx.

void OnLogIn (Object sender, EventArgs e)

{ if(FormsAuthentication.Authenticate(UserName.Text, Password.Text))

FormsAuthentication.RedirectFromLoginPage (UserName.Text, false);

// true for persistent cookie
else Output.Text = "Invalid login";
}
System.Web.Security.FormsAuthentication.Authentic method returns true if the user
name and password are in the credentials section of Web.config.

Internal Works

ASP.NET creates an authentication cookie,

attaches it to the outgoing response, and
redirects the user to the page that he or she
originally requested. The lifetime of a persistent
cookie is independent of the browser session.
Authorization is applied on a directory-bydirectory basis. Web.config files in each directory
specify exactly how the files are to be protected.
ASP.NET checks to see whether a valid
authentication cookie is attached to the request. If
the cookie exists, ASP.NET extracts identity
information. If the cookie doesnt exist, ASP.NET
redirects the request to the login page.

Real-World Forms Authentication

Forms2
Forms3

Real-World Forms Authentication (Forms2)

Storing user names and passwords in a database

(MySQL).
Creating the database, creating the users table and
adding users.

Logo on to winserv1.
Start->All Programs->My SQL->My SQL Query Browser.
Server Host: db1.cs.uakron.edu
Port 3306
Username: yourLoginID
Password: yourPassword for MySQL
Default Schema: your DB name
File->Open Script:
T:\Xiao\Windows Programming\Examples\C10\MySQLTable-Creation\Weblogin.sql
Execute!

Real-World Forms Authentication

Weblogin.sql
CREATE TABLE users
(
username varchar(32)
password varchar(32)
role
varchar(32)
);

NOT NULL,
NOT NULL,

INSERT INTO users (username, password, role) VALUES (dev', dev', 'Developer');
INSERT INTO users (username, password, role) VALUES (mgr', mgr', 'Manager');

AddUsers.sql
INSERT INTO users (username, password, role) VALUES ('wpd1', 'wp2009', 'Developer');
INSERT INTO users (username, password, role) VALUES ('wpd2', 'wp2009', 'Developer');

Deploy Forms2 on Winserv1

Create a web application directory.
C:\inetpub\wwwroot\xiaotest\Forms2
You need to have admin privilege.
On winserv1, use an existing web application directory
already created for you.
Copy everything from
T:\Xiao\Windows Programming\Examples\C10\Forms2
to the above directory
(C:\inetpub\wwwroot\xiaotest\Forms2)

Deploy Forms2 on Winserv1

To access
http://winserv1.cs.uakron.edu/xiaotest/Forms2/PublicPag
e.aspx, and
http://winserv1.cs.uakron.edu/Examples/C10/Forms2/Pu
blicPage.aspx can be viewed by anyone.
http://winserv1.cs.uakron.edu/xiaotest/Forms2/Secret/Pro
tectedPage.aspx and is available only to authenticated
users (dev/dev).

Deploy Forms2 on Winserv1

Authenticated users means anyone who has
successfully logged in through LoginPage.aspx.
Valid users are stored in the database.
The cookie containing the authentication ticket is a
session cookie, destroyed when the browser is closed.
You are not prompted for password again during a
session.

Real-World Forms Authentication

LoginPage.aspx
Credential Matching:
SQL:
select count(*) from users where username = dev' and pwd = dev;
It returns 0 if no matching credentials found.

MySQL notes:
(1) count (*) works for SQL Server but not MySQL due to the extra space
after count.
(2) password is a keyword in MySQL (not SQL Server), therefore cant be
used as database column names.
(3) ExecuteScalar returns Int64 for count query.

FormsAuthentication.RedirectFromLoginPage (UserName.Text,
Persistent.Checked);
Persistent authentication cookie: be able to get back without logging in
again, even after shutting down.

Authentication Cookie Lifetime

Session authentication cookie.

Machine.config
<forms ... timeout="30"> // 30 minutes
Web.config
<forms loginUrl="LoginPage.aspx" timeout="10080" /> // 7 days

Proramming cookies.
HttpCookie cookie =
Response.Cookies[FormsAuthentication.FormsCookieName];
cookie.Expires = DateTime.Now
+ new TimeSpan (7, 0, 0, 0); // 7 days

Removing cookies as a user.

IE->Tools->Internet Options->General->Delete Cookies.
Netscape->Tools->Cookie Manager->Manage stored cookies->Remove all.
FireFox->Tools->Clear Recent History: check Cookies.

Forms Authentication
Role-Based Security

Forms Authentication and Role-Based Security (Forms3)

Use role membership to allow only some authenticated

users to view Secret/ProtectedPage.aspx.

Without roles:
Deny all unauthenticated users.
<deny users="?" />
Deny all users (users=*) except John and Alice.
<allow users="John, Alice" />
<deny users="*" />
Allow all except Jeff, Bob, and Mary:
<deny users="Jeff, Bob, Mary" />
<allow users="*" />
<allow> and <deny> are order-sensitive.
ASP.NET will stop at <= *> and ignore any statements
that appear after it.

Forms Authentication and Role-Based Security (Forms3)

With roles:
Users table has a field named role that stores each users role
(group) membership.
Grant Developer access to Secret.
<allow roles="Developer" />
<deny users="*" />
Map the roles to user accounts so that ASP.NET can determine
whether the requestor is a developer or not.
Place the mapping in the AuthenticateRequest event handler
(invoked at the beginning of every request).
Can be done in a custom HTTP module or in Global.asax.

http://winserv1.cs.uakron.edu/Examples/C10/Forms3/PublicPage.aspx
http://winserv1.cs.uakron.edu/xiaotest/Forms3/PublicPage.aspx
dev/dev/Developer can view ProtectedPage.aspx.
mgr/mgr/Manager cant.

Programming Role-based Authentication

Getting Information about Authenticated Users in Your

Code
ASP.NET stores user information in the HttpContext.User
property.
Access User through Page.Context.User or simply
Page.User, or HttpApplication.User.
The User property is of the type IPrincipal (an interface
defined in System.Security.Principal).
Implemented by the WindowsPrincipal class for Windows
authentication and GenericPrincipal class for other forms of
authentication (along with Windows authentication).
GenericPrincipal is a device for representing user identities
independent of the authentication protocol being used.
ASP.NET compares the role name in the GenericPrincipal to
the roles granted access through Web.config.
User.Identity contains some usefull properties:

Properties in User.Identity
Property

Description

AuthenticationType

Reveals which form of

authentication was used

IsAuthenticated

Reveals whether the user is

authenticated

Name

Reveals an authenticated users

name

if (User.Identity.IsAuthenticated) {
string name = User.Identity.Name;
}
Name is of the form domain-name\user-name for Windows authentication,
user-typed login for forms authentication.

Programming Authentication - Roles

Retrieve a users role and create a Principal for the user.
<%@ Import Namespace="System.Security.Principal" %>
<script language="C#" runat="server">
void Application_AuthenticateRequest (Object sender, EventArgs e)

HttpApplication app = (HttpApplication) sender;

if (app.Request.IsAuthenticated &&

app.User.Identity is FormsIdentity) {

FormsIdentity identity = (FormsIdentity) app.User.Identity;

// Find out what role (if any) the user belongs to

string role = GetUserRole (identity.Name);

// Create a GenericPrincipal containing the role name

// and assign it to the current request
if (role != null)
app.Context.User = new GenericPrincipal (identity,
new string[] { role });
}

Programming Authentication - Roles

string GetUserRole (string name)
{
MySqlConnection connection = new MySqlConnection
("server=db1.cs.uakron.edu;database=xiaotest;uid=xiaotest;pwd=wp2009;
allow zero datetime=yes)
try {
connection.Open ();
StringBuilder builder = new StringBuilder ();
builder.Append ("select role from users " +
"where username = \'"); builder.Append (name); builder.Append ("\'");
MySqlCommand command = new MySqlCommand (builder.ToString (),
connection);
object role = command.ExecuteScalar ();
if (role is DBNull) return null;
return (string) role;
}
catch (MySqlException) { return null; }
finally { connection.Close ();}
}

More on Forms Authentication

Multiple Roles
Coding:
app.Context.User = new GenericPrincipal (identity,
new string[] { "Developer", "Manager" });
Web.config
<allow roles="Manager, Developer" />
<deny users="*" />

Configure subdirectories in root Web.config

<location path="Secret">
<system.web>
<authorization>
<allow roles=" Developer" />
<deny users="*" />
</authorization>
</system.web>
</location>

More on Forms Authentication

Signing Out
<asp:Button Text="Log Out"
OnClick="OnLogOut" RunAt="server" />
<script language="C#" runat="server">
void OnLogOut (Object sender, EventArgs e)
{ FormsAuthentication.SignOut (); }
FormsAuthentication.SignOut( ): returns a SetCookie header, sets the cookies value to a null
string and sets the cookies expiration date to a
date in the past.

More on Forms Authentication

Attributes of forms element in Web.config:
Attribute

Description

Default

name

Name assigned to authentication cookies

.ASPXAUTH

loginUrl

URL of the login page

login.aspx

protection

Level of protection (validation and

encryption) applied to authentication
cookies

All

timeout

Lifetime of session authentication tickets in

minutes

30

path

Scope of authentication cookies

The protection attributes specifies the desired level of protection for the
authentication cookies. All instructs ASP.NET to both encrypt and validate
authentication cookies.

Encrypt and Validate Authentication Cookies

Validation works by appending the
machineKey elements validationKey to the
cookie, the resulting value is hashed, and the
hash is appended to the cookie. When the
cookie is returned in a request, ASP.NET
verifies that it wasnt tampered with by
rehashing the cookie and comparing the new
hash to the one accompanying the cookie.
Encryption works by encrypting the cookie
hash value and allwith machineKeys
decryptionKey attribute.

Encrypt and Validate Authentication Cookies

Validation consumes less CPU time than
encryption and prevents tampering. It does not
prevent someone from intercepting an
authentication cookie and reading its contents.
To validate but not encrypt authentication
cookies:
<forms ... protection="Validation" />
Encryption provides insurance against
tampering and prevents the cookies contents
being read.
To encrypt but not validate cookies:
<forms ... protection=" Encryption " />

Encrypt and Validate Authentication Cookies

To disable both:
<forms ... protection="None" />
Encrypted cookies cant be read or altered, but can be stolen and used illicitly.
Time-outs are the only protection.
The most reliable way to prevent someone from spoofing your site with a stolen
authentication cookie is to use an encrypted communications link (HTTPS).
<forms ... loginUrl="https://www.wintellect.com/login.aspx" />
This assumes the server supports HTTPS and Login.aspx is stored in a
directory configured to use HTTPS.
Caveat

Emptor: ASP.NET does not protect HTML pages.

Just renaming .html to .aspx to protect it.
http://winserv1.cs.uakron.edu/xiaotest/Forms3/PublicPage.aspx
http://winserv1.cs.uakron.edu/xiaotest/Forms3/Secret/ProtectedPage.aspx
http://winserv1.cs.uakron.edu/xiaotest/Forms3/Secret/Calc.html
http://winserv1.cs.uakron.edu/xiaotest/Forms3/Secret/Calc.aspx

Windows
Authentication

Windows Authentication

It maps incoming requests to accounts on the

Web server or in the Web servers domain.
Serve content to a well-defined populace
(intranet.)
Requires no programming. Authentication is done
by the system.

Windows Authentication

Dont use it to generically expose content to all

comers over the Internet.
Windows authentication on the front end is
typically paired with ACL authorization
(administrator controlled) on the back end.
Can be also used with URL authorization
(programmer controlled).

Windows Authentication

Categories of Windows Authentication:

Basic authentication: login, piggyback on HTTP.
Digest authentication: login, piggyback on HTTP.
Integrated Windows authentication: Windows login.
SSL client certificates: limited primarily to intranet.

Basic Authentication
An HTTP standard (documented in RFC 2617,
ftp://ftp.isi.edu/in-notes/rfc2617.txt.)
How it works:
For the first time access, the Web server returns a 401
status code indicating what type of authentication is
required.
HTTP/1.1 401 Access Denied
Server: Microsoft IIS-5.0 . . .WWWAuthenticate: Basic realm="uakron.edu"
A realm is a logical security space that encompasses
all or part of a web site.
The browser pops up a dialog box (not part of your
ASP generated HTML) asking for a user name and
password.

Basic Authentication

It concatenates the user name and password to

an encoded string in the Authorization header of
an HTTP request.
Authorization: Basic SmVmZjppbWJhdG1hbg==
The browser includes the same Authorization
header in each future request to the same realm.
IIS maps the user name and password to an
account on the web server, producing an access
token.
The access token is used to perform ACL-based
security checks.

Basic Authentication

Pros of Basic Authentication:

It works with virtually all browsers.
Easy to use.
It works well with firewalls.

Cons of Basic Authentication:

Nothing prevents the HTTP requests with Authorization
header from being intercepted and used to gain access
to your server.
Some users consider pop-up dialogs intrusive.
Better to be used with HTTPS, not HTTP.

Digest Authentication
Documented in RFC 2617 (ftp://ftp.isi.edu/innotes/rfc2617.txt).
Similar

to basic authentication.

The

browser solicits a user name and password by

popping up a dialog box. The server uses the credentials to
assign an identity to the request.
The

big difference between basic and digest

authentication is that digest doesnt transmit clear-text
passwords. Instead, it passes an authentication token that is
cryptographically secure. As a result, you can use it over
unencrypted channels without fear of compromising your
Web server.

Digest Authentication Cont.

When the client first requests a resource guarded by

digest authentication, the server returns a 401 error and
includes a noncea string of 1s and 0sin a HTTPAuthenticate header.
The browser responds by prompting for a user name and
password. It then transmits the user name back to the
server, along with a hash or digest computed from the
combined user name, password, and nonce.
The server authenticates the request by performing its
own hash on the user name, password, and nonce. The
password the server uses doesnt come from the client; it
comes from the server itself.
If the hashes match, the user is authenticated.
Its also compatible with proxy servers.

Digest Authentication Cont.

Pros of Digest Authentication:

Easy to understand.
Works with firewalls.
Far more secure over ordinary HTTP than basic
authentication.
Cons of Digest Authentication:
Uses pop-up dialog boxes for user names and
passwords.
Doesnt support delegation (the ability to make a call
from one machine to another and have the call execute
as the caller on the remote machine) on Windows
2000 servers.
Digest authentication is not widely used.

Integrated Windows Authentication

Uses Windows login credentials to authenticate users.

Identifies the user (on the server) by using that persons

login identity on the client.

The browser asks for a user name and password only if

the user does not have a valid account on the server.

The client and server negotiate a trust in a series of

exchanges that involve user names, domain names,
nonces, and hashes.

All done automatically by the OS on the server and the

browser on the client.

Integrated Windows Authentication

Pros of Windows Authentication:

Doesnt force users who have already logged in to
Windows to provide a user name and password again.
Secure, even over unencrypted channels, because
plain-text passwords are never transmitted.
Good for in-house use and behind firewalls.

Cons of Windows Authentication:

Cant work through firewalls.
Proprietary to Windows and Internet Explorer.
Not for general Internet use.

Windows Authentication / ACL Authorization in Action

CorpNet

T:\Xiao\Windows Programming\Examples\C10\Basic

About CorpNet
It models a simple intranet-type application (e.g. an internal
application for a company).
It uses Windows (basic) authentication and ACL authorization
to restrict access to its pages.
Code:
General.aspx provides general information.
Salaries.aspx lists the salary.
Bonuses.aspx lists the bonuses.
Anyone in the company can view General.aspx, only selected
individuals can view Salaries.aspx and Bonuses.aspx.

Windows Authentication / ACL Authorization in Action

Deployment on your home computer:

Create your own directory:
C:\inetpub\wwwroot\yourLoginID
Copy
T:\Xiao\Windows Programming\Examples\C10\Basic

To
C:\inetpub\wwwroot\yourLoginID
Make the directory a web application.
Access the aspx pages (as an anonymous user):
http://localhost/yourLogin/Basic/general.aspx
http://localhost/yourLoginI/Basic/salaries.aspx
(access accepted but no salary entry).
http://localhost/yourLoginID/Basic/bonuses.aspx

Windows Authentication and

Anonymous Access (No Authorization Control)
Use Web.config in the root directory to set the authentication mode.
<configuration>
<system.web>
<authentication mode="Windows"/>
</system.web>
</configuration>

Access CorpNet as an anonymous user on winserv1

http://winserv1.cs.uakron.edu/xiaotest/basic/general.aspx
http://winserv1.cs.uakron.edu/xiaotest/basic/salaries.aspx
http://winserv1.cs.uakron.edu/xiaotest/basic/bonuses.aspx

Access CorpNet as an anonymous on your own computer

http://localhost/xiaotest/basic/general.aspx
http://localhost/xiaotest/basic/salaries.aspx
http://localhost/xiaotest/basic/bonuses.aspx

Basic Authentication, No Authorization Control

(on your own computer)
Use Control Panel -> Administrative Tools -> IIS manager
to configure the application to require authentication and to
disallow anonymous access.

In IIS Manager, find and click on Basic application.

(WINSERV1\Sites\Default Web Site\xiaotest\Basic)

In the IIS pane, double-click on Authentication

Disable Anonymous Authentication

Enable Basic Authentication

http://winserv1.cs.uakron.edu/xiaotest/basic/salaries.aspx

Login prompt provided by the browser.

User Name: cs\xiaotest, Password: ???

No salary information is available for xiaotest

Modify salaries.aspx to enter a salary for xiaotest

ACL Authorization

Change the permissions on Salaries.aspx and Bonuses.xml to

deny CS\xiaotest read privilege.
Right-click on the file -> properties ->Security->Edit->Add
location: CS
object name: xiaotest
ok
Deny: Read
ok; ok
(advanced for inheritance)
If you dont see the security tab in the properties window:
right-click on Start, open, tools, folder options, view, advanced
settings, files and folders, uncheck Use simple file sharing.
Tests:
http://winserv1.cs.uakron.edu/xiaotest/basic/general.aspx (ok)
http://winserv1.cs.uakron.edu/xiaotest/basic/salaries.aspx (denied)
http://winserv1.cs.uakron.edu/xiaotest/basic/bonuses.aspx (ok)

Security Inside
Note: ACL Control is set per user and per file
manually.
User: xiaotest access denied for Basic/Bonuses.xml

Why you can still read Bonuses.xml through

Bonuses.aspx?
IIS checks the login and passes access token to
ASP.NET if the login is correct.
ASP.NET makes ACL checks using the callers
identity against the ASPX files to be accessed and
passes access token to the application (ASPX files).
Web applications run inside ASP.NET which is run
by user ASPNET, and can programmatically access
anything that ASPNET is allowed to access.

Impersonation
To execute a request using the access token
provided by IIS.
Add the following in Web.config
<identity impersonate="true" />
The identities assigned to the ASP.NET worker
process and to the requests that it executes
play crucial roles.
After IIS 6.0, W3WP.exe connects to
aspnet_isapi.dll.

Impersonation
Impersonation makes web applications run as the caller.
Any programmatically
access will subject ACL check using the callers identity.
<configuration>
<system.web>
<authentication mode="Windows" />
<identity impersonate="true" />
</system.web>
</configuration>
Start a new browser
http://winserv1.cs.uakron.edu/xiaotest/basic/bonuses.aspx
500 - Internal error occurred.
The following does work on winserv1
IIS Manager, double-click on the Basic application.
In the IIS pane, double-click on Authentication
Enable ASP.NET Impersonation

CorpNet demonstrates several important principles for

using Windows authentication:
Windows authentication is enabled in ASP.NET by including an
<authentication mode=Windows /> statement in Web.config. It
has the scope of the Web.config at application level (not page
level).
ASP.NET applications that use Windows authentication can
prevent users from viewing files by using ACLs to deny access to
selected security principals.
ASP.NET applications that use Windows authentication must
enable impersonation if they want resources protected by ACLs to
be protected from programmatic accesses by code executed
within a request.
ASP.NET applications that use Windows authentication can
personalize content for individual users by reading user names
from Page.User.Identity.Name.
ACL authorization requires system administrators of the web
server to manually set the security control for each application
(even each page/file).

Windows Authentication and URL Authorizations

Change web.config to use URL authorization so the programmer

can set the security control (per directory not per file).
<configuration>
<system.web>
<authorization>
<deny users="CS\YourUnixID" />
<allow users="*" />
</authorization>
</system.web>

</configuration>

CS\YourUnixID" is not allowed to access any APSX pages in Basic.

Note only one \ after CS.
Based on string names not Windows security IDs (SIDs).
The deny statement needs to be before the allow statement in the
above case.
URL authorizations usually not used with Windows authentication.

Windows Authentication and Role-Based Security

Role-based security restricts access based on roles (groups) that the users belong
to. For ACL authorizations, control the access by giving permission to the selected
groups.
For URL authorizations, use Web.config to restrict groups.
e.g. add the WP group and a test2 user in the group.
Start->Settings->Control Panel->User Accounts->Advanced->Advanced->Groups
Action->New Group
Start->Settings->Control Panel->User Accounts->Advanced->Advanced->Users
test2->properties->Member Of->Add
Action->New Users
Web.config
<authorization>
<allow roles=ServerName\WP" />
<deny users="*" />
</authorization>
Deny test but allow test2.
Allow should be first here. (* should be at the end).

Summary
Security
Authentication
Forms
Windows
Basic, Digest, Integrated, SSL Client Certificates
Passport
Authorization: ACL, URL
IIS/ASP.NET Server-Side Security Processing
Application Security Scenarios
Encryption and Validation
Database Based Authentication
Role Based Authorization
Anonymous Login
Impersonation
Realm