Security Architecture in Font

Creator Code-39 in Font Security Architecture

Whether you configure it carefully or not, your ASP .NET web applications will always have some kind of security in place. This is a consequence of the security architecture itself, which can be divided into three layers: The operating system: Unless you are using DOS or Windows 9x, there will always be some built-in security. Windows NT, 2000, and XP use domains to keep users information and to ensure that they have permission to access resources such as files and folders, printers, network shares, and so on. Users must always log in before using the system, and every request made by a user is checked for the necessary permission before it is allowed. The web server: A web server runs in the operating system, and as such, also uses the security infrastructure built into it. Even when Anonymous access is enabled for an application, it will actually be bound to the account specified for the anonymous user; by default, the IUSR_MACHINENAME account. The web application: When an ASP .NET application is run on IIS (there are alternatives, as there s a public ASP .NET hosting API), the security available in the previous two levels is always in effect, whether or not you explicitly decide to use it. At this level, you have some additional configuration options and features that ASP .NET offers over plain IIS settings, as you ll learn in this chapter.

Because they crop up so frequently in discussions about security, we need to clearly define two key terms: authentication and authorization. We ll also explain credential stores, security tokens, role-based security, principal, and identity. These refer to essential security concepts that you ll learn how to apply in this chapter.

In order for users to get access to a resource with restricted access, they must first be identified and authenticated. This means that they must provide some sort of identifier (such as a login name) and credentials (such as a password). Here, the login name allows them to say who they are, and the password allows them to prove that they are who they say they are. The way these credentials are validated depends on the authentication scheme you choose. ASP .NET offers several, and we ll discuss them in this chapter. Once users have been identified and their identification has been authenticated, another step known as authorization takes place. Here, the process consists of checking whether authenticated users have permission to access the resource they requested. For example, an ordinary user may not be allowed to access certain administrative features of a web application. As a side effect of authentication, an application may also provide customized content that s tailored to the current user accessing the resource. In fact, some applications will use security concepts with the sole aim of offering users an improved experience through personalization supplying content filtered according to their needs.

As we ve said, authentication is the process of positive identification of a user based on the credentials they supply. In order to perform this process, the credentials supplied by the user are compared to those existing in a credential store. Once again, the nature of the credential store depends on the type of authentication. For example, Windows authentication compares the credentials against a Windows domain. Passport sites such as Hotmail, MSN, McAfee, and others use the Microsoft-owned Passport credential store, which is in charge of the authentication. The credential store could also be a database, an XML file, or any other media that developers decide to use for this purpose. Later in this chapter, you ll learn which types of authentication are available for your ASP .NET applications. In order to allow a security-aware application to detect that the current user has already been authenticated, a security token is attached to that user. The security token is used to keep information about the user; again, its format and manner of use depend on the application. In a Windows environment, for example, this token is directly associated with the user while the user s session remains open. It is later used as a sort of key when the user performs an action such as opening a folder or printing a document; security settings on any of these objects may bar that user from accessing the resource. In a web environment, things are somewhat different, because of the disconnected and stateless nature of the HTTP protocol. Later in this chapter, we ll discuss how ASP .NET solves this problem. Once the user has been authenticated and the user s security token is in place, authorization happens. Once more, the association between a resource and the list of users allowed to access it depends on the specific application type or environment. For example, restrictions on access to files and folders in Windows are kept in access control lists (ACLs). These ACLs are set through the Security tab of the Properties window corresponding to the file or folder. Figure 10-1 shows an example of the security settings of a folder called MyArchive.