| To understand security in distributed applications, you must be knowledgeable about the closely intertwined subjects of authentication and authorization. Authentication refers to the process of obtaining credentials from a user and verifying that user's identity. After an identity has been authenticated, it can be authorized to use various resources. Authorization refers to granting rights based on that identity. ASP.NET provides you with flexible alternatives for authentication. Some, but not all, of these authentication methods also make sense in regular Windows applications. You can perform authentication yourself in code or delegate authentication to other authentication providers. Because it's the most complex case, I'll consider authentication in the context of ASP.NET applications first and discuss other types of distributed applications later in the chapter. No Authentication The simplest form of authentication is no authentication. To enable an application to execute without authentication, you add this element to its configuration file: <authentication mode="None" /> Setting the mode to None tells ASP.NET that you don't care about user authentication. The natural consequence of this, of course, is that you can't base authorization on user identities because users are never authenticated. IIS and ASP.NET Authentication Actually two separate authentication layers exist in an ASP.NET application. All requests flow through IIS before they're handed to ASP.NET, and IIS can decide to deny access before the ASP.NET process even knows about the request. Here's a rundown of how the process works: IIS first checks to make sure that the incoming request comes from an IP address that is allowed access to the domain. If not, the request is denied. Next, IIS performs its own user authentication, if it's configured to do so. We talk more about IIS authentication later in the chapter. By default, IIS allows anonymous access, so requests are automatically authenticated. If the request is passed to ASP.NET with an authenticated user, ASP.NET checks to see whether impersonation is enabled. If impersonation is enabled, ASP.NET acts as though it were the authenticated user. If not, ASP.NET acts with its own configured account. Finally, the identity from step 3 is used to request resources from the operating system. If all the necessary resources can be obtained, the user's request is granted; otherwise, it is denied.
As you can see, several security authorities interact when the user requests a resource or a Web page. If things aren't behaving the way you think they should, it can be helpful to review the previous list and make sure that you've considered all the factors involved. Authentication Providers The ASP.NET architecture delegates authentication to an authentication provider a module whose job it is to verify credentials and provide authentication. ASP.NET ships with three authentication providers: The Windows authentication provider Enables you to authenticate users based on their Windows accounts. The Passport authentication provider Uses Microsoft's Passport service to authenticate users. The Forms authentication provider Uses custom HTML forms to collect authentication information and enables you to use your own logic to authenticate users. Credentials are then stored in a cookie.
To select an authentication provider, you make an entry in the <system.web> element in the web.config file for the application. You can use one of these entries to select the corresponding built-in authentication provider: <authentication mode="Windows" /> <authentication mode="Passport" /> <authentication mode="Forms" /> You can also create your own custom authentication provider. This doesn't mean that you plug in a new module in place of the supplied provider; it means that you write custom code to perform authentication and set the authentication mode for the application to None. For example, you might depend on an ISAPI filter to authenticate users at the level of incoming requests. Configuring Windows Authentication The Windows authentication provider enables IIS to perform the actual authentication and then passes the authenticated identity to your code. IIS offers four authentication methods: Anonymous If you select Anonymous authentication, IIS does not perform any authentication, and anyone is allowed access to the ASP.NET application. Basic If you select Basic authentication, users must provide a Windows username and password to connect. However, this information is sent across the network in clear text, making Basic authentication dangerously insecure on the Internet. However, one advantage of Basic authentication is that it's supported by most Web servers, proxy servers, and Web browsers. Digest If you select Digest authentication, users must still provide a Windows username and password to connect. However, the password is hashed (scrambled) before being sent across the network. Digest authentication requires that all users be running Internet Explorer 5 or later and that Windows accounts be stored in Active Directory. Integrated If you select Windows Integrated authentication, passwords never cross the network. Users must still have a Windows username and password, but either the Kerberos or challenge/response protocols are used to authenticate the user. Windows Integrated authentication requires that all users be running Internet Explorer 3.01 or later.
Passport Authentication The Microsoft .NET Passport is an online service (see www.passport.net) that enables users to use a single email address and a password to sign in to any .NET Passport participating Web site or service. Passport uses an encrypted cookie mechanism to indicate authenticated users. If users have already signed in to Passport when they visit your site, they are considered authenticated by ASP.NET. Otherwise, they are redirected to the Passport servers to log in. More information on using .NET Passport with your application can be found at www.microsoft.com/net/services/passport. Forms Authentication Forms authentication provides you with a way to handle authentication using your own custom logic within an ASP.NET application. (Note that this is different from custom authentication using an ISAPI filter, which takes place before the request ever gets to ASP.NET.) With Forms authentication, the logic of the application goes like this: When a user requests a page from the application, ASP.NET checks for the presence of a special cookie. If the cookie is present, the request is processed. If the cookie is not present, ASP.NET redirects the user to a Web form that you provide. You can carry out whatever authentication checks you want in your form. When the user is authenticated, you indicate this to ASP.NET, which creates the special cookie to handle subsequent requests.
The following steps show how to implement Forms authentication in an ASP.NET Web application: Add a new Visual C# ASP.NET Web application project (Example12_2) at the following location: http://localhost/EC70320/C12/Example12_2. Add a new Web form (frmLogIn) to the application. Place a Label control that displays a message asking the user whether she wants to log in, two RadioButton controls (rbYes and rbNo with a GroupName of LogIn), and a Button control (btnSubmit) on the form. Switch to Code view and add the following using directive: using System.Web.Security; Add this code to handle the Button control's Click event: private void btnSubmit_Click(object sender, System.EventArgs e) { if(rbYes.Checked) FormsAuthentication.RedirectFromLoginPage("Admin", false); } Edit the web.config file to replace both the <authentication> and <authorization> elements, as follows: <authentication mode="Forms"> <forms loginUrl="frmLogin.aspx" name="Example12_2" timeout="1" /> </authentication> <authorization> <deny users="?" /> </authorization> Set WebForm1.aspx as the start page and run the application. Instead of WebForm1, the browser displays the custom login form. To proceed further, you must select the Yes radio button and click the Submit button.
Of course, in a real application, you'd likely implement a more sophisticated authentication scheme. You might, for example, store usernames and IP addresses in a database and allow only users who connect from their registered IP addresses. Or, you might develop a Web service that allows authenticating users over the Internet. By default, in the web.config file, the <authorization> element contains <allow users="*" />. With this setting, ASP.NET allows all users even unauthenticated users access to application resources. The * wildcard matches any user. For the previous example, we changed this to a deny element, like this: <deny users="?" /> The ? wildcard matches only unauthenticated users. The net effect is to allow authenticated users access to all resources, while denying unauthenticated users access to any resources. The <forms> element contains the URL of the form to use for login authentication, the name of the cookie to use, and a timeout that controls how long a user can work with the application before being directed back to the login page. (The previous example sets this to the very low value of 1 minute for testing.) When the user is authenticated, the form calls the RedirectFromLoginPage() method of the FormsAuthentication object. The two parameters to this method are the name of the authenticated user and a Boolean value that controls whether to save a permanent (cross-session) cookie. If the second parameter is false, the cookie is stored in memory and only for the length of the browser session. Note that the login form doesn't contain any reference to the page where the user will go after authenticating. The Forms authentication provider automatically keeps track of the name of the page that the user was trying to access and sends the user there when you call the RedirectFromLoginPage() method. |
