ASP.Net Security
Chapter 10
Jeff Prosise’s Book
Authentication
• To ascertain the caller’s identity
– Windows authentication
– Forms authentication
– Passport authentication
• Windows authentication: Here, IIS does the
authentication and makes the caller’s identity
available to ASP.Net (via a token)
– Most suitable when everyone that uses the
application can login to the local machine
– Uses the built-in security features of the OS
Authentication (cont.)
• Passport authentication:
– Passport serves as a front-end to a large
group of users registered with Microsoft
Passport
– Such users can be authenticated anywhere
on the Internet by applications that present
long credentials to Passport.
– If Passport validates them, it returns an
authentication ticket to the application; that in
turn stores it as an encoded cookie
Authentication (cont.)
• Forms authentication
– Relies on login forms in web pages to authenticate
users
– In an e-commerce application such as e-bay’s
bidding, windows authentication is not viable since it
is impractical to create windows accounts for all
millions
– In web.config, we set <authentication mode = “Forms”
/>
– Other modes are: None, Windows, and Passport
Authorization
• Determines what resources a user can
access
• ASP.Net supports:
– ACL authorization or file authorization---e.g.,
using NTFS file system’s ACL
– URL authorization---relies on configuration
directives in web.config using the
<authorization> element
– Authorization link
Windows Authentication
• Maps incoming requests to accounts on the web server
• Used to serve a well defined user group that may be controlled
through windows accounts
– Basic authentication: transmits a user name and password in each
request; IIS maps them to an account on the web server and generates
a token.
• Suppose a web page is placed in the virtual directory
• Suppose IIS is configured to disallow anonymous access to that directory
and to require basic authentication
• When a user attempts to access it for the first time (via HTTP request, a
401 is returned indicating that it requires basic authentication
• The user’s browser then prompts the user for windows user name/password
• Problem: User name/password sent in plain text between the browser and
the web server with each request; user needs a windows account
– Digest authentication: User name/password are sent as an encrypted
token with each request
Windows Authentication (Cont.)
• Integrated windows authentication:
With Integrated Windows authentication (formerly called
NTLM, and also known as Windows NT
Challenge/Response authentication), the user name and
password (credentials) are hashed before being sent
across the network. When you enable Integrated
Windows authentication, the client browser proves its
knowledge of the password through a cryptographic
exchange with your Web server, involving hashing.
IIS Security
• Internet Information Services---a web server
• IIS protects a server in four ways:
– Web applications are deployed in virtual directories that are
URL-addressable on the server. Remote clients cannot
automatically access files outside this directory.
– IIS assigns every request a token---a windows security principal;
OS and .Net check this token prior to allowing access
– It can enable/disable requests based on IP addresses and
domains
– Supports SSL and HTTPs
– IIS supports four types of authentication:
•
•
•
•
Basic authentication (user name/password)
Digest authentication (user name/password)
Integrated windows authentication
SSL client authentication
Forms Authenticatrion
• Authenticates a user by asking the user to type
credentials (e.g., user name/password) into a web form.
• Entries in web.config can identify login page
• When a user accesses for the 1st time, ASP.Net redirects
the user to the login page.
• If the login is successful, ASP.Net issues a ticket in the
form of a cookie and redirects the user to the page
originally requested.
• The cookie enables the user not to login everytime.
Lifetime of a cookie is dictated by your application.
Example Application with Forms
Authentication
• Application contains two pages:
– PublicPage.aspx --- viewed by anyone
– ProtectedPage.aspx --- available only to
authenticated users (validated by login page)
• LoginPage.aspx---asks for a user name
and a password
• Web.config---stores valid user names and
passwords
PublicPage.aspx
<html>
<body>
<h1>Public Page</h1>
<hr>
<form runat="server">
<asp:Button Text="View Secret Message" OnClick="OnViewSecret"
RunAt="server" />
</form>
</body>
</html>
<script language="C#" runat="server">
void OnViewSecret (Object sender, EventArgs e)
{
Response.Redirect ("Secret/ProtectedPage.aspx");
}
</script>
LoginPage.aspx
<html>
<body>
<h1>Please Log In</h1>
<hr>
<form runat="server">
<table cellpadding="8">
<tr>
<td>
User Name:
</td>
<td>
<asp:TextBox ID="UserName" RunAt="server" />
</td>
</tr>
<tr>
<td>
Password:
</td>
<td>
<asp:TextBox ID="Password" TextMode="password"
RunAt="server" />
</td>
</tr>
<tr>
<td>
<asp:Button Text="Log In" OnClick="OnLogIn"
RunAt="server" />
</td>
<td>
</td>
</tr>
</table>
</form>
<hr>
<h3><asp:Label ID="Output" RunAt="server" /></h3>
</body>
</html>
<script language="C#" runat="server">
void OnLogIn (Object sender, EventArgs e)
{
if (FormsAuthentication.Authenticate (UserName.Text,
Password.Text))
FormsAuthentication.RedirectFromLoginPage (UserName.Text,
false);
else
Output.Text = "Invalid login";
}
Web.config in the main directory
<configuration>
<system.web>
<authentication mode="Forms">
<forms loginUrl="LoginPage.aspx">
<credentials passwordFormat="Clear">
<user name="Jeff" password="imbatman" />
<user name="John" password="redrover" />
<user name="Bob" password="mxyzptlk" />
<user name="Alice" password="nomalice" />
<user name="Mary" password="contrary" />
</credentials>
</forms>
</authentication>
</system.web>
</configuration>
Web.config in the secret subdirectory (to
deny unauthenticated users)
<configuration>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Why is the earlier example not
realistic?
• Unreasonable to store passwords in clear
text
• Storing a large number of
names/passwords in Web.config is
unrealistic. Instead, store them in a
database.
• Modified Login.aspx is in the next few
slides
<%@ Import NameSpace="System.Data.SqlClient" %>
<html>
<body>
<h1>Please Log In</h1>
<hr>
<form runat="server">
<table cellpadding="8">
<tr>
<td>
User Name:
</td>
<td>
<asp:TextBox ID="UserName" RunAt="server" />
</td>
</tr>
<tr>
<td>
Password:
</td>
<td>
<asp:TextBox ID="Password" TextMode="password"
RunAt="server" />
</td>
</tr>
<tr>
<td>
<asp:Button Text="Log In" OnClick="OnLogIn"
RunAt="server" />
</td>
<td>
<asp:Button Text="Log In" OnClick="OnLogIn"
RunAt="server" />
</td>
<td>
<asp:CheckBox Text="Keep me signed in" ID="Persistent"
RunAt="server" />
</td>
</tr>
</table>
</form>
<hr>
<h3><asp:Label ID="Output" RunAt="server" /></h3>
</body>
</html>
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
<script language="C#" runat="server">
void OnLogIn (Object sender, EventArgs e)
{
if (CustomAuthenticate (UserName.Text, Password.Text))
FormsAuthentication.RedirectFromLoginPage (UserName.Text,
Persistent.Checked);
else
Output.Text = "Invalid login";
}
bool CustomAuthenticate (string username, string password)
{
SqlConnection connection = new SqlConnection
("server=localhost;database=weblogin;uid=sa;pwd=");
try {
connection.Open ();
•
•
•
•
•
•
•
•
StringBuilder builder = new StringBuilder ();
builder.Append ("select count (*) from users " +
"where username = \'");
builder.Append (username);
builder.Append ("\' and cast (rtrim (password) as " +
"varbinary) = cast (\'");
builder.Append (password);
builder.Append ("\' as varbinary)");
•
•
SqlCommand command = new SqlCommand (builder.ToString (),
connection);
•
•
•
•
•
•
•
•
•
•
•
int count = (int) command.ExecuteScalar ();
return (count > 0);
}
catch (SqlException) {
return false;
}
finally {
connection.Close ();
}
}
</script>
New Web.config in main directory
<configuration>
<system.web>
<authentication mode="Forms">
<forms loginUrl="LoginPage.aspx" />
</authentication>
</system.web>
</configuration>
Authentication Cookie Lifetime
• Timeout value is controlled by:
– In Machine.config file:
• <forms … timeout=“30”>
– In local Web.config file:
configuration>
<system.web>
<authentication mode="Forms">
<forms loginUrl="LoginPage.aspx" timeout = “30”/>
</authentication>
</system.web>
</configuration>
Forms Authentication and Rolebased Security
• Previous example, all authenticated users
have access; what if we want to restrict
access to a few? (Here, * means all; ?
means unauthenticated users)
– In Web.config of the secret page:
<authorization>
<allow users = “John, Alice” />
<deny users=“*” />
</authorization>
• Alternately, deny access to Jeff, Bob, and Mary
explicitly.
<authorization>
<deny users = “?” />
<deny users = “Jeff, Bob, Mary” />
<allow users=“*” />
</authorization>
• Order sensitive statement execution
• Still not practical when a large number of users
are involved
• Solution: Role based control
Using role-based authorization:
Step 1
In Web.config file of the secret directory:
<configuration>
<system.web>
<authorization>
<allow roles="Manager" />
<deny users="*" />
</authorization>
</system.web>
</configuration>
Step 2: Mapping users to roles
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); //From DB
// 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 });
}
}
Multiple roles?
if (role != null)
app.Context.User = new GenericPrincipal
(identity,
new string[] { role });
The 2nd parameter is a string and hence could be:
new string[] { “Manager”, “Developer”});
In Web.config we can say:
<allow roles = “Manager, developer”/>
<deny users = “*”/>