Professional ASP.NET Security - Jeff Ferguson
.pdf
Chapter 7
Here is a simple event handler that we can add to Global.asax that will log each authentication to a text file:
public void WindowsAuthentication_OnAuthenticate(object sender,WindowsAuthenticationEventArgs e)
{
System.IO.FileStream fs = new System.IO.FileStream(Server.MapPath("") + @"\authentications.txt", System.IO.FileMode.Append);
string ip = e.Identity.Name + " "
+e.Context.Request.UserHostAddress.ToString()
+", ";
byte[] b = System.Text.Encoding.ASCII.GetBytes(ip);
fs.Write(b,0,b.Length);
fs.Close();
}
First we create a FileStream to write to a file in our application folder:
System.IO.FileStream fs = new System.IO.FileStream(Server.MapPath("") + @"\authentications.txt", System.IO.FileMode.Append);
We then build a string by extracting the username and the source IP address for the request:
string ip = e.Identity.Name + " "
+e.Context.Request.UserHostAddress.ToString()
+", ";
Note that we use the WindowsAuthenticationEventArgs object, e, to access the objects we need to access to get the information for the log. We use e.Identity to access the WindowsIdentity object of the authenticated user (this is the one that is added to Context.User), We use e.Context.Request to access the HttpRequest object for the request.
Finally, we write the text to the file and close it:
byte[] b = System.Text.Encoding.ASCII.GetBytes(ip);
fs.Write(b,0,b.Length);
fs.Close();
Each time the Windows authentication module performs authentication (once per request), this event handler will write the username and source IP address into a file.
Note – This method of logging is only really suitable for an application that expects a very low amount of usage. Higher trafficked systems would use a more sophisticated logging system. However, this example does show how such systems can be linked into the Windows authentication module.
136
Windows Authentication
Summary
In this chapter we have looked at how we can use Windows authentication to tie our authentication to that done by IIS. We have seen:
How to set IIS up to perform Basic, Digest, or Integrated Windows authentication
How to configure ASP.NET for Windows Authentication
How we can access the details of the user authenticated by IIS
How we can customize Windows authentication
137
Chapter 7
138
NET Passport
The .NET Framework includes a concise authentication model enabling fine-grained control of authentication to particular areas of a web site or particular resources. Unlike the authentication models deployed in older ASP web applications, authentication is no longer governed by file or directory-level access (a model in which access to resources was protected by the web server or the application), but is now part of the core ASP.NET model, and can be easily integrated within an application without having to write excessive quantities of security code.
In this chapter, we're going to investigate the way in which we can implement authentication solutions using .NET Passport. Formerly, it was difficult to avoid writing an authentication application without having to use techniques that granted access to specific resources, as requested by the user. This would normally involve writing small chunks of ASP script - within the application - to check file authorization.
The only real alternative to being authorized to a particular resource before the request is processed by the web server is to write an ISAPI DLL, since ISAPI programming can handle pre-processing before the request is answered by the web server. ISAPI enables the developer to use the identity of the logged in user, checking a list of resources from a storage solution - such as a SQL Server database or Active Directory - and determining whether the user has the right to see the requested resource before the web server serves the actual resource (ISAPI is explained in more detail later in this chapter).
Within the .NET Framework, there are a whole series of tools, which mean that we no longer have to spend a lot of time piecing together authentication and authorization code, and .NET Passport is completely integrated with these features.
.NET Passport is a single sign-in authentication system from Microsoft, which uses common web protocols including cookies and HTTP Redirects to log the user into any site that supports .NET Passport. In this chapter we focus on implementing and programming .NET Passport (which we will also refer to simply as 'Passport' throughout this chapter).
Over the course of this chapter, we'll look at the following topics:
Q What Passport is
Q The advantages of using Passport authentication over other authentication schemes Q How Passport works
Q Using Passport from ASP.NET applications Q Customizing Passport authentication
Passport is a key part of the integrated authentication model that we can utilize within an ASP.NET application. Before we look at Passport in any more detail, however, we need to decide which type of authentication scheme we want to implement. Initially, we'll look briefly at the various types of authentication that can be used within an ASP.NET application, and at the circumstances that would best suit the different types of authentication. After this, we'll discuss some of the reasons we'd want to implement .NET Passport on our site, and some of the problems we may subsequently face.
Why Use Passport Authentication?
For many purposes it could make sense to avoid having to look after authentication issues ourselves. This is where .NET Passport might be useful. If we use an authorization process that holds user details outside our application, it would cut down on the risk of user ids or passwords being compromised (assuming the process we choose is secure). If we use .NET Passport, Microsoft becomes responsible for the management and storage of usernames and passwords, and there is one less issue - and arguably the most important issue - that we have to worry about in the creation and maintenance of our site. This would also mean that there is less administration, as accounts are created, deleted, and updated through the .NET Passport server.
This is what .NET Passport is all about. It is an integral part of the overall .NET strategy, enabling centralized storage of user information and authentication using common web protocols such as HTTP GET redirects and client-side cookies. It also results in seamless integration across multiple web sites, as users will only need one username and password for all sites that implement .NET Passport. This has the following advantages:
Q Users may only need to log in once per browser session.
Q Users would not need to remember a collection of distinct usernames and passwords for a whole series of sites.
Q Our site would immediately inherit all .NET Passport account holders as potential users -registration is frequently a deterrent to gaining a large user base, so most sites collect the minimal registration details required to build up a user identity. .NET Passport allows this process to be skipped, as any site that implements .NET Passport would be able to immediately identify the user and create a profile for the first time user without any interactive form content being filled in by the user.
a We would immediately know who our users are (so long as they have elected to share information with us). Information sharing can allow the web site to get the user profile without the user having to enter information, or can enable pre-population of web forms.
140
.NET Passport
Q Our site would inherit all the benefits of using .NET Passport, potentially being able to deliver .NET Alerts (real-time or delayed alerts delivered to a variety of devices and applications -only available to logged on .NET Passport user) via Windows Messenger, or to a mobile device using a Microsoft-provided gateway.
However, this isn't everybody's cup of tea. .NET Passport would be subject to the usual pitfalls of any centralized service:
Q If the Passport server crashes or is subject to malicious attacks then users can no longer log into our site.
Q There is a trust issue: are we prepared to trust Microsoft to manage our user data in a way that we would wish?
Q Should we lock ourselves into a particular vendor's authentication mechanism? Q Will our users be prepared to submit personal information to a central repository?
These are just a few of the issues that are involved in the take-up of Passport, as well as the financial implications! We should bear in mind that Passport offers us a complete solution here without all the difficulties we might face in implementing our own authentication solution. In some instances, a .NET Passport login will work just as smoothly as a Windows login through a web browser (on an intranet).
How does .NET Passport Work?
So how does .NET Passport work? At heart, it relies on a combination of HTTP redirects and cookies. Each web server implementing .NET Passport must have several pieces of server software to enable it talk to .NET Passport and enable it to handle all .NET Passport cookies. The client application must be able to process, store and retrieve cookies to be Passport-aware: URL rewriting is not currently supported . When a user logs in to a Passport-enabled web site, a number of interactions occur between the user, the Passport-enabled web site, and .NET Passport, as follows:
1 . The user requests a particular page from the .NET Passport-enabled web site.
2 . An HTTP 302 redirect is sent to the user's browser with the location header directing it to the URL http://current-login.passport.com. At the Passport site, the user will be presented with an HTML form login page.
3 . Successful entry of the details into the login page will result in the user having a cookie set for the .NET Passport domain (passport.com). This will be the binding mechanism for the Passport session, enabling subsequent requests to be authenticated by .NET Passport without the user having to log in again.
4 . An HTTP 302 redirect then occurs to a return URL within the Passport-enabled web site. At this point the user will also have a cookie set for the domain of the Passport-enabled web site.
These steps are shown in the following diagram:
.NET Passport-enabled
Website
This is not an overly complex interaction of redirects and cookies, and can provide a seamless login sequence. When a user logs into a Passport-enabled site, a cookie will be set for both the Passport domain (passport. com) and the Passport-enabled site domain (it is important to understand that a browser will only send cookies to the web server that correlates the cookie domain with the domain used in the address bar of the browser - this ensures that only the correct parties see cookies applicable to their site, and are only able to set cookies on a browser that correlate with their domain).
The user can then request a page from another Passport-enabled site. The login mechanism will redirect the user to http://current-login.passport.com. The Passport Server at this location will automatically pick up the cookie previously set (for the .NET Passport domain - passport.com) and will redirect the user back to the Passport-enabled site, so that the user will not have to enter credentials again. (Until, that is, the ticket within the cookie expires. By default, this is four hours, but is configurable using the tools described later in this section. After this time, a new login will have to occur, and another cookie -with a valid ticket - will be set on the client machine.)
The .NET Passport Cookie
The .NET Passport cookie contains some user details, which can be retrieved by the Passport-enabled site if the user gives permission for the site to do so. Each cookie contains both encoded (compressed) and encrypted information on the user's profile and ticket.
Profile information is also carried in the cookie so that names, e-mail addresses, and supplementary information, such as occupation and date of birth, can be obtained by the Passport-enabled web site (although this is available only if the user has chosen to enter and share this data). One obvious benefit of this is that we might offer the user pre-populated forms. It is not possible for users to choose to allow only some sites to see this information, nor is it possible for the user to permit only certain information to be accessed: it's currently an all or nothing approach.
142
.NET Passport
implementing .NET Passport
Now that we have a general idea of how .NET Passport works and what it does we'll discuss how to implement it on our site. To utilize .NET Passport is quite straightforward, but before starting, we should make sure that we have all the following things in place.
Q A machine connected to the internet with a corresponding DNS name (although it will work with an IP address, it is not recommended).
Q A web server - preferably IIS 5 or above, but other web servers are supported (such as Apache). As this book is about ASP.NET security, we'll use IIS 5.
Preparing for .NET Passport
Before we register an application for .NET Passport, we'll first put together a very basic skeletal application. We'll build on this as necessary.
Q Create a simple ASP.NET Web Application using C#.
G Add two blank pages to the project. We'll use one to contain the code to log in to .NET Passport, and the other to contain code that will delete .NET Passport cookies.
Without further ado, let's look at how we would register this application to use Passport.
The code download for this book contains a simple Passport Web application, which may be used as a basis for experimenting with and testing Passport. Of course, you will have to register this as a Passport site before most of the functionality will work properly.
Registering a .NET Passport Application
We register our site at http://www.netmyservicesmanager.com. Initially, select the Create New Application.
Note that you will have to have already registered a personal account with .NETPassport in order to log on.
On the Application Properties page, we must give certain information about our application.
We must choose the type of environment. The two possible values for this are the development/testing environment, and production environment (by default, this will be a development/testing environment). Throughout this chapter, we'll use the development environment. However, towards the end of the chapter, we'll look at how to roll our application out into a production environment.
We also need to select a specific type of Passport to use, and select an operating system. The three basic types of Passport are:
Q .NET Passport Single Sign-In
Q Kids Passport
Q .NET Passport Express Purchase
We will use the .NET Passport Single Sign-In.
We have to provide information about, among other things:
Q Our web site title
Q Our domain name
Q Our production domain name
Q Our default return URL
In the code download for the book, you will find all the files necessary to construct a basic web application that uses Passport authentication. If we use these files to register to use .NET Passport, creating our application with references to localhost, we would enter the following URLs in the Passport registration process:
Q Production domain name (localhost)
a Default return URL (http://localhost/SecurePassportApp/login.aspx)
Q Privacy policy URL (http://localhost/SecurePassportApp/privacy.aspx)
Q Co-brand Image URL (http://localhost/SecurePassportApp/cobrand1 .aspx)
Q Co-brand Instruction text (Login to the Secure Passport App here)
Q Cookie expiry URL (http://localhost/SecurePassportApp/cookieexpire.aspx)
Q Logout URL (http.V/localhost/SecurePassportApp/logout.aspx)
The production domain name is needed to find a return path to your server after every Passport redirect request returns to set cookies.
In this instance we can use localhost to test the .NET Passport site, as the browser is redirected to the local host - the machine we're browsing from - which also means that we can run the web application in debug mode and step the through the authentication code.
The default return URL specifies a page within the site to which all traffic will return to (this can be overridden in a variety of ways, as we will see later).
A privacy policy URL specifies a page informing the user of the level of privacy on the site and explaining data collection and storage policies. This should ideally be reviewed by a lawyer - Microsoft recommends a company called eTrust - details of which are given on the Passport web site.
As we will see later, P3P headers are used to define privacy. P3P is explained towards the end of the chapter.
The co-brand image URL is used by Passport to present a brand image when the user is redirected to the .NET Passport URL. This will appear in conjunction with the other .NET Passport image branding on the Passport login page.
Installing the Key
Traffic between our web server and the .NET Passport server is encrypted using a shared encryption key. This has to occur if the data between client and server is to be kept secret. The key is needed to begin using .NET Passport on our web server.
144
.NET Passport
Many sites would also use Secure Sockets Layer (SSL) technology to further encrypt communications between .NET Passport server and the Passport-enabled web site. However, this is not mandatory (it is nandatory if we use the express purchase option - but we will not be looking at this is this chapter).
Since any traffic between our web site and .NET Passport that uses SSL does so by requesting a secure login page on the .NET Passport server, this is resolved during the authentication process.
Let's look at how to get hold of and how to install the shared encryption key.
A key may be downloaded from the .NET My Services Manager site in the form of an executable file that installs the key to the hard drive of the web server. The key can then be used to encrypt and decrypt cookies sent by the .NET Passport server. As the only two parties to have possession of the key are the .NET Passport server and the web site, any cookie data intercepted will remain undecipherable.
To install the key, from the command prompt, we type the following command, using the /addkey switch:
>Partner_23653 l.exe |
/addkey |
The name of your file should be different from this - the initial registration process allotted the number 23693 to my site.
It should be noted that the key used is a Triple DES key, which - as a 168-bit key - gives an unprecedented level of encryption. It is called a Triple DES key as it is constituted by three 56-bit DES keys.
A key is applicable to only one internet site.
Installing the Passport SDK
After installing the key, we need to install the .NET Passport Software Development Kit (SDK). Installing the Passport SDK will enable an application to use Passport login features. It also enables us to use single method calls to log in to Passport - instead of having to write a system ourselves to perform cookie handling and redirects - and formats query string parameters for the Passport server.
The SDK is a suite of COM objects with which we can manage all aspects of using .NET Passport. These are absolutely necessary for using .NET Passport. Once installed, we can use the Passport classes within the .NET Framework (which act as wrappers for the COM layer installed by the Passport SDK). The .NET Passport classes are installed with the .NET Framework, but use COM Interop to invoke methods on the COM classes that are installed with the SDK.
The Passport SDK can be downloaded from:
http://msdn. microsoft, com/downloads/default. asp?URL=/downloads/sample.asp?url=/msdnfiles/027/001/885/msdncompositedoc.xml
The SDK is composed of two parts:
Q The object model, enabling us to abstract the .NET Passport 'protocol' to a few method calls.
Q The Passport Manager Administration utility, which enables the management of multiple sites and multiple keys.