A Word about Security

There are a few different aspects of security you need to consider when developing a Logi application, including database server security, web server (IIS) security, and ASP.NET security.

First, let's address database security when using Microsoft SQL Server. If a user ID and password are included in the Connection String (defined in the Connection.SQL element in the _settings definition), then the specified credentials are used to access the database using SQL Server Authentication.

Hint: These SQL Server credentials are for SQL Server Authentication, not Windows Authentication.    

Otherwise, if the Connection String specifies integrated security (“Integrated Security=SSPI”), then the web application security credentials are used to access the database using Windows Authentication.

Hint: The “Trusted_Connection=Yes” or “Trusted_Connection=True” or “Integrated Security=True” connection string attributes are all equivalent.  Also, integrated security only applies to Microsoft SQL Server.    

But, what are the “web application security credentials”?

By default, the web application security identity is configured to execute the web application with the default ASP.NET Windows NT user account: <user_machine>\ASPNET

So, when the connection string specifies integrated security, the default ASP.NET Windows NT user account must have access to any database accessed by a report. In most production environments, this user account doesn’t have access to the database.

Hint: In a development and test environment, the default ASP.NET Windows NT user account is often given access to the database server.    

At this point, we have the following options:

• Grant access to the database to the default ASP.NET Windows NT user account (not recommended)
• “Impersonate” a user account with access to the database (recommended). But, how do we impersonate a user account?

To execute the web application under the identity of the current authenticated user, locate the web.config file for your Logi application (it’s in the application project folder) and, using a text editor like Notepad, add the following XML element to it:

<identity impersonate="true" />

For anonymous access, the user account credentials configured in the IIS management console are used to access the database. Otherwise, the credentials of the currently authenticated user account are used to access the database.

Web server security is configured using the IIS Manager tool. Select the Logi application’s virtual directory in the console. By default, the virtual directory is located in the IIS tree view panel under the Default Web Site node (i.e. Internet Information Services -> (local computer) -> Web Sites -> Default Web Site -> MyFirstApplication).

Right-click the application's virtual directory and select the Properties menu item. Select the Directory Security tab. Select the Edit command in the Anonymous access and authentication control panel on the Directory Security tab. Confirm Anonymous access is enabled. The web security identity is configured in the Anonymous access panel.

Figure 2.19:  Anonymous Access and Authentication Control dialog box for IIS 6.0 

Note that the dialog box shown above may be arranged slightly differently depending on which version of IIS you’re using.

By default, the account used for anonymous access to the web site is IUSR_<user_machine>. Like the default ASP.NET Windows NT user account, in most production environments, this user account doesn’t have access to the database.

At this point, we have the following options:

• Grant access to the database to the account used for anonymous access (not recommended)
• Change the account used for anonymous (not recommended)
• Impersonate a user account with access to the database (recommended). But, how do we impersonate a specific user account?

To execute the web application under the identity of a specific user, locate the web.config file for your Logi application (it’s in the application project folder) and, using a text editor like Notepad, add the following XML element to it:

<identity impersonate="true" 
          userName="<user_name>" 
          password="<user_password>" />


There is no single security approach that is perfect for all environments. But, in most production environments, I recommend using integrated security and impersonating a specific “application” user with access to the database server and any other necessary resources.