Design secure intranet applications to meet standards

Intranet applications have unique security characteristics that should be addressed during the design phase. Discover how engineering and security teams must work together to ensure intranet applications meet the established security standards.

By Tim Landgrave

The capabilities of the .NET Framework make it an ideal platform for intranet development. With built-in support for access to Active Directory and lightning fast access to SQL Server data using the SqlClient namespace, it’s much easier to develop robust, secure intranet applications using ASP.NET than with classic ASP.

But architects must still be concerned about implementing appropriate security mechanisms in their designs and about working with their engineering and security teams to make sure that their design works within their company’s security standards. Intranet applications have special characteristics that architects should consider when designing the security architecture.

Characteristics of intranet applications
Since companies have control over the browsers they support, it’s not uncommon for intranet applications to require an upper-level browser like Internet Explorer (IE) Version 4 and above. All versions of IE since Version 4 support NTLM authentication, which makes the security between the browser and the Web server much simpler to implement—as long as the company also supports Active Directory for its user accounts.

Most intranet applications should also assume that users are allowed to use the application only if they have been authenticated. Once authenticated, an intranet application should support access to data that’s specific to the authenticated user. This is where many security designs fall apart.

User specific data doesn’t mean unique user logins
One common mistake that architects make in their zeal to secure intranet systems is to assume that the same credentials used to gain access to the Web application should also be used to gain access to the underlying database. Although potentially useful for database auditing purposes, utilizing user credentials to authenticate against a back end database has disastrous performance ramifications.

This is because high performance ASP.NET applications depend on reusing database connections from a connection pool instead of re-creating them with each database call. Since database connections can be pooled only if they share the same connection string, and the connection string includes the user ID and password, database connections opened by multiple users cannot be placed in a pool and reused. For performance reasons, your intranet security design should assume that the application would make all calls to the database with the same user ID.

However, it’s not uncommon for a system’s business requirements to include an audit trail including which user requested certain actions to be performed. If your intranet application requires user-level auditing, then you should pass the user ID as part of the stored procedure used to execute data requests, and handle the auditing in the stored procedure.

For performance and security reasons, all requests to the database should be made in stored procedures instead of direct SQL Server queries with table and column names in the query. By using stored procedures, you can give ID permissions to the common application user for the stored procedures that are required to support the intranet application, but deny permissions to modify the tables directly. This gives you an additional level of control over the data required by your application.

Configuring the intranet environment
To configure the environment properly, you need to secure both the browser connection to the Web server and the Web server’s connection to the database. To secure the browser’s connection to the Web server, you should configure the Web server to use Integrated Windows Authentication and turn off anonymous access. This allows you to authorize the use of ASP.NET application files and other key resources by authenticated users only. To make administration easier, you should place the users into Windows groups and then use these groups when assigning Access Control Lists (ACLs) to the resources.

Securing the channel between the Web server and the database server is slightly more complex. Since you need to configure the ASP.NET account on the database server with a known password, you must change the default password from AutoGenerate to a strong password in the Machine.config file on the <processModel> attribute.

You should also set the password of the ASP.NET account to this same value by clicking on Local Groups And Users in Administrative Tools. To guarantee that the Web application uses Windows authentication when accessing the database server, you should edit the Web.Config file in your application's virtual directory so that the <authentication> element is set to mode=Windows. You should also set the <identity> element's impersonate attribute to equal false to ensure that impersonation is turned off. .

Once the Web server's ASP.NET account has a fixed password and you have configured the application's Web.config file to use this account when accessing the database, you need to configure the database server to use the same account. On the database server, go to Local Groups And Users and create a new account named ASP.NET, giving it the same password that you assigned on the Web server.

You must also give the account the following rights: Access This Computer From The Network, Deny Logon Locally, and Log On As A Batch Job. The SQL Server should be configured for Windows Authentication only. Now you can create a SQL Server Login for the ASP.NET account, create a new database user, and map that user's access to the application database. Give the user the right to execute stored procedures, but not direct access to the underlying tables in the database.

Once you have a pattern to follow when securing intranet applications, it becomes easier to write applications whose security can be easily maintained and monitored by the operations and data security departments. You should create and document similar security standards for other types of applications—extranet, Internet, etc.—that you create in your organization.

Editor's Picks