Visual Basic .NET at Work Building 10 Enterprise Projects phần 8 potx

Web Security You’ve seen Web security all over the place. Any Web site that asks you to log in uses Web security of one sort or another. The .NET platform and ASP.NET give you a few options and let you build security into your Web sites and Web applications just like those you’ve seen before. In fact, that’s what we’ll be doing in our project. You can even secure different parts of a Web site or application with different levels of security. For example, you might provide the entire public (anonymous users) with access to adver- tising and product information on your site. However, only employees who log in and have proper access will be allowed to see the sales information. The primary focus of Web security is to redirect users to a login page when they try to access a part of the site that is restricted. The system will handle this for you auto- matically once you define and configure the access rights to the site. I will be covering this in detail later. What about Code? Although we are focusing on Web security, you can also secure code components. The .NET Framework provides a mechanism called code access security that allows us to specify the rights of code modules, as well as users. Based on several criteria, including where the code originated and what sort of guarantees are provided with it, you can decide how much code can be trusted. You can actually specify what sorts of operations and access to resources that code modules have, very much like users. This can reduce the likelihood of malicious code even being allowed to execute on your system. You can get some of these benefits merely by programming in an approved .NET-managed code programming language. However, programming will be required on your part to take full advantage of it. The code access security system works something like this. You create code compo- nents that have specific access needs. For example, your code module might need to read and write to the server registry. This would typically require a high level of secu- rity. When a caller makes a request to use your functionality, your code can require that the caller have the same security rights that your module does. In fact, the security sys- tem will walk the entire call stack to make sure that every caller in the call chain has proper clearance. If any one of the callers does not meet your security requirements, you can deny access to your services. In this way, code that you write can be built with the correct code access security levels to use the registry module, but malicious code that finds its way into your system and tries to execute whatever it finds would be denied access to your code. Using the .NET code access programming mechanisms, you can help your code sat- isfy security requirements and also require that any modules you call have specific per- missions. Code access security is a valuable tool for distributed applications, making them more secure at the module and method levels. However, it is not something you can design and build in a couple hours. It will require systemwide planning to decide what resources are available to components at various levels and what modules should be trusted and how much, and a comprehensive security policy will have to be worked out with your system administrator. 342 Project 8 Role-Based Security Often it is not practical to assign specific rights to every user. You can, instead, assign rights to roles and place users in these roles. A role is simply a named set of rights. Users in that role all have the same rights. For example, you would give the Accoun- tant role access to the company’s financial database but not to the Human Resources information. The CEO role might, depending on your company, be locked out of most everything or given access to everything. The .NET security functionality allows you to use role-based security. It’s not sim- ple, but it does provide a useful mechanism for implementing security. It involves cre- ating Identity and Principal objects and using them with the PrincipalPermission object to perform security checks. The Identity object contains information about the user involved, and the Principal represents the security context, including the role under which the user is operating. You can use those objects with the PrincipalPermis- sion object to make requests about specific permissions that the user and role are allowed to perform. Although we will not be covering role-based security in this project, it is important to know what your options are. Consider looking into this mechanism further if it sounds like it might meet your needs. For example, if you have a large number of internal users, role-based security might be appropriate. Authentication and Authorization The process of authentication is the biggest task in security. There are several mecha- nisms available to handle authentication, each of which has its own pros and cons, depending on the situation and the application. We know that authentication is the process of identifying users. However, typically you have to know something about the users to begin with. On a basic Web site, where you might be simply collecting a list of users for auditing or advertising purposes, you might only ask them for some information on a form and accept it as truth. At the other end of the spectrum, you might only allow known employees to access your site or application. In that case, you would have to have a predefined list of users and a mech- anism for maintaining that list. The various authentication mechanisms each have their own ways of providing a list of users. The authentication mechanisms available with .NET, IIS, and Windows are as follows: Forms authentication. This mechanism allows you to handle most of the authen- tication yourself, but still provides you with redirection mechanisms and the maintenance of security during a session and beyond a session. It is used primarily for Web sites and Web applications. Windows authentication. In this authentication scenario, IIS and Windows work in concert to handle authentication. This is one of the easiest mechanisms to use, requiring little work on the part of the programmer. However, it will only allow into your site or application users who are registered with the Windows domain. For internal applications, this is fine. However, a Web site that allows anonymous users or new users to create accounts should not use it. User Authentication Login Screen 343 Passport authentication. Passport is an authentication service that Microsoft cre- ated and runs. Users create a Passport account through Microsoft, which provides them with varying levels of information such as a name, address, password, phone number, and even credit card information. You can use this service to validate user-supplied credentials against information stored in the Passport database. Using Passport authentication is a little involved, but if you’d like to learn more about it, you can do so at http://www.passport.com. Developer links are on the site. Authorization with Web Forms is the process of allowing authenticated (or other- wise) users access to specific resources. We can define what those access levels are by user, role, or in general. These settings are defined for portions of a Web application or site using the configuration file, which I’ll cover in detail later. Forms Authentication and Authorization Forms authentication and authorization are ideal for Web sites and Web applications that are open to the public or that provide varied levels of access to different parts of the site. Programmers have the most control over these mechanisms. They provide a redirection mechanism that presents your own login page if the user requests a restricted resource and has not yet been authenticated. The basic process looks like this: 1. The user requests a secured resource on the Web server, a Web page to which you have restricted access. At this point, the user has not been authenticated, so the server automatically redirects the request to your specific login page. 2. The user enters login information, usually a user name or ID and a password. These are sent to the server when the user submits the form using a button or other mechanism. 3. The login credentials are validated on the server. This is done by your code. There are plenty of mechanisms available to you to do this, from the simple to the complex. In the end, however, you decide if the user should be allowed to access the requested resource. 4. If users pass your inspection, you can send them to their originally requested page. You don’t have to know what the page was; the FormsAuthentication system knows it. They are now authenticated on the system, and the authenti- cation information will automatically be passed around from page to page during the current session or between sessions. 5. At this point, the authorization is checked. If the authorizations prohibit users from viewing the requested resource, even though they are authenticated on the site, they will not be allowed access to the page and will be informed of this. If they are authorized, the redirection will continue and the page will be displayed for them. 6. If users do not pass authentication, you can leave them on the current URL and display a nice login error message for them. They are not authenticated on the 344 Project 8 system. If they try to access the page again, or other restricted pages, they will be sent right back to the login page. The forms security concepts and execution flow are now established. So how do we make it happen as programmers? There are two basic steps: securing the parts of the Web site that we want to protect and implementing the code to make it work. Configuration Files Securing portions (or all) of a Web site or application is controlled, with Web Forms, using configuration files. The files, named Web.config, are placed in directories of the Web server to tell IIS how to secure the resources in those directories. This is where you define the authentications and authorizations for the files in the particular directories. The file is an XML file that you can edit manually. Here’s an example: <configuration> <system.web> <authentication mode="forms"> <forms loginURL="myLogin.aspx" name=".ASPXAUTH"/> </authentication> <authorization> <deny users="?"/> </authorization> </system.web> </configuration> This configuration file defines both authentication and authorization. The authenti- cation mode has been set to forms mode. Other authentication mode options include Windows, Passport, and None. It then defines the login page that users should be redi- rected to if they request a secured page and have not yet been authenticated. The sim- ple authorization section tells IIS to deny access to all anonymous users. There are many more options for authorization. A few examples are shown in Table 8.1. Table 8.1 Examples of the Authorization Clauses AUTHORIZATION CLAUSE DESCRIPTION <allow users=”*”> Allow anyone into the resources in this directory <allow users=”homer, tony”> Allow only these two users access to the directory <allow roles=”HR”> Allow only those users in the HR roles group access to this director <deny users=”*”> Don’t allow anyone in here, except those defined in an “allow” clause User Authentication Login Screen 345 The last clause given in the table is important. It shows that these clauses can be combined. Consider the following: <deny users="*"> <allow users="homer, tony"> This pair of clauses keeps everyone out except the users Homer and Tony. Use the combinations, but test them out once they are in place to make sure they do what you expect them to. It’s fairly easy to mess these up, so use caution. When you create a Web forms project with Visual Studio .NET, it creates a Web.config file for you at the root level. You can open and edit this file like any other file in your project. It defaults your application to Windows authentication mode, and if you want to use forms mode, you can just change it in the authentication section of the file. You can also create new directories for your Web application in the Solution Explorer. Do this to organize the sections of your application by the access you’d like to provide, and then create additional Web.config files to restrict or grant access to these directories as needed. The configuration file is placed in a specific directory on the Web server. For example, if you had an application that is completely restricted, it will go in the root directory of the Web application, like this: C:\Inetpub\wwwroot\RestrictedApp\web.config You can use a single configuration file to restrict access to a specific directory and all subdirectories below it. You can then override those settings in subdirectories by plac- ing additional web.config files in those directories. For example, if we allow everyone into the main Web application, we can place a web.config file in the Web application root directory with the following authorization: <allow users="*"/> However, we want to restrict a portion of the Web site that displays usage statistics to only selected, specific users. We would organize our Web site into directories that reflect our authorization needs, and the usage statistics content would be located in its own directory, restricted by its own web.config file. The file would be located in a sub- directory called Usage that contained our usage statistics content. That web.config file would look like this: <configuration> <system.web> <authorization> <deny users="*"/> <allows users="statadmin"/> 346 Project 8 </authorization> </system.web> </configuration> Only the user called statadmin would be allowed access to the resources in the directory that contains this web.config file. Note that we only need the authorization information for this configuration file. Authentication is provided in the web.config file at the application root. Authentication and Authorization in Code We’ve seen configuration files and we’ve talked about security concepts and setup. However, we need to tie them together in the final step: code. We’ll take an amazingly simple example wherein we only allow a few specific people into a Web site. We’ll pro- vide a very basic login page, a placeholder page for the requested resource, and a con- figuration file to set things up. To begin with, here’s a configuration file that will let all anonymous users at least attempt to log in to the page: <configuration> <system.web> <authentication mode="forms"> <forms loginURL="myLogin.aspx" name=".ASPXFORMSAUTH"/> </authentication> <authorization> <allow users="*"/> </authorization> </system.web> </configuration> Now we can create a simple Web page that has the necessary login fields. You can do this manually or using Visual Studio. The login form looks like Figure 8.1. The simple default form, the one that we’re going to restrict access to, looks like Figure 8.2. Figure 8.1 The myLogin.aspx form. User Authentication Login Screen 347 TEAMFLY Team-Fly ® Figure 8.2 The default.aspx form. When users try to access the default.aspx file through their Web browser, the configuration file tells IIS to redirect their request to the file myLogin.aspx. When this file is displayed, users enter a user ID and password and then click the Login button. At this point, the button event code fires; the code looks like this: Private Sub btnLogin_ServerClick(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles btnLogin.ServerClick If ((tbName.Text = "tony") And (tbPwd.Text = "doggie")) Then FormsAuthentication.RedirectFromLoginPage( _ tbName.Text, False) Else msg.Text = "Invalid login information. Please try again." End If End Sub This code is very simple, and the only validation we do is to match what the user entered against a specific ID and password. You could replace this with any sort of val- idation code you like, and as you’ll see in our project, I replaced it with something much more useful. If the user ID and password match the ones we’re allowing, we make use of the FormsAuthentication object that’s part of the System.Web.Security namespace. The method we’re using, RedirectFromLoginPage, actually handles the redirection to the originally requested page. So we don’t have to remember it or even know it in the first place. If the user ID and password don’t match, we tell the user and stay on the page. The redirection from the requested page is handled by IIS for us, and for any other pages that are restricted. 348 Project 8 Let’s Start the Project If your business creates lots of Web sites or Web applications, you will probably want a standard login page that you can use to gain access to any of them. Our project is a set of pages that you can use as a front end to any of your sites. With a little modifica- tion to the appearance to match your company’s look, this project could find a nice home in front of all your Web sites that need security. The project is similar to the samples you’ve seen so far. We need two configuration files to define the authentication method and the authorizations. We will have a login page and a placeholder for our application. We went a step further with the password checking, however. All our users and their respective passwords are located in a SQL Server database. This makes them a little more secure, more expandable, and easier to edit and maintain. We’ve even added a form that will let users add an account for themselves and then login. Setting Up We need to create the project, get the database set up, and create a new directory for the unsecured part of the site. Once that’s done, we can create the pages and the code behind it. The Database You saw simple password and user ID verification in a prior example, where we com- pared the user’s credentials to hard-coded values. In this application, we’re going to store all the users in a SQL Server database. The database design we need for this appli- cation is simple. It has only one table. The columns are defined as shown in Figure 8.3. As for previous projects, a Microsoft Access version of this database is on the accom- panying CD-ROM; you can import into SQL Server. It includes a few sample user accounts that you can try out. The connection string that we use for it is defined in the code-behind module for the two ASP pages that we created. The Site Organization This project has three pages: the login page, the New Account page, and default.aspx, which represents the main page of your application or site. The default.aspx page is the one that needs to be secured; the New Account page needs to be accessible to everyone with no restrictions. To make that happen, we are putting the New Account page in a subdirectory of its own where we can control its more open access with another web.config file. When we create the project, we’ll add a folder to the project called NewAccount where we’ll create the new account form. We’ll also add a web.config file there that we will type in manually. User Authentication Login Screen 349 Figure 8.3 The security project database. Create the Project Start everything by creating a new Web Forms project in Visual Studio. I called mine prj08, but you can name yours whatever you like. It should include the first empty Web Form, as well as a web.config file in the project root. As long as we’re here, and because we need it for the next section, create the subdi- rectory for the new account form. Right-click on the solution name in the Solution Explorer and select Add Folder, naming it NewAccount. The Images Folder One last setup detail is that we have an image we want to use for our header, and we need to add it to the project. Create a new folder in the project by right-clicking on the solution name in the Solution Explorer and selecting the Add Folder option. Name the folder images. Then add the image by right-clicking on the new folder name and select- ing the Add Existing Item option from the menu. Browse to the file vc_prj08.jpg on the accompanying CD-ROM and add it in. It is now available for use by the application. Configuring Security Visual Studio created a Web.config file for us in the root directory of the project. You can open it like any other file, so let’s do so and edit it a little. Notice that there are all sorts of things in this file, only some of which are related to security. The rest can be 350 Project 8 safely ignored for the time being (just don’t do anything to it). Also notice that there is already an authentication section with some information in it and an authorization sec- tion with nothing in it. We’re going to change that. Edit the authentication section so that it does not use the Windows authentication method, but uses the Forms method instead. Also tell it to point to the login form that we’re going to create for the security redirection. It should look like this: <authentication mode="Forms"> <forms loginUrl="prj08login.aspx" name=".ASPXFORMSAUTH"></forms> </authentication> The authorization portion is simple. We want to deny access to all anonymous users, which implies that we allow access to all authenticated users. This is exactly what we want in this case. Here’s the authorization section for the root configuration file: <authorization> <deny users="?" /> </authorization> That takes care of that one. Now we need another one, which we’ll have to create from scratch. This one is for the NewAccount directory, and we need it so that we can override the restrictive security we just set up at the root level. Lower-level (directory level) web.config files have priority over higher ones. So let’s open it up with the fol- lowing web.config file. You can create it in a text editor and then add it to the project. <?xml version="1.0" encoding="utf-8" ?> <configuration> <system.web> <authorization> <allow users="*" /> </authorization> </system.web> </configuration> The Forms Now that we’re all setup, we can actually create some content. The three forms we’re making could be created using the Designer tools or the HTML window. Ours will be built by hand in the HTML window so that we can get the layout the way we wanted it. The Login Form Our primary form, which allows the user to login to the system, can be created by renaming the default form that Visual Studio created for us. Rename it prj08login.aspx. The form we’re creating looks like Figure 8.4. It helps to have an image of what you’re building before you build it. User Authentication Login Screen 351 [...]... not a match, meaning the user is not in the database, it returns an empty string Otherwise, the method uses standard ADO.NET techniques that you’ve seen in other projects Team-Fly® 357 3 58 Project 8 Figure 8. 5 The New Account form The event handler that traps the Login button click, btnLogin_ServerClick, retrieves the matching password and sees if the one the user entered matches the one in the database... applications are fun to build However, what would you say if I said you could easily build Web sites and applications for cell phones and other Web-enabled devices? That’s exactly what we’ll be doing using the Microsoft Mobile Web SDK and Visual Studio NET We will create a Web site that uses ASP.NET, database access and even separate middle-tier business components to provide useful, current information... here at this early stage First, notice that the standard header for an ASP mobile application that we mentioned earlier has been included for us Second, take a look at the tags that define the controls Every one is preceded by the mobile attribute This is required for mobile Web applications, and almost every tag will have the mobile attribute Lastly, notice that all the controls have the following attribute:... Microsoft Mobile Explorer (MME) is an emulator, a version of Internet Explorer that emulates an actual cell phone minibrowser The MME integrates tightly with Visual Studio and is the runtime environment for your mobile applications When you run the application, it comes up in the MME (once you configure it to do so; more on this later) Figure 9.1 shows what the MME emulator looks like Microsoft even went... definitely want to give it a try with a Web-enabled cell phone ✄ You Will Need ✔ Visual Studio NET ✔ The Mobile Internet Toolkit SDK ✔ Microsoft Mobile Explorer 3.0 or later ✔ A basic knowledge of Visual Basic NET ✔ Internet Information Server ✔ SQL Server (or other database) ✔ A basic knowledge of ASP.NET Employee Information System Using the Mobile Toolkit Technology Overview The idea behind remote... Internet Toolkit, Visual Basic NET, and ASP.NET to create the main application This is the fun part wherein we construct the mobile Web site that users will access through cell phones; it will include features like weather alerts, company announcements, company phone lookup, company events, and a next holiday function 3 Test it out We’ll test the program out once it’s complete using the emulator, but you’ll... again If it is not a duplicate, it then attempts to insert the new record in the database Notice that this time we are throwing our own custom exceptions if there are errors or conditions of our own that represent errors Using this technique is not only solid error handling, but it also allows us to create accurate error messages for the user that are very easy to display later The event handler for... Toolkit is that it’s based on ASP.NET If you know ASP.NET, you’ll have a great start on mobile Web content The process you use to create mobile Web sites is the same one you use to create regular ASP.NET Web sites or applications You can write ASP code using any editor, or you can allow the tools to generate it for you Other bonuses include a complete suite of controls that are made specifically for the... to retrieve alert rows that are current By design, ' there is only ever intended to be one row in there, reflecting ' the current state of the company sSQL = "SELECT pwd FROM VultureUser WHERE ID='" & sID & "'" ' Get our data objects ready for retrieval Dim da As SqlDataAdapter = New SqlDataAdapter(sSQL, conn) Dim ds As DataSet = New DataSet() Dim theRow As DataRow ' Load the data Try conn.Open() da.Fill(ds,... the details Therefore, that’s how we’re going to start An overview of the process can be a big help when it comes to understanding the individual topics we’ll be covering The steps listed below illustrate how to create your own mobile Web application, although there may be deviations given your own needs 1 Create a new mobile Web application project in Visual Studio This application type will be available . the configuration file, which I’ll cover in detail later. Forms Authentication and Authorization Forms authentication and authorization are ideal for Web sites and Web applications that are open. authorization information for this configuration file. Authentication is provided in the web.config file at the application root. Authentication and Authorization in Code We’ve seen configuration files and we’ve. Authentication Login Screen 349 Figure 8. 3 The security project database. Create the Project Start everything by creating a new Web Forms project in Visual Studio. I called mine prj 08, but you