Where to Perform Authentication and Authorization

[Previous] [Next]

Where you have your security system perform authentication and authorization is an important issue because of the numerous ramifications of these decisions. In our example application architecture defined in Chapter 2, "A Process for Building Secure Web Applications," there are three possible locations at which to perform authentication and authorization:

• At the Web server, in which case IIS is the gatekeeper
• In the COM+ business components—COM+ is the gatekeeper
• In the Microsoft SQL Server database—SQL Server is the gatekeeper

A gatekeeper is a service that controls access to resources. Note that before deciding where authentication and authorization will occur you need to determine whether the user's identity originates from the Web server and whether the identity is application level or operating system level. We'll discuss these issues in "Application vs. Operating System Identity Flow," later in this chapter.

A Security Best Practice

A well-known security best practice is the leveraging of as much of the operating system's security capabilities as possible rather than the creation of your own. There are two reasons for doing this:

• Operating system security code is usually better tested and more secure than custom security code.
• The possibility of back-end servers, such as database servers and file servers, being attacked is minimized by operating system security.

Take a look at Figure 8-1. In this scenario, authentication and authorization is performed at the back-end database server. Regardless of how an attacker attempts to access the data, he will be denied access because the database server performs access checks.

Figure 8-1. An attacker is denied access to a database server that performs access checks.

In the next, less secure example, shown in Figure 8-2, the access checks are performed by the server in front of the database server—for example, a COM+ business rules server. Because the database server assumes that all connections come from the COM+ server and that the COM+ server performs the appropriate checks, an attacker might be able to bypass the COM+ server and access the database directly.

Figure 8-2. An attacker accesses a database server that relies on other servers to provide security services.

Here's an example of the less secure scenario that the authors have seen on more than one occasion: an intranet solution using an IIS server configured to utilize Integrated Windows authentication is built from Active Server Pages (ASP) pages querying a SQL Server database. The SQL Server database is configured to use standard security, rather than Windows authentication, and queries are made to SQL Server by passing the username as part of an SQL query.

The username is used to provide "authentication"—if the user account does not appear in the database User tables, the user is not granted access. "Authorization" is determined by evaluating which records the user account can access also based on their entry in the User table. The SQL code generated by the ASP pages and sent to SQL Server looks like this:

 strUser = Request.ServerVariables("AUTH_USER") strSQL = "SELECT Project.ProjectID, Project.ProjectName, " & _ "Status.Comment, User.UserName " & _ "FROM Project, User, UserProject, Status " & _ "WHERE User.UserName = '" & strUser & "'" & _ " AND UserProject.UserID = User.UserID " & _ " AND UserProject.ProjectID = Project.ProjectID " & _ " AND Status.StatusID = Project.StatusID" 

Notice how the first part of the WHERE clause adds the username to the SQL query.

NOTE

---

Note another security mistake in this SQL statement. The strUservariable is fed directly into the SQL string without checking its validity. Although the chance of a rogue value being used is slim, it's still good practice to check the validity of all external data before using it as part of an SQL statement. You can find more information on how to do this in Chapter 12, "Securing Against Attack."

The pertinent aspects of the data model in this example of weakened security are shown in Figure 8-3.

Figure 8-3. Part of a data model of a database containing sensitive project information.

In this case, the user account, gathered from IIS when the user is authenticated, is used to build up an SQL statement. When SQL Server receives the statement, it returns sensitive project status information available only to that user, because authorization is determined by row membership in the UserProject table.

The big security weakness in this example is the fact that SQL Server resides on the same network as the IIS server and hence can be accessed directly through the use of data access techniques such as open database connectivity (ODBC) and OLE DB. (OLE DB is a strategic system-level programming interface to data. Whereas ODBC was created to access relational databases, OLE DB was designed for relational and nonrelational information sources.) Through such access, a user can bypass all authentication and authorization checks made by IIS. For example, an attacker could build up an SQL string from, say, Microsoft Excel and, using ODBC, request and receive sensitive information. Assuming that IIS, which the user has just bypassed, is performing authentication, SQL Server performs no authentication steps of its own.

You can fix this problem a couple of different ways. First, you can place the SQL Server computer on a private network and make it accessible from the IIS server only. You do this by adding a second network card to the Web server, using a private subnet between the two servers, and disabling routing on the Web server computer. Figure 8-4 shows this scenario.

Figure 8-4. A Web server that contains two network cards: one listening on IP address 207.46.131.137 for Internet traffic, and the other using IP address 10.0.0.43 for communicating with SQL Server.

Second, you can use Internet Protocol Security (IPSec) and configure the SQL Server computer to allow communication between only the Web server and any administration servers.

Finally, you can perform security checks in the database rather than assume that the Web server is performing all the work.

The moral of this story? Perform operating system-level authentication and authorization in the database servers, if possible. This will require that you flow the user's identity from the Web server through the middle COM+ layers to the back-end data sources. Until Microsoft Windows 2000, this was a problem because the Windows NT Challenge/Response authentication protocol does not support delegation. (Delegation was discussed in Chapter 3, "Windows 2000 Security Overview," and will be covered in more detail in Chapter 10, "Building a Secure Solution.") However, Windows 2000 supports Kerberos authentication, and Kerberos supports delegation.

You might choose not to use operating system-level identity flow if you can trust the resilience of the servers behind the Web server and rely solely on identity information gathered by the Web server. Nevertheless, you should make sure those COM+ servers and SQL Server servers are well protected and you trust the people administering them.