Configuration Management


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 .

Use Least Privileged Run-As Accounts

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.

Avoid Storing Secrets in Object Constructor Strings

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.   } } 

Avoid Unconstrained Delegation

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:

Table 11.1: 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 .




Improving Web Application Security. Threats and Countermeasures
Improving Web Application Security: Threats and Countermeasures
ISBN: 0735618429
EAN: 2147483647
Year: 2003
Pages: 613

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net