Serviced Components

This section identifies the key review points that you should consider when you review the serviced components used inside Enterprise Services applications. For more information about the issues raised in this section, see Chapter 11, "Building Secure Serviced Components."

Do you use assembly level metadata?
Do you prevent anonymous access?
Do you use a restricted impersonation level?
Do you use role-based security?
Do you use method level authorization?
Do you use object constructor strings?
Do you audit in the middle tier ?

Do You Use Assembly Level Metadata?

Check that you use assembly level metadata to define Enterprise Services security settings. Use the assemblyinfo.cs file and use attributes to define authentication and authorization configuration. This helps to ensure that the settings are established correctly at administration time. Although the administrator can override these settings, it provides the administrator with a clear definition of how you expect the settings to be configured.

Do You Prevent Anonymous Access?

Check that your code specifies an authentication level using the ApplicationAccessControl attribute. Search for the "AuthenticationOption" string to locate the relevant attribute. Check that you use at least call-level authentication to ensure that each call to your component is authenticated.

 [assembly: ApplicationAccessControl(                        Authentication = AuthenticationOption.Call)]

Do You Use a Restricted Impersonation Level?

The impersonation level you define for your serviced components determines the impersonation capabilities of any remote server that you communicate with. Search for the "ImpersonationLevel" string to check that your code sets the level.

 [assembly: ApplicationAccessControl(               ImpersonationLevel=ImpersonationLevelOption.Identify)]

Check that you set the most restricted level necessary for the remote server. For example, if the server needs to identify you for authentication purposes, but does not need to impersonate you, use the identify level as shown above. Use delegation-level impersonation with caution on Windows 2000 because there is no limit to the number of times that your security context can be passed from computer to computer. Windows Server 2003 introduces constrained delegation.

Note	In Windows Server 2003 and Windows 2000 Service Pack 4 and later, the impersonation privilege is not granted to all users.

If your components are in a server application, the assembly level attribute shown above controls the initial configuration for the component when it is registered with Enterprise Services.

If your components are in a library application, the client process determines the impersonation level. If the client is an ASP.NET Web application, check the comImpersonationLevel setting on the <processModel> element in the Machine.config file.

Do You Use Role-Based Security?

Check that your code uses role-based security correctly to prevent unauthorized access by reviewing the following questions:

Is role-based security enabled?

Check that role-based security is enabled. It is disabled by default on Windows 2000. Check that your code includes the following attribute:
```
 [assembly: ApplicationAccessControl(true)] 
```
Do you use component level access checks?

COM+ roles are most effective if they are used at the interface, component, or method levels and are not just used to restrict access to the application. Check that your code includes the following attribute:
```
 [assembly: ApplicationAccessControl(AccessChecksLevel=                AccessChecksLevelOption.ApplicationComponent)] 
```
Also check that each class is annotated with ComponentAccessControl attribute as follows :
```
 [ComponentAccessControl(true)] public class YourServicedComponent : ServicedComponent { } 
```
Do you perform role checks in code?

If your method code calls ContextUtil.IsCallerInRole , check that these calls are preceded with calls to ContextUtil.IsSecurityEnabled . If security is not enabled, IsCallerInRole always returns true . Check that your code returns a security exception if security is not enabled.

Do You Use Object Constructor Strings?

Search your code for "ConstructionEnabled" to locate classes that use object construction strings.

 [ConstructionEnabled(Default="")] public class YourServicedComponent : ServicedComponent, ISomeInterface

If you use object constructor strings, review the following questions:

Do you store sensitive data in constructor strings?

If you store data such as connection strings, check that the data is encrypted prior to storage in the COM+ catalog. Your code should then decrypt the data when it is passed to your component through the Construct method.
Do you provide default construction strings?

Do not do this if the data is in any way sensitive.

Do You Audit in the Middle Tier

You should audit across the tiers of your distributed application. Check that your service components log operations and transactions. The original caller identity is available through the SecurityCallContext object. This is only available if the security level for your application is configured for process and component-level checks by using the following attribute:

 [assembly: ApplicationAccessControl(AccessChecksLevel=                AccessChecksLevelOption.ApplicationComponent)]