ASP+ Authentication Providers

Advertisements

ASP+ Authentication Providers

Cookie authentication and authorization is vital for Web site security and personalization.

Introduction:

ASP+ provides several new authentication and authorization schemes to enable not only the security but also the personalization of your Web site. These schemes are in addition to the default authentication schemes that IIS provides. The .NET PDC Tech Preview documents four authentication providers: Cookie, Passport, Windows, and None. The most interesting one for me, from a development standpoint, is cookie authentication. This article delves into cookie authentication and shows you how to add value to your sites. It is important to note that these ASP+ authentication providers are only executed for files that invoke the ASP+ engine. This means that requesting an .asp file will not invoke the ASP+ authentication provider by default. All authentication options are set in an XML file, called CONFIG.WEB�the new location for much of the information that was placed in the metabase in the past. To specify the authentication provider you need to use the <security> and <authentication> tags. Note that Listing 1 shows a valid XML document. This means that case matters, as does the order of the tags. If there is no security node in CONFIG.WEB, then ASP+ defaults to using no authentication provider. Although ASP+ is not using an authentication provider, the underlying IIS mechanisms are still in place. In this mode authentication is unchanged from IIS 4.0/ASP 3.0. The Windows authentication provider is used to authenticate logins and map them to Windows groups. This is done by creating a WindowsPrincipal object and attaching it to the request. This object is then used for authentication when accessing resources or assemblies in the page. The passport authentication provider integrates with the Microsoft Passport service and uses the passport service for authentication. Cookie Authentication Cookie authentication is useful when you want to control the entire authentication process from login form to authorization. However, this method requires your user to accept cookies for it to work. Cookie authentication, as the name implies, uses a cookie to persist authentication information and permit access to locations in the site. You might wonder how cookie authentication actually works. When a request for an ASP+ page first comes to a Web set using cookie authentication, ASP+ checks for an authentication cookie. If none is present it is redirected to a login form. The login form that you write collects the username and password and then authenticates it in a way you define. If the username/password combo pass authentication, then you call an API to write the authorization cookie and redirect the user to the original content they were looking for. If an authentication cookie is present on subsequent requests, the user is passed through immediately to the content they requested.

Authentication Example

Let's work on an example. First off I must modify the CONFIG.WEB from Listing 1 by removing the Windows authentication provider and replacing it with the cookie authentication provider. The new CONFIG.WEB is shown in Listing 2.

Listing 2. A modification of the CONFIG.WEB from Listing 1 that changes the authentication provider to cookie and also forces all users to authenticate.

First the mode is set to "cookie" and then the parameters are specified for cookie authentication. In the <cookie> node I set the decryption key to autogenerate. This is fine if you have a single Web server. If you are operating in a Web farm, however, you will probably want to set this value explicitly so that all nodes share it. The loginurl attribute is set to indicate which page unauthenticated users should be directed to�in this case login.aspx. Finally, the cookie attribute indicates what the name of the cookie should be. This is useful if you have several authentications schemes running on a single domain and don't want them to collide.

Cookie authentication can automatically validate against name/password pairs specified in a <credentials> section of the CONFIG.WEB file. This is convenient for testing but clearly presents problems in maintaining and scaling the authentication. A better choice would be to place the authentication information into a database like SQL Server. Listing 3 shows the TSQL required to create a table called Users, against which I will authenticate the user.

After creating this table and populating it with a few accounts, all that is left is to create the login form. The login form needs to collect the e-mail address and password of the user and then validate them by comparing them against the database. If they match, an authentication cookie will be sent to the user. Listing 4 contains a sample login form.

The login form first presents an ASP+-based login page to the user. Server-side controls are used to validate that the user has entered an e-mail address and password. Once these have been entered and the login button clicked, control is passed back to the server and the Login_Click() method is executed. Login_Click first checks to make sure the page is valid. If it is, a connection is built to the database and a query is run to retrieve the password of the user. This is compared against the input; if it matches, RedirectFromLoginPage is called to redirect the user back to the originally requested page and also write the authentication cookie to the browser.

There it is�custom authentication in 30 lines of code or less. Compared to the hoops you would have to jump through in ASP 3.0, this is amazing. I want to take authentication further, however. Authentication is great but in many cases what you actually want is authorization.

Custom Authorization

Authentication determines that I am who I say I am. This is usually done via name/password combinations. Authorization, on the other hand, determines what a particular user is allowed to access. Typically authorization is handled with a group-mapping or role-mapping scheme. A user is associated with multiple roles and these roles are then mapped to resources. ASP+ allows for you to define roles with access to resources outside of the scope of the access control lists (ACLs) placed on individual files. This is done in the CONFIG.WEB file in an <authorization> node. Listing 5 shows a CONFIG.WEB file that would be put into an administrative directory to limit access to pages there.

By placing CONFIG.WEB files like the one in Listing 5 in different locations throughout your site, you can customize who has access to things on a directory level irrespective of ACLs and have those permissions persist even after moving the site with FTP or some other type of XCOPY process.

Now that I have defined what roles are required to access a particular URL, how do I map users into roles? This is done by defining two additional tables in SQL Server: Groups and UserGroupMappings. Groups contains the roles like Administrator, Publisher, or any other role you would like to create. UserGroupMapping connects particular users to roles. This allows me to perform a query and get all the roles for an authenticated user. Listing 6 provides the TSQL to create these tables.

Now that I have the roles defined in the database I have to write some code to handle authorizing against the database. You might think this would need to go into the login.aspx page. But that page is only called on the first request. Authorization needs to happen on each request. The way this is done is to define an httpModule, the binary equivalent of global.asax. HttpModules participate in the application event model and can sink various events that are raised. In this case I am interested in the Application_Authenticate() event, which is raised each time the system needs to authenticate access. Listing 7 shows how to add the httpModule to CONFIG.WEB.

In the DevxGroup event handler, I connect to the database, retrieve the list of groups, create a new DevxCustom security principal, and populate it with the roles I looked up from the database. Going to the database each time you need to authenticate a page is not the most efficient way to handle this but you could easily extend the methodology to store the roles in an encrypted cookie. The DevxCustom security principal implements the IsInRole() interface, which is called by ASP+. If the user is in the role that ASP+ passes to this function, the method should return True; otherwise it should return False. It compares the passed-in role with the string table that was created in DevxCustom when the principal was created. Listing 8 and Listing 9 include the code from the DevXGroup and DevXPrincipal classes.

That's it! Using these techniques you should be able to create your own authentication and authorization schemes using any data source for storing user data. Have fun.