In addition to the configurable settings that COM+ provides to administrators through the Component Services tool, developers often perform configuration- related functions in code. For example, the functions might retrieve object construction strings stored in the COM+ catalog. Consider these main issues when you use configuration management with Enterprise Services:
Use least privileged run-as accounts .
Avoid storing secrets in object constructor strings .
Avoid unconstrained delegation .
During development, run and test your service components using a least privileged local account instead of the interactive user account. Configure the account as closely as possible to match the run-as account that the administrator is likely to use in the production environment.
If you store secrets such as database connection strings or passwords in object constructor strings in the COM+ catalog, any member of the local administrators group can view this plaintext data. Try to avoid storing secrets. If you have to store a secret, then encrypt the data. DPAPI is a good implementation option because it allows you to avoid problems associated with key management.
At runtime, retrieve the object construction string and use DPAPI to decrypt the data. For more information about using DPAPI from managed code, see "How to create a DPAPI library" in MSDN article, "Building Secure ASP.NET Applications," at http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp .
[ConstructionEnabled(Default="")] public class YourServicedComponent : ServicedComponent, ISomeInterface { // The object constructor is called first. public YourServicedComponent() {} // Then the object construction string is passed to Construct method. protected override void Construct(string constructString) { // Use DPAPI to decrypt the configuration data. } }
Serviced component clients are authenticated with either NTLM or Kerberos authentication, depending on the environment. Kerberos in Windows 2000 supports delegation that is unconstrained; this means that the number of network hops that can be made with the client's credentials has no limit.
If ASP.NET is the client then you can set the comImpersonation attribute on the <processModel> element in Machine.config to configure the impersonation level:
comImpersonationLevel="[DefaultAnonymousIdentifyImpersonateDelegate]"
The impersonation level defined for an Enterprise Services server application determines the impersonation capabilities of any remote server that the serviced components communicate with. In this case, the serviced components are the clients.
You can specify the impersonation level for a serviced component, which applies when the service component is a client, using the following attribute:
[assembly: ApplicationAccessControl( ImpersonationLevel=ImpersonationLevelOption.Identify)]
Note | Using this attribute is equivalent to setting the Impersonation Level value on the Security page of the application's Properties dialog within Component Services. |
The following table describes the effect of each of these impersonation levels:
Impersonation Level | Description |
---|---|
Anonymous | The server cannot identify the client. |
Identify | This allows the server to identify the client and perform access checks using the client's access token |
Impersonate | This allows the server to gain access to local resources using the client's credentials |
Delegate | This allows the server to access remote resources using the client's credentials (this requires Kerberos and specific account configuration) |
For more information, see the "Impersonation" section in Chapter 17, "Securing Your Application Server" and "How to Enable Kerberos Delegation in Windows 2000" in the References section of MSDN article, "Building Secure ASP.NET Applications," at http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp .