View source for ASP.NET 1.1 - Enterprise Services to SQL Server

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, and Prashant Bansode


== Applies To ==
* ASP.NET 1.1
* Enterprise Services (.NET 1.1)



== Scenario ==
In this scenario, ASP.NET pages call business components hosted in an Enterprise Services application that in turn connects to a database. As an example, consider an internal purchase order system that uses transactions over the intranet and allows internal departments to place orders.

[[image:IntranetEntServicesToSQLServer.gif]]



== Characteristics ==
This scenario has the following characteristics: 
* Users have Internet Explorer. 
* Components are deployed on the Web server. 
* The application handles sensitive data that must be secured while in transit. 
* Business components connect to SQL Server using Windows authentication. 
* Business functionality within these components is restricted based on the identity of the caller. 
* Serviced components are configured as a server application (out-of-process). 
* Components connect to the database using the server application's process identity. 
* Impersonation is enabled within ASP.NET (to facilitate Enterprise Services role-based security). 



== Solution ==
ASP.NET calls a component within Enterprise Services, which calls the database.

[[image:IntranetEntServicesToSQLServerSolution.gif]]



== Web Server ==
IIS
* Disable Anonymous access for your Web application's virtual root directory
* Enable Integrated Windows Authentication


ASP.NET
<ul>
<li>Configure your ASP.NET Web application to use Windows authentication.  Edit Web.config in your application's virtual directory root.  Set the <authentication> element to:
<pre>
 <authentication mode="Windows" />
</pre>
</li>
<li>Configure your ASP.NET Web application for impersonation Edit Web.config in your Web application's virtual directory.  Set the <identity> element to:
<pre>
 <identity impersonate="true" />
</pre>
</li>
<li>Configure ASP.NET DCOM security to ensure that calls to Enterprise Services support caller impersonation. Edit Machine.config and locate the <processModel> element. Confirm that the comImpersonationLevel attribute is set to Impersonate (this is the default setting)
<pre>
 <processModel 
    comImpersonationLevel="Impersonate"
</pre>
</li>
</ul>


Enterprise Services
<ul>
<li>Create a custom account for running Enterprise Services. Note - If you use a local account, you must also create a duplicate account on the SQL Server computer.
</li>
<li>Configure the Enterprise Services application as a server application. This can be configured using the Component Services tool, or via the following .NET attribute placed in the service component assembly.
<pre>
 [assembly:
  ApplicationActivation(ActivationOption.
  Server)]
</pre>
</li>
<li>Configure Enterprise Services (COM+) roles. Use the Component Services tool or script to add Windows users and/or groups to roles. Roles can be defined using .NET attributes within the serviced component assembly.
</li>
<li>Configure Enterprise Services to run as your custom account. This must be configured using the Component Services tool or script. You cannot use .NET attributes within the serviced component assembly.
</li>
</ul>



== Database Server ==
* Create a Windows account on your SQL Server computer that matches the Enterprise Services process account The user name and password must match your custom Enterprise Services account.  Give the account the following privileges: 
* Access this computer from the network 
* Deny logon locally 
* Log on as a batch job 
* Configure SQL Server for Windows authentication
* Create a SQL Server Login for your newly created account. This grants access to the SQL Server.
* Create a new database user and map the login name to the database user.  This grants access to the specified database.
* Create a new database user role and add the database user to the role.
* Establish database permissions for the database user role. Grant minimum permissions.



== Communications Security ==
* Configure the Web site for SSL.
* Configure IPSec between Web server and database server.



== Analysis ==
* ASP.NET and Enterprise Services are running as least privileged accounts, so potential damage from compromise is mitigated. If either process identity were compromised, the account's limited privileges reduce the scope of damage. Also, in the case of ASP.NET, if malicious script were injected, potential damage is constrained. 
* The ASP.NET application must be configured for impersonation in order to flow the security context of the original caller to the Enterprise Services components (to support Enterprise Services (COM+) role-based authorization). If you do not impersonate, role checks are made against the process identity (that is, the ASP.NET worker process). Impersonation affects who you authorize resources against. 
* Without impersonation, system resource checks are against the ASP.NET process identity. With impersonation, system resource checks are made against the original caller. 
* By using Enterprise Services (COM+) roles, access checks are pushed to the middle tier, where the business logic is located. In this case, callers are checked at the gate, mapped to roles, and calls to business logic are based on roles. This avoids unnecessary calls to the back end. Another advantage of Enterprise Services (COM+) roles is that you can create and administer roles at deployment rime, using the Component Services Manager. 
* Windows authentication to SQL means you avoid storing credentials in files and sending them across the network. 
* The use of a local account to run the Enterprise Services application, together with a duplicated account on the database server, also works in the presence of a firewall where the ports required for Windows authentication may not be open. The use of Windows authentication and domain accounts may not work in this scenario



== Pitfalls ==
* The use of a duplicated Windows account on the database server (one that matches the Enterprise Services process account) results in increased administration. Passwords should be manually updated and synchronized on a periodic basis. 
* Because .NET role-based security is based on Windows group membership, this solution relies on Windows groups being set up at the correct level of granularity to match the categories of users (sharing the same security privileges) who access the application.
 
 
 
[[Category: Application Scenarios]]

__NOTOC__