Professional ASP.NET Security - Jeff Ferguson

xmlDoc .Load! "userlist .xml" ) ;

foreach) System. Xml . XmlNode nNode in xmlDoc. selectNodes ( " //USER" ) )

{

if (nNode. innerText==tmpPuidVal) Server .Transfer ( "accessrevoked.htm" ) ;

Assuming we have an XML file to contain the banned users that looks something like this:

<?xmlversion="1.0"encoding="utf-8"?><USERS> <USER>0003BAAD80 59472 6</USER>

</USERS>

users that appear in the banned list will be redirected to accessrevoked.htm

The method loads a simple XML resource file, which contains a list of users banned from the site (userlist .xml), and then redirects them (using server redirects) to a page telling them that they have been banned from the site.

The PassportAuthenticationEventArgs object in the method is used to provide context and identity information. The Context property returns a handle to the current HttpContext, which allows us to access ASP. NET objects such as Application, Session, and Cache, among others. The Identity property returns the Passportldentity object for the user being authenticated.

The HexPUID is available to every application, so it is good value to check against. The PUID value is freely available to all Passport-enabled web sites when login occurs, and its use in this fashion is recommended. An XML file can be used to store the PUID values of the banned users, or perhaps something a bit more robust like a SQL Server database table.

Using Passport Encryption and Compression

Passport encryption may be controlled programmatically, and this is done via a series of static methods, which map onto the Passport . Crypt COM object. In order to take advantage of this it's a good idea to have a basic understanding of encryption and compression.

One of the overriding factors in the development of .NET Passport was optimizing login speed. This would have involved anticipating the extent to which it would be used. With the huge volume of traffic that it receives, Microsoft didn't estimate this badly. At last count, the .NET Passport server dealt with 3.5 billion transactions per month.

It follows that for efficiency data should be compressed by a Passport-enabled web site to avoid the web server having to process too much data. So, before being sent in to the Passport server, each request should be compressed by the Passport-enabled site to avoid unnecessary network volumes.

As we will see shortly, for security, we may also encrypt information on the Passport-enabled web site, but this will increase the amount of information we have to pass through the server. This being the case, it is a good idea to compress any information after it had been encrypted.

156

.NET Passport

P3P is quite complicated to hand-code in XML so there are a variety of online wizards and downloadable applications that will create the P3P document for us. One such editor is P3P Policy Editor available at the IBM web site http://www.alphaworks.ibm.com/aw.nsf/techs/p3peditor. This application creates a P3P XML document and an HTML privacy policy for a web site.

P3P policies are deployed using the following path to a reference file /w3c/p3p.xml. This may contain all the security policy across a site. Alternatively, the P3P policy can use an HTTP header specifying the whereabouts of the policy file, in the following way:

Response.AddHeader "P3P", "policyref=""http://www.example.org/w3c/p3p.xml"""

Alternatively, we could put tokens in the P3P header that represent a compact policy (which must be sent with the cookie) allowing browser privacy settings to determine whether the user will accept the cookie or not. It should be noted that in some circumstances a P3P header (like the one below) should be included in the logout page for cookie deletion - otherwise, it is solely dependent on the user's privacy settings as to whether any action is taken.

based on trust through P3P headers and policies.

Creating a Production Website

Once all Passport specifications have been met (according to the guidelines issued on the .NET Passport site and in the documentation) the Passport application may be transferred from Development/Testing to Production.

To do this, we need to contact Microsoft by selecting the 'Certify your application so that it can be rolled into Production' option where Microsoft will assess whether your site follows all the Passport legal and UI guidelines. If I does, then .NET Passport integration can be rolled out as production web site.

There is an annual fee for using .NET Passport.

The Future of .NET Passport

.NET Passport is a key feature in the Microsoft .NET vision, and is being incorporated at all levels of Microsoft products. For instance, Windows XP currently has support for .NET Passport. Once logged into a Windows account, a user can automatically log in to any Passport-enabled resource online simply by logging in through their Windows XP account.

The login to .NET Passport is actually a feature of the new Winlnet API released by Microsoft and shipped with IE 6. Windows XP uses this new version of the Winlnet API. In this way .NET Passport has become a core part of Windows rather than an afterthought.

Not only can Passports be associated with a corresponding user account, they can also be used in the same capacity as a standard Windows account. There are options within the Windows Accounts Manager to be able to change .NET Passport Profile details over the Web.

159

One of the challenges to .NET Passport - being championed by Sun Microsystems and others - is the Liberty Alliance Single Sign-In System. This is based on a federated model, which means that there is no central control of resources. Microsoft is introducing .NET Passport Federation as a response to this.

The federated model will allow many organizations to 'partner1 with .NET Passport, and will provide a framework within which organizations wishing to provide web services can receive Passport users, or users within an organization not having a .NET Passport account can log in if they have an Active Directory account. Support for the federated model is planned for the final release of Windows .NET Server this year.

The other big push is for .NET Passport to support mobile devices. Indeed, the latest release (2.1 at the time of writing) supports a variety of clients and login methods from devices such as pocket PCs, stinger phones, and mobile phones. Mark-up languages supported include WML, HTML 3.2, HDML, and iMode. Features such as PIN number access are currently in use by Passport - especially useful for phone keyboards where it's easier to enter the phone number and a PIN number for login credentials than it is to enter an e-mail address and password. In future releases of .NET Passport, Microsoft intends to support biometric security.

Passport 3.0 will use Kerberos - a shared secret protocol developed by MIT and currently in its fifth version. Kerberos, named after the legendary dog which guards the entrance to the Kingdom of Hades, works by producing a ticket, or TGT (Ticket-Granting Ticket), which enables access to network services by allowing shared secrets to be known and encrypted within tickets. Tickets are granted by a KDC (Key Distribution Center) - in this case .NET Passport - and are validated by the network service being requested. In this way .NET Passport can grant tickets to .NET My Services, enabling access to them.

Another area where .NET Passport is integral (and introducing a growing phenomenon on the internet) is the adaptation of .NET Passport logins to enable real-time chat and video to be sent over the internet via Windows or MSN Messenger. .NET Passport is the means of user authentication - the .NET Presence service (part of the .NET My Services service suite) will take advantage of this to be able to determine the presence of a user: that a particular user is currently online and available to enable realtime alerts to be sent using .NET Alerts.

Summary

In this chapter we have investigated the following topics:

Q Why we should implement .NET Passport

Q Using and installing the Passport SDK and key

Q Programming using the Passportldentity class

Q Programming using the PassportAuthenticationModule Q Collecting profile information with .NET Passport

Q Understanding .NET Passport encryption and compression a The future of .NET Passport

160

Forms Authentication

If you have built web authentication systems using ASP 3.0 or similar technologies, you are probably familiar with the concept of 'cookie' authentication. This involves setting an HTTP cookie when a user's credentials are verified (when the username and password are checked). This cookie is then used on subsequent requests to identify the user.

Another popular way of achieving this result is to set a session variable for a user when their credentials are verified. This is essentially the same process: the user is linked to their server-side session through a cookie that identifies them.

ASP.NET includes an authentication module and associated classes that will do the hard work of cookie authentication for us so that we do not have to worry about the basic 'plumbing' of building such a system. In ASP.NET, this is called Forms Authentication because an HTML form is used for users to enter their credentials.

In this chapter, we will begin by looking at why we would want to use this type of authentication and how it works. We will then go on to look at the relevant classes from the .NET Framework class library.

Once we have taken an overview of the objects we will be using to implement forms authentication, we will look at a basic forms authentication scenario. We will then consider more advanced and unusual situations, showing how the flexibility of forms authentication allows us to implement the behavior we require.

Why Use Forms Authentication?

Cookie authentication is an attractive option for web developers for a number of reasons:

Q It keeps all code for authenticating users within the application

Q We have full control over the appearance of the login form

Q It works for users with any browser

Q It allows us to decide how to store user information

Let's look at each of these in turn:

Keeping Control of Authentication Code

Because forms authentication is implemented entirely within ASP.NET, we have complete control over how authentication is performed. We do not have to rely on any external systems, as is the case with Passport authentication. As we will see later in the chapter, we can heavily customize the behavior of forms authentication, adjusting it to suit our needs.

Controlling the Appearance of the Login Form

We have the same degree of control over the appearance of forms authentication as we do over its functionality. We can format the login form in any way we like, within the capabilities of HTML and the browsers in which we want to display it.

This flexibility in appearance is not available to the other authentication methods. Windows authentication requires a requester to be used to collect credentials, while passport authentication requires that the user leaves our site and visits the passport.com site to enter their credentials.

Working with a Range of Browsers

Forms authentication uses standard HTML as its user interface, so it can be used by all browsers (providing we format the HTML correctly). Because we can format the login form in any way we like, we can even use forms authentication with devices that do not use HTML, such as mobile devices. To do this, we would need to detect the browser being used and provide a form in the correct format for the device (for example WML for WAP mobile phones).

Storing User Information

Forms authentication stores user information in the web. conf ig file by default but, as we will see later in the chapter, we can store the information anywhere and anyhow we like - we just need to create some code to access the data store. For example, we may choose to store the information in a database.

This flexibility in the storage of user information means that we can control how user accounts are createc and administered. It also means that we can attach whatever information we like to user accounts.

Windows authentication requires that we set up windows user accounts for each user we want to authenticate. This is obviously a problem if we want to service large numbers of users or if we want to allow users to register themselves for a user account within our web application. If we want to store additional information about users, we have to do it separately and link it to the Windows user accounts.

164

Forms Authentication

rt authentication requires users to have passport accounts and places limits on the information we ttach to users. If we want to store additional information, we must do so ourselves and link it to the passport accounts.

Why Would We Not Use Forms Authentication?

\\~e have discussed the reasons why cookie-based authentication (and hence forms authentication) is ttractive to us by why would we not use forms authentication all the time? There are, of course, downsides to forms authentication:

Q We have to create our own interface for users to log in Q We have to maintain user details ourselves

p Resources protected by forms authentication must be processed by ASP.NET Q We have to take separate precautions against interception of network traffic

Creating Our Own Login Interface

As we mentioned earlier, forms authentication gives us complete control over the interface that users use to log into our system. Along with benefits, this brings extra work - we have to actually build the interface. In Windows authentication, a standard requester is used. In Passport authentication, we use the interface of the Passport site for logging in.

Creating the logging in interface does not require a lot of work but it should certainly be noted that forms authentication is a toolkit for building an authentication system rather than a finished system that is ready to use.

Maintaining User Details

When we use forms authentication, we are responsible for maintaining the details of the users who access our system. The most important of these are arguably the credentials that the user uses to log in to the system. We are responsible for keeping these details secure so we have to be careful about where and how they are stored. We are also responsible for backing up these details in case of system failure.

In Windows authentication, users' credentials are stored by the underlying operating system, Windows. A variety of techniques are used to keep them secure so this is considered a reasonably secure credentials store. In Passport authentication, the credentials are stored on Passport servers which are, we hope, secure and backed up regularly.

Resources Must be Processed by ASP.NET

In order to be protected by forms authentication, a resource (such as a page or an image) must be processed by ASP.NET. Requests for other resources will never be passed to ASP.NET, effectively allowing anonymous access to them. By default, only ASP.NET resources such as .ASPX files are protected.

We will see in the next chapter how we can extend the protection to other resources but there is a downside to doing so. Passing other resources through ASP.NET can impact on performance.

Windows authentication relies on IIS authentication and, therefore, protects all resources served by IIS. Passport authentication is similar to forms authentication in this regard - only resources processed by ASP.NET are protected.

IftK

Interception of Network Traffic

When a user enters their credentials for forms authentication, they are sent from the browser to the server in plaintext format. This means that anyone intercepting them will be able to read them. This is obviously an insecure situation.

There are solutions to this problem (most commonly Secure Sockets Layer as we will discuss later) but the fact remains that we have to do additional work to guard against traffic interception. As we saw in Chapter 7, in Windows authentication we have the option of using authentication methods that are protected against traffic interception. When Passport authentication is used, the credentials are protected through SSL on the Passport server - we never have to deal with the credentials themselves.

Why Not Implement Cookie Authentication Ourselves?

Cookie authentication is, on the surface, a simple system. Why don't we just implement it ourselves using cookies or session variables? We will look at features implemented in the forms authentication API that save us coding work later in the chapter. Aside from saving us some work, there are some additional advantages to using the forms authentication module rather than creating our own equivalent:

Q Security of the authentication cookie

G Forms authentication is a well tested system

Q Integration with the ASP.NET Security Framework

Keeping the Authentication Cookie Secure

Although cookie authentication seems simple, if it is not implemented correctly, we can be left with an insecure system. We saw in Chapter 2 that cookies on their own are not a safe place to store sensitive information - a would-be hacker can view and edit cookies. If our authentication is based on unprotected cookies, they will have an easy time compromising our system.

By default, the forms authentication module encrypts its authentication information before placing it in a cookie. It also validates the cookies when they return to the server to verify that no changes have been made. The combination of these two processes makes forms authentication cookies very secure. Using this scheme means that we do not have to do the work of coming up with our own scheme and verifying that it is secure. Many examples of self-built cookie authentication systems are far from secure.

Forms Authentication is Well Tested

Forms authentication ships with ASP.NET so it has already been used in a number of web applications and web sites. It is sure to be used on many more projects. Because so many people are using the same system, any flaws will be quickly discovered, publicized, and solved. So long as we keep up to date with patches our site's vulnerability will be minimised. (Let's reiterate again how important this is for security - we have to stay up to date with security patches if we want to be secure) If we create our own forms authentication equivalent, we do not have the advantage of this widespread testing. The first we know of a vulnerability might be when our system is compromised.

Integration with the ASP.NET Security Framework

In Chapter 3 we discussed the advantages of working with a framework for authentication and authorization. Code for authentication and authorization can interoperate easily and is organized in a logical, familiar way.

166

Forms Authentication

ication is fully integrated with the rest of the security framework - it populates the t (Principal) object and user identity (Identity) objects as it should do. As we will see later • this makes it easy to customize the behavior of forms authentication using the same

technique5 vx 'have covered for customizing other authentication types.

How Does Forms Authentication Work?

scussed earlier, forms authentication takes care of a lot of the plumbing of providing cookie ication. However, it is still a good idea for us to understand what is going on 'under the covers'.

\\'h n a request is made for a resource that is not accessible to anonymous users and forms

hentication is active, the URL authorization module will redirect the user to a login page. The URL of the original request is preserved as a URL parameter, for use later.

The login page contains a form for users to enter their credentials (usually their username and password). If the details that the user enters are correct, an 'Authentication Ticket1 is created. The authentication ticket contains the encrypted details of the user. This ticket is written into a cookie and sent to the client machine. The user is then redirected back to the URL they originally requested.

When the user requests the original URL again (due to being redirected back to it), the authentication ticket cookie is added to the request by the browser and picked up by the forms authentication module. It uses the details in the cookie to populate the Context .User property. This user information is then used by the URL authorization module to verify that the user is permitted to access the requested resource.

We can also authenticate users without using the access denied - login form - access granted process. In personalization scenarios, we may make logging in optional - users may follow a link to the login page rather than being redirected there automatically. In these situations, the authentication ticket is created and persisted as a cookie in exactly the same way as for forced authentication.

The Forms Authentication API

Before we implement forms authentication, it is useful for us to have an idea of what functionality is provided for us. Forms authentication is provided through a set of classes that compose the forms authentication API:

U FormsAuthenticationModule - The HTTP module that does the background work of dealing with the authentication ticket with each page request

-J FormsAuthentication - A class that contains utility methods and properties that we can use when implementing forms authentication

Q Forms Identity - An implementation of Ildentity (see Chapter 3) that is specific to forms authentication

Q FormsAuthenticationTicket - A class that represents the details of a user that we will encrypt and write to the authentication cookie

All of the classes that compose the forms authentication API are in the

System.Web. Security namespace.