AddThis Social Bookmark Button

Print

.NET Serviced Components
Pages: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11

Component-Level Access Checks

The component attribute ComponentAccessControl is used to enable or disable access checks at the component level. Recall from Chapter 7 that this is your component's role-based security master switch. The ComponentAccessControl attribute's constructor accepts a Boolean parameter, used to turn access control on or off. For example, you can configure your serviced component to require component-level access checks:

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

The ComponentAccessControl attribute has an overloaded default constructor that uses true for the attribute construction. Consequently, the following two statements are equivalent:

[ComponentAccessControl]
[ComponentAccessControl(true)]

Adding Roles to an Application

Related Reading

COM and .NET Component ServicesCOM and .NET Component Services
By Juval Lwy
Table of Contents
Index
Sample Chapter
Full Description

You can use the Component Services Explorer to add roles to the COM+ application hosting your serviced components. You can also use the SecurityRole attribute to add the roles at the assembly level. When you register the assembly with COM+, the roles in the assembly are added to the roles defined for the hosting COM+ application. For example, to add the Manager and Teller roles to a bank application, simply add the two roles as assembly attributes:

[assembly: SecurityRole("Manager")]
[assembly: SecurityRole("Teller")] 

The SecurityRole attribute has two public properties you can set. The first is Description. Any text assigned to the Description property will show up in the Component Services Explorer in the Description field on the role's General tab:

[assembly: SecurityRole("Manager",Description = "Can access all components")]
[assembly: SecurityRole("Teller",Description = "Can access IAccountsManager only")] 

The second property is the SetEveryoneAccess Boolean property. If you set SetEveryoneAccess to true, then when the component is registered, the registration process adds the user Everyone as a user for that role, thus allowing everyone access to whatever the role is assigned to. If you set it to false, then no user is added during registration and you have to explicitly add users during deployment using the Component Services Explorer. The SecurityRole attribute sets the value of SetEveryoneAccess by default to true. As a result, the following statements are equivalent:

[assembly: SecurityRole("Manager")]
[assembly: SecurityRole("Manager",true)] 
[assembly: SecurityRole("Manager",SetEveryoneAccess = true)]

Automatically granting everyone access is a nice debugging feature; it eliminates security problems, letting you focus on analyzing your domain-related bug. However, you must suppress granting everyone access in a release build, by setting the SetEveryoneAccess property to false:

#if DEBUG
[assembly: SecurityRole("Manager")]
#else
[assembly: SecurityRole("Manager",SetEveryoneAccess = false)]
#endif

Assigning Roles to Component, Interface, and Method

The SecurityRole attribute is also used to grant access for a role to a component, interface, or method. Example 10-13 shows how to grant access to Role1 at the component level, to Role2 at the interface level, and to Role3 at the method level.

Example 10-13: Assigning roles at the component, interface, and method levels

[assembly: SecurityRole("Role1")]
[assembly: SecurityRole("Role2")]
[assembly: SecurityRole("Role3")]
 
[SecurityRole("Role2")]
public 
interface IMyInterface
{  
   [SecurityRole("Role3")]  
   void MyMethod(  );
}
  
[SecurityRole("Role1")]
public class MyComponent :ServicedComponent,IMyInterface
{...}

Figure 10-2 shows the resulting role assignment in the Component Services Explorer at the method level. Note that Role1 and Role2 are inherited from the component and interface levels.

Figure 10-2.The resulting role assignment of Example 10-13 in the Component Services Explorer, as seen at the method level

 

If you only assign a role (at the component, interface, or method level) but do not define it at the assembly level, then that role is added to the application automatically during registration. However, you should define roles at the assembly level to provide one centralized place for roles description and configuration.

Verifying Caller's Role Membership

Sometimes it is useful to verify programmatically the caller's role membership before granting it access. Your serviced components can do that just as easily as configured COM components. .NET provides you the helper class SecurityCallContext that gives you access to the security parameters of the current call. SecurityCallContext encapsulates the COM+ call-object's implementation of ISecurityCallContext, discussed in Chapter 7. The class SecurityCallContext has a public static property called CurrentCall. CurrentCall is a read-only property of type SecurityCallContext (it returns an instance of the same type). You use the SecurityCallContext object returned from CurrentCall to access the current call. Example 10-14 demonstrates the use of the security call context to verify a caller's role membership, using the same use-case as Example 7-1.

Example 10-14: Verifying the caller's role membership using the SecurityCallContext class

public class Bank :ServicedComponent,IAccountsManager 
{   
   void TransferMoney(int sum,ulong accountSrc,ulong accountDest)   
   {      
      bool callerInRole = false;      
      callerInRole = SecurityCallContext.CurrentCall.IsCallerInRole("Customer");   
	  if(callerInRole)//The caller is a customer      
      {        
         if(sum > 5000)            
           throw(new UnauthorizedAccessException(@"Caller does not have sufficient 
                                              credentials to transfer this sum"));      
      }      
      DoTransfer(sum,accountSrc,accountDest);//Helper method
   }
   //Other methods
}

You should use the Boolean property IsSecurityEnabled of SecurityCallContext to verify that security is enabled before accessing the IsCallerInRole( ) method:

bool securityEnabled = SecurityCallContext.CurrentCall.IsSecurityEnabled;
if(securityEnabled)
{
   //the rest of the verification process
}

Pages: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11

Next Pagearrow