Export (0) Print
Expand All

COM+ Role-Based Security and the .NET Framework 

The .NET Framework provides mechanisms to integrate managed code with COM+ security services. This functionality relies on the Windows NT token associated with executing code as the basis for identity.

Role-Based Security

Role-based security allows you to define roles for an application, so that authorization to the application either at the component, method, or interface level is done based on membership in these roles. Both COM+ and the .NET Framework allow you to define application-level roles. The .NET Framework and COM+ role-based security mechanisms are independent, and you can use only one mechanism within a single application.

COM+ security relies on Windows NT accounts and process/thread impersonation. If the managed code provides authentication services, it must obtain a Windows NT security token and do an impersonation before calling any COM objects.

Application and Component Access Control

COM+ allows you to enable security at either the application level or the class level. Application-level security is set using the ApplicationAccessControlAttribute attribute, as shown in the following sample code.

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

You configure the granularity of access checking for an application by using either the Application or ApplicationComponent property. The former enables access checks only at the application level. No access checks are made at the component, interface, or method level. If the caller is a member of at least one role that is defined in the application, the call to any object, interface, or method succeeds. The latter enables access checks at every level. Using ApplicationComponent is much more useful, because it indicates that role-based access checks are applied at the component, interface, and method levels.

Using the ApplicationComponent property only enables component-level access checks. To actually ensure that access checks are performed for a specific component, you must use the ComponentAccessControlAttribute attribute.

Component-level security can be enabled by using the ComponentAccessControlAttribute attribute. This attribute can be applied to a class (as shown in the following sample code), to an interface, or to a method.

[ComponentAccessControl(true)]
public class CreditAccount : ServicedComponent
{
}

Before setting security for a component, you must enable security for the application that hosts the component. Access checks occur only if you apply the ApplicationAccessControlAttribute attribute to the assembly and set the ApplicationAccessControlAttribute attribute to ApplicationComponent.

The level at which security control is enabled determines when a caller's role membership is checked. The following table describes how caller role membership is checked depending on whether application security or component security is enabled.

Application security Component security When role membership is checked

Enabled

Disabled

Role membership is checked each time the caller access the application.

Enabled

Enabled

Role membership is checked for any class for which class-level security is enabled, in addition to the application-level access check. The component-level setting enables role-based security at the class, interface, and method level.

Disabled

Enabled/Disabled

Disables security for all classes in the application.

Adding Roles to an Application

You can add roles to an application and associate the roles with components by using the SecurityRoleAttribute attribute, as shown in the following sample code.

[SecurityRole("Teller", Description="Bank teller role")]
public class CreditAccount : ServicedComponent
{
}

This attribute enables you to create roles and assign roles to membership requirements for an application, component, interface, or method. Applying this attribute to an assembly as a whole ensures that the role exists in the COM+ catalog. When you apply this attribute to a component, it ensures that the role exists in the application configuration and associates the target component with the role.

If the SetEveryoneAccess property is set to true, the role Everyone is added as a member. The default is false, which means there are no users assigned to a role. Instead, you must configure them manually.

Security roles are supported at the assembly, class, method, and interface levels. As with other method attributes, security configuration is not currently shared between interface definition and method implementation.

The SecurityCallContext class provides access to COM+ security call context, and is similar but not identical to the SecurityCallContext object in Visual Basic. New instances are not created programmatically but obtained through the CurrentCall property. The remaining properties, described in the following table, call methods on the SecurityCallContext object.

Property Remark

Callers

Retrieves the Callers item from the SecurityCallContext object in COM+ and returns the item as a SecurityCallers object.

CurrentCall

Returns a reference to a SecurityCallContext object associated with the current call.

DirectCaller

Retrieves the DirectCaller item from the SecurityCallContext object in COM+ and returns the item as a SecurityIdentity object.

MinAuthenticationLevel

Retrieves the MinAuthenticationLevel item from the SecurityCallContext object in COM+.

NumCallers

Retrieves the NumCallers item from the SecurityCallContext object in COM+.

OriginalCaller

Retrieves the OriginalCaller item from the SecurityCallContext object in COM+ and returns the item as a SecurityIdentity object.

See Also

Community Additions

ADD
Show:
© 2014 Microsoft