| The previous discussion is relevant for intranets or other scenarios where users will have Windows user accounts on the servers or domains. Furthermore, Windows Integrated Security does not work across firewalls or proxies. For public Web sites, we need another approach. The alternative approach is to bring up a login form to authenticate the user. We will look at two of the several approaches possible within .NET to login forms. The FormsBasedAuthentication example uses the .NET Forms-Authentication class and the web.config file. Forms Authentication and Authorization .NET Forms-based authentication uses the application's web.config file, a login form, and an optional cookie to authenticate the user. Typically, in this scenario you will set up the Web site for anonymous access so that no users will be screened out by IIS. Here is the web.config file section for the FormsBasedAuthentication example:  <authentication mode="Forms"> <forms name = "HotelBrokerCookie" path="/" loginUrl="Login.aspx" protection="All" timeout="10"> <credentials passwordFormat="Clear"> <user name="Natasha" password="Natasha" /> <user name="Adams" password="Adams" /> <user name="peter" password="peter" /> </credentials> </forms> </authentication> <authorization> <allow users="Natasha,peter" /> <deny users="*" /> </authorization> The authentication mode is set to Forms. This means that the User.Identity object will be a FormsIdentity instance if the user is authenticated. The forms element has several attributes that define how the authentication is set up. The name attribute is the name of the cookie. The path attribute indicates where on the site the cookie is valid, "/" indicates the entire site. The loginUrl indicates where the login form resides. The protection attribute indicates how the cookie should be encrypted. "All" indicates that the cookie should be validated and encrypted. Other options are None, Encryption, Validation. Timeout indicates how many minutes before the cookie becomes invalid ( expires ). The credential elements indicate how the password should be stored in the configuration file. For simplicity, we have used clear text. You could also specify SHA-1 or MD5 to hash the passwords. If passwords are stored in web.config , it should be secured against download. Passwords for the configuration file can be encrypted with the static FormsAuthentication method HashPasswordForStoringInConfigFile . The user elements indicate the user names and passwords. The authorization section, as discussed earlier, determines which authenticated users are authorized to access the Web site. Since this example uses redirection and cookie validation, a user should attempt to access the main page, http://localhost/FormsBasedAuthentication/default.aspx , instead of the login.aspx file. If a valid cookie does not exist on the system, the user will be sent to the login page. If a valid cookie exists, it will be used to validate the user and will go straight to the default.aspx page. If the user went straight to the login page, he or she would have to log in every time, even with a valid cookie. Here is the code for handling the Login button event: Private Sub btnLogin_Click(...) Handles btnLogin.Click If FormsAuthentication.Authenticate(_ txtUserId.Text, txtPassword.Text) Then FormsAuthentication.RedirectFromLoginPage(_ txtUserId.Text, True) Else lblErrorMessage.Text = "Could not authenticate user." End If ... End Sub For simplicity, the Password textbox does not bother to hide the password, but of course, in real life, the password should be hidden in the user interface. The FormsAuthentication class's Authenticate method validates the user name and password from the web.config file. If a valid cookie is on the system, this authentication is skipped . RedirectFromLoginPage does several things. It checks the authorization section of web.config to see if the users have the rights to access the file, creates a cookie, and redirects the user to the default.aspx page. If the second argument is true, a persistent cookie is placed on the user's system. Using persistent cookies is a security risk, because the cookie can be stolen as it is transmitted. You could use SSL to protect the cookie. You can remove the session or persistent cookie with the SignOut method. If you run the FormsBasedAuthentication example, only Natasha, peter, and Adams will be authenticated. However, only Natasha and Peter will be authorized to use the site. Of course, only Natasha will be found in the database of Acme customers. That test has been moved to default.aspx to distinguish it from the forms authentication done in login.aspx . Default.aspx can refer to the name of the user through the User object. The type of identity object is FormsIdentity . Dim ok As Boolean = _ HotelState.acme.Login(User.Identity.Name) If you succeed and log in as Natasha once, subsequent tries will succeed without the login page because we have created a persistent cookie. To avoid persistent cookies, set the second argument to RedirectFromLoginPage to false . The application, however, runs under the identity of the system process or thread, not the identity of the user name that is logged in. Hence, role-based security in ASP.NET can be used only with Windows authentication, not with Forms authentication. You will have to write code to control access to the Hotel Administration page.  | 
