Design Considerations

Before you start writing code, there are a number of important issues to consider at design time. The key considerations are:

• Role-based authorization

• Sensitive data protection

• Audit requirements

• Application activation type

• Transactions

• Code access security

Role-Based Authorization

For effective role-based authorization using COM+ roles, ensure that the original caller's security context is used for the call to the serviced component. This allows you to perform granular role-based authorization based on the caller's group membership. If an ASP.NET Web application calls your serviced components , this means that the Web application needs to impersonate its callers before calling your component.

Sensitive Data Protection

If your serviced components handle sensitive data, such as employee details, financial transactions, and health records, consider how to protect the data as it crosses the network. If your application does not run in a secure Internet Data Center (IDC) environment, where IPSec provides transport level encryption, an alternative option is to use RPC encryption. For this you must use the Packet Privacy authentication level. For more information, see the "Sensitive Data" section later in this chapter.

Audit Requirements

To address the repudiation threat, sensitive transactions performed by Enterprise Service components should be logged. At design time, consider the type of operations that should be audited and the details that should be logged. At a minimum, this should include the identity that initiated the transaction and the identity used to perform the transaction, which may or may not be the same.

Application Activation Type

At design time, decide how your serviced component will be activated. You can activate them using an instance of the Dllhost.exe process or you can run them inside the client process. Server applications run out of process in an instance of Dllhost.exe. Library applications run in the client's process address space. Library applications are more efficient due to the lack of inter-process communication. However, they are less configurable and are not protected with process level isolation. Many security settings, such as the authentication and impersonation levels, are inherited from the client process.

Transactions

If you plan to use distributed transactions, consider where the transaction is initiated and consider the implications of running transactions between components and resource managers separated by firewalls. In this scenario, the firewall must be configured to support the Microsoft Distributed Transaction Coordinator (DTC) traffic.

If your physical deployment architecture includes a middle- tier application server, it is generally preferable to initiate transactions from the Enterprise Services application on the application server and not from the front-end Web application.

Code Access Security

Typically, applications that use serviced components are fully trusted, and as a result code access security has limited use to authorize calling code. However, Enterprise Services demands that the calling code has the necessary permission to call unmanaged code. The main implication of this is that you will not be able to directly call into an Enterprise Services application from a partial trust Web application. The ASP.NET partial trust levels (High, Medium, Low, and Minimal) do not grant the unmanaged code permission. If you need to call a serviced component from a partial trust application, the privileged code that calls your component must be sandboxed. For more information, see "Code Access Security Considerations" later in this chapter.