Professional ASP.NET 1.0 Special Edition- P25 ppt

We also learned that configuration files are inherited. The default settings in machine.config are inherited in web.config files, unless overridden, as we saw in the <sessionState> examples within this chapter. After introducing configuration, we then spent the bulk of the chapter discussing various configuration settings used in ASP.NET. We covered topics from internationalization, to HTTP Handlers, to process model settings. The settings covered in this chapter should cover 90 percent of all the configuration settings we will want to use for our applications. Finally, we discussed how we could author our own configuration section handler by implementing a class that inherited from the IConfigurationSectionHandler interface. Securing ASP.NET Applications Most of the pages that you create for a public Web site are designed to be accessible to any visitor, so the default settings for ASP.NET pages are ideal - anyone can access the pages from anywhere on the network or the Internet. However, there will always be some pages that you don't want to be publicly available. For example, you might want to limit access to a complete site to users who have paid a subscription, or to limit access to administration pages to specific users only. In previous versions of ASP, securing your pages was generally done in one of two ways. You could create a custom security system that allowed users to login to your site or application (or a specific part of it). Alternatively, you could rely on the security features of IIS and Windows itself to control which users could access specific pages, folders, or resources. In ASP.NET our pages run under the .NET framework, and this introduces new concepts in managing security, while still retaining existing security features. In this chapter, we'll overview all the features that control user access, and then concentrate on the specific techniques designed for use with ASP.NET. The main topics of this chapter are:  An overview of the security model in Windows 2000 and IIS  An overview of the new security features in ASP.NET  The different types of access control that we can implement with ASP.NET  A detailed look at how we apply the ASP.NET security and access control features  A brief overview of the "trust" model Windows 2000 and IIS Security Overview As this book is about ASP.NET, we'll only be providing an overview of the features in the Windows operating system and IIS for securing your Web pages and Web applications. Though we will be concentrating on Windows 2000 here, the concepts, configuration, and usage of these features is virtually unchanged from previous versions of ASP. However, they do provide the basis on which .NET security techniques are founded. If you are not familiar with the material in this section, you may wish to consult other documentation or books to gain a broader understanding. Securing your applications or Web sites is one of the most important factors when connecting your server to the Internet. While the basics described here, and the techniques we use to control access, will provide a secure environment, you must still implement all the other measures that are required for protecting your servers and applications against intruders. This includes physical security (e.g. locked doors and windows), internal user security (e.g. keeping passwords secret and monitoring usage), virus protection, prompt installation of operating system updates and patches, etc. The Need for Security When you come to secure your applications, you must first think about what it is you are actually trying to achieve. For example, does your application contain highly sensitive information, or allow users to perform tasks that you absolutely must protect against misuse - such as a bank providing on-line account access to clients. Or, is the information less sensitive but still valuable, such as content that you want visitors to pay a subscription to access. In the end, it all comes down to quantifying the risks involved and the effect of a security breach. Securing applications is more difficult than allowing everyone access, and can involve using extra hardware to build complex multi-layer systems with firewalls, demilitarized zones, and all kinds of other highly-secure features. However this type of approach is normally used only when the highest levels of security are required, such as when you are protecting whole networks from access by external intruders. Security as it concerns our ASP.NET applications will normally be limited to the configuration of the machine(s) on which they run, and the connected resources such as database servers, etc. This generally involves limiting access to specific folders, files, components, and other resources, to only the appropriate users. These topics are the real focus of this chapter. If you are building an application that requires the utmost in protection from intruders, you must base the ASP.NET servers in a secure environment, as well as configuring them correctly. This involves the kinds of extra equipment we mentioned earlier, and a thorough understanding of the risks involved. Books such as Designing Secure Web-based Applications for Windows 2000 (MS Press, ISBN 0-7356-0995-0) and Hacking Exposed - Second Edition (Osborne, ISBN: 0-07-212748-1) are useful. If in doubt, however, employ an experienced professional to design and secure your network and servers as well. Security Concepts The basic concepts for securing your applications consist of four main topic areas:  Authentication is the process of discovering the individual identity of users, and making them prove that they are who they say they are.  Authorization is the process of determining if a particular user is entitled to access the resource they've requested.  Impersonation is the process whereby the resource is accessed under a different identity, usually the context of a remote user.  Data or functional security is the process of securing the system through physical means, operating system updates, and the use of robust software. We don't cover this topic in this chapter. Many elements of the operating system, IIS, and the .NET Framework combine to provide the features required to implement the first three of the topics we listed above. For example, Windows 2000 uses its own list of user accounts to help identify and authenticate users. IIS also identifies users based on the information provided by Windows as they access a Web site, and it passes this information on to ASP.NET where it can be used as part of the overall authorization process. To help you understand how the overall security process works, we'll look separately at each of the first three topics listed above. Just remember, however, that they are all part of the same chain of events involved in allowing or denying users access to resources. Authentication To be able to limit access to specific users, we have to be able to identify them. This doesn't mean we need to know everything about them - as in some "big-brother" scenario - but we do need to be able to tell each user apart, and identify those that should have access and those that should not. Authentication involves challenging a user to prove that they are who they say they are - usually by means of a username and password, a digital certificate, or perhaps even a "smart card" or a fingerprint reader. In theory, if they can provide a valid username and password combination or some other user-specific "property" that can be identified, then they must be who they say they are. We depend on only one person having access to that particular "property". In the most common case, a user provides their username and matching password when prompted, either when they log onto a machine or when they access the resource. If these details are valid, the user has been identified - they are authenticated. Authorization Once we know who the user is, we can decide if they have permission to access the resource they requested. This is done in a range of ways, depending on the resource. In Windows-based systems most resources have an Access Control List (ACL), which lists the users that can access a resource. The list will usually also specify what kind of access each user has (e.g. whether they can read it, write to it, modify it, delete it, etc.) For example, if they request an ASP page, the operating system will check to see if they have Read access to the page. If so, it will allow IIS to fetch the page. However, IIS also has authorization settings that control what a user can do with a resource. If it's an ASP page, they will only be able to execute the script in that page if IIS has Script Execute permission set for the Web site, folder or page. So, in traditional ASP environments, you can see how several "layers" can be involved in the authorization process. If the identified user has permission to access the resource in the way that they've requested, the process succeeds: they have been authorized. If not, they receive an error message of some type, generated by the "layer" that refused them access to the resource. Impersonation There are times when a user will access a resource as though they were someone (or something) else. An example of this is when there is no access control in place for a Web page - in other words it allows any users to access it. In fact, this is an over-simplification, because Windows never allows anonymous access. All users must be authenticated and authorized using an existing account. For HTML pages, ASP pages, and components in version 3.0 and earlier, this is achieved through the two accounts named IUSR_machinename and IWAM_machinename. These accounts are set up when IIS is installed, and are automatically added to all the folders in every Web site on the server. If we allow anonymous access to a resource in IIS, every user will look the same - we won't be able to tell who is who. But we don't need to. When IIS receives a request for a Web page or other resource for which anonymous access is permitted, it uses the IUSR_machinename account to access the resources on the user's behalf. If the resource they request is an ASP page that uses a COM or COM+ component, that component (by default) is executed under the context of the IWAM_machinename account. In contrast, ASP.NET - when impersonation is turned off - makes all access to resources under the context of a special ASP.NET process account. When we turn impersonation on, ASP.NET executes every resource under the account of a specified user that we authenticate when they make the request. As in a COM+ application running under Windows 2000 or in MTS under Windows NT4, we can specify the account that will be used. If we specify the IUSR_machinename account, then ASP.NET will behave like previous versions of ASP, as far as the permissions required for accessing resources is concerned. One vital point to bear in mind is that the authentication process used by ASP.NET only applies to resources that are associated with ASP.NET. In other words, access control is only applied to files that are defined as "application" files in Internet Services Manager's Application Mappings dialog. By default this includes .aspx and .asax pages, .ascx components, .vb and .cs code files, Web Service files, and other resources that are mapped to aspnet_isapi.dll. It does not apply to resources such as images, Word documents, zip files, PDF files, and other types of file. These types of files must be protected using standard Windows techniques such as ACLs. You'll see all these topics discussed later in this chapter. Security Within ASP.NET From the preceding chapters, you'll have seen how many of the configuration settings you used to make within IIS under previous versions of ASP are now made through one or more instances of the new configuration file named web.config. This applies to most of the settings in the Internet Services Manager interface (within the MMC), because web.config replaces the metabase contents that this interface is used to manipulate. However, security settings made in IIS are still effective in many areas. This is because, unlike the configuration of application settings, custom errors, etc., IIS is still actively managing the request and performing the base security process in conjunction with the operating system itself. In effect, a request for an ASP.NET page is received by IIS, which uses the application mappings defined for the site containing that page to direct the request to ASP.NET. You can see the application mappings if you open the Application Configuration dialog from the Home Directory page of the Properties dialog for a site or directory in Internet Services Manager. The application mappings for all the ASP.NET resource types point to a file named aspnet_isapi.dll stored in the .NET frameworks folder: As you can see from the screenshot, the application mappings rely on file extensions. This is why you can still run existing ASP 3.0 pages on the same server as ASP.NET (they have a different file extension), and (of course) publish other resources such as HTML pages, zip files, documents, etc. which aren't processed by ASP.NET. If you hadn't realized it yet, this dialog proves that ASP.NET is an ISAPI DLL - as were ASP 3.0 and earlier. This DLL captures the request, processes it using managed code within the .NET Framework, and then passes the response back to IIS so it can be delivered to the client. So, IIS first authenticates a user, and then passes the request on to ASP.NET where it can perform its own security processes. The next schematic shows the overall flow of the request, and we'll briefly see how each part of the process is carried out in the following sections of this chapter. Authentication in Windows 2000 Windows 2000 maintains a list of users that are allowed to access resources on a machine. This is either stored on the machine itself, or on a domain controller elsewhere. The list is managed through the Computer Management tool, or through the Active Directory Users and Computers tool on a domain controller: You can see the IUSR and IWAM accounts in the previous screenshot that are used by IIS when anonymous access is enabled. Depending on the type of operating system and software you have installed, you'll probably see several other accounts listed as well. Within the list you can see an account with the username TestUser, which we created to experiment with the security features in ASP.NET and Windows 2000. User Groups The Properties dialog for this account shows that it is a member of two account groups - TestGroup and Users: All accounts are automatically added to the Users group, but we created a new group named TestGroup and added the TestUser account to it. You can see a list of groups in the Computer Management dialog as well: By allocating users to groups, we provide a way of minimizing the amount of work required to change permissions. For example, if we have 500 users who can access a particular set of resources, we can allocate them all to one group and then give that group permission to access those resources. The alternative would be to add all 500 users to each resource individually. And any changes to the permissions afterwards would mean changing them for all 500 users rather than just once for the group as a whole. Groups are also useful when we use "programmatic security". We can detect whether a user is a member of a specific group, and make decisions based on the result. This means that we don't have to hard-code all of the usernames into our application (just the group name), and we don't have to change the code to add or remove individual users. We just configure the group in the ACL for the resource to add users to, or remove them from the group. Authentication in IIS When a user requests a resource over the Web, IIS receives the request and performs the initial authentication of the user. IIS also performs other checks before deciding whether the user will be allowed access to the resource. We'll look at these next. IP Address and Domain Name Restrictions In Windows 2000 Server and Windows NT4 (but not Windows 2000 Professional), you can specify the IP addresses or domain names of clients that will be allowed access or denied access. This is achieved using the IP Address and Domain Name Restrictions dialog, available from the Directory Security page of the Properties dialog for a site or directory. This is useful if you always access the restricted site from a single machine, or if all your users come from a specific set of IP addresses or set of domains: Using Certificates to Authenticate Users You can also use the Properties dialog to set up server certificates that are to be used for a site or directory. As well as enabling secure communication through SSL, these certificates can be used in conjunction with client certificates to identify the machine that is accessing your server. For example, the following screenshot shows a configuration where the clients must provide a certificate to access the site. We've created a rule so that, if the organization that issued the certificate to the client is our own Certificate Server, the user will automatically be authenticated using the TestUser account we created earlier: You can also access the content of a client certificate using code in an ASP.NET page, through the Request.ClientCertificate collection. Specifying the Authentication Method [...]... application: ASP.NET Impersonation The first step within ASP.NET is to see if the application is configured to use impersonation This is a similar concept to the way that IIS impersonates users with its own IUSR account However, in this case, impersonation is used to decide whether the user's request should be executed under the context of their account, or that of the special account named ASPNET that ASP.NET. .. unique parts to play initially, as the request arrives at the server Afterwards, providing that access is not denied by IIS, the request is passed to ASP.NET for processing and fulfillment The ASP.NET Security Process The next schematic shows the process within ASP.NET in more detail After IIS has checked the user's IP address and domain to ensure that they are allowed access, it authenticates the user Remember... resource is only available if the account they are running under is valid for that resource If impersonation is not enabled in an ASP.NET application (the default) then: If anonymous access is enabled in IIS (the default) the request is made under the context of the special ASP.NET process account If anonymous access is not enabled in IIS, the request is made under the context of the authenticated user... they are running under is valid for that resource Other security checks are also possible within ASP.NET The availability of these checks depends on the type of security specified We'll overview the various options next, and look at these in more detail as we go through the chapter The ASP.NET Security Options ASP.NET provides a range of different options for implementing security and restricting user... Important Points When Using Security in ASP.NET Before we get too involved, however, there are a couple of things that we need to keep in mind when working with ASP.NET security: You don't have to change any of the default settings in Internet Services Manager, or change the permissions assigned to files or resources when using the security features that are configured for ASP.NET in the web.config file The... control is limited to that specified Default (IIS) authentication None within IIS Resources are accessed under the context of the special ASP.NET process account, or the IUSR account if impersonation is enabled To specify the type of authentication we want to use in an ASP.NET virtual application or virtual directory we provide the Name shown above in the section of the web.config... impersonation is enabled - in other words, whether to run under the user (or IUSR) account, the special ASP.NET process account, or a different account that you specify You'll see how we use these sections of the file when we look at each type of authentication in more detail next Using Windows Authentication in ASP.NET Windows authentication is best suited to situations like a corporate Intranet Web site... users="*" /> Running Under Another Specific Account Finally, we can instruct ASP.NET to access resources under a specific account, rather than the user account that was authenticated by IIS or the special ASP.NET process account (which is normally used when impersonation is not enabled) This is done within the element: ... Here we're specifying that impersonation is enabled but, instead of using the ASP.NET process account, ASP.NET should access all resources under the context of the domain-level account named MyUserName from the domain named MyDomainName We also have to provide the password for the account so that ASP.NET can present it to the operating system and other applications and services when it... being performed by ASP.NET Once IIS is happy with the user's request, it passes it to ASP.NET, where the first step is to see if there is an authentication cookie within the request headers: The forms authentication process generates this cookie when the user logs into the application If it's present, we know that they have already been authenticated and the cookie contains their identity ASP.NET then checks . Applications for Windows 200 0 (MS Press, ISBN 0- 7356 -09 95 -0) and Hacking Exposed - Second Edition (Osborne, ISBN: 0- 07- 212 748 -1) are useful. If in doubt, however, employ an experienced professional to. that of the special account named ASPNET that ASP. NET uses for anonymous requests. This is a confusing concept to grasp at first. The added complexity comes from the fact that ASP. NET uses the. designed for use with ASP. NET. The main topics of this chapter are:  An overview of the security model in Windows 200 0 and IIS  An overview of the new security features in ASP. NET  The different