While in and out are built-in attributes that the MIDL compiler supports, .NET allows you to create your own custom attributes by deriving from the System.Attribute class. Here’s an example of a custom attribute:

using System;

public enum Skill {  Guru, Senior, Junior }[AttributeUsage(AttributeTargets.Class      | 
                  AttributeTargets.Field      |
                  AttributeTargets.Method     |
                  AttributeTargets.Property   |
                  AttributeTargets.Constructor|
                  AttributeTargets.Event)]
                  public class AuthorAttribute : System.Attribute 
{   
  public AuthorAttribute(Skill s)
  {
    level = s;
  }
  public Skill level;
}

The AttributeUsage attribute that we’ve applied to our AuthorAttribute class specifies the rules for using AuthorAttribute.^[29] Specifically, it says that AuthorAttribute can prefix or describe a class or any class member.

Given that we have this attribute, we can write a simple class to make use of it. To apply our attribute to a class or a member, we simply make use of the attribute’s available constructors. In our case, we have only one and it’s AuthorAttribute( ), which takes an author’s skill level. While you can use AuthorAttribute( ) to instantiate this attribute, .NET allows you to drop the Attribute suffix for convenience, as shown in the following code listing:

[Author(Skill.Guru)]
public class Customer
{[Author(Skill.Senior)]
  public void Add(string strName)
  {
  }[Author(Skill.Junior)]
  public void Delete(string strName)
  {
  }
}

You’ll notice that we’ve applied the Author attribute to the Customer class, telling the world that a guru wrote this class definition. This code also shows that a senior programmer wrote the Add( ) method and that a junior programmer wrote the Delete( ) method.

You will not see the full benefits of attributes until you write a simple interceptor-like program, which looks for special attributes and provides additional services appropriate for these attributes. Examples of real interceptors are marshaling, transaction, security, pooling, and other services in MTS and COM+.

Here’s a simple interceptor-like program that uses the Reflection API to look for AuthorAttribute and provide additional services. You’ll notice that we can ask a type, Customer in this case, for all of its custom attributes. In our code, we ensure that the Customer class has attributes and that the first attribute is AuthorAttribute before we output the appropriate messages to the console. In addition, we look for all members that belong to the Customer class and check whether they have custom attributes. If they do, we ensure that the first attribute is an AuthorAttribute before we output the appropriate messages to the console.

using System.Reflection;

public class interceptor
{
  public static void Main(  ) 
  {Object[] attrs = typeof(Customer).GetCustomAttributes(false);
                  if ((attrs.Length > 0) && (attrs[0] is AuthorAttribute))
    {
      Console.WriteLine("Class [{0}], written by a {1} programmer.", 
          typeof(Customer).Name, ((AuthorAttribute)attrs[0]).level);
    }

    MethodInfo[] mInfo = typeof(Customer).GetMethods(  );
    for ( int i=0; i < mInfo.Length; i++ )
    {
      attrs = mInfo[i].GetCustomAttributes(false);if ((attrs.Length > 0) && (attrs[0] is AuthorAttribute))
      {
        AuthorAttribute a = (AuthorAttribute)attrs[0];
        Console.WriteLine("Method [{0}], written by a {1} programmer.", 
            mInfo[i].Name, (a.level));if (a.level == Skill.Junior)
        {Console.WriteLine("***Performing automatic " +
                  "review of {0}'s code***", a.level);
        }
      }
    }           
  }
}

It is crucial to note that when this program sees a piece of code written by a junior programmer, it automatically performs a rigorous review of the code. If you compile and run this program, it will output the following to the console:

Class [Customer], written by a Guru programmer.
Method [Add], written by a Senior programmer.Method [Delete], written by a Junior programmer.
                  ***Performing automatic review of Junior's code***

While our interceptor-like program doesn’t intercept any object-creation and method invocations, it does show how a real interceptor can examine attributes at runtime and provide necessary services stipulated by the attributes. Again, the key here is the last boldface line, which represents a special service that the interceptor provides as a result of attribute inspection.

In order to demonstrate role-based security, let’s add two roles to our COM+ application, .NET Essentials CRM. The first role represents Agents who can use the Customer class in every way but can’t delete customers. You should create this role and add to it the local Users group, as shown in Figure 4-6. The second role represents Managers who can use the Customer class in every way, including deleting customers. Create this role, and add to it the local Administrators group.

Figure 4-6. Creating roles and adding users to roles

Once you’ve created these roles, you need to enable access checks for the .NET EssentialsCRM COM+ application. Launch the COM+ application’s Properties sheet (by selecting .NET Essentials CRM and pressing Alt-Enter), and select the Security tab. Enable access checks to your COM+ application by providing the options as shown in Figure 4-7.

Figure 4-7. Enable authorization for this COM+ application

Once you have enabled access checks at the application level, you need to enforce access checks at the class level too. To do this, launch Customer’s Properties sheet, and select the Security tab. Enable access checks to this .NET class by providing the options shown in Figure 4-8. Here, we’re saying that no one can access the Customer class except for those that belong to the Manager or Agent role.

Figure 4-8. Enforce class-level access checks

Now, if you run the client application developed in the last section, everything will work because you are a user on your machine. But if you uncheck both the Manager ^[32] and Agent roles in Figure 4-8 and rerun the client application, you get the following message as part of your output:

System.UnauthorizedAccessException: Access is denied.
   at Client.Main(  )

You’re getting this exception because you’ve removed yourself from the roles that have access to the Customer class. Once you’ve verified this, put the configuration back to what is shown in Figure 4-8 to prepare the environment for the next test that we’re about to illustrate.

We’ve allowed anyone in the Agent and Manager roles to access our class, but let’s invent a rule allowing only users under the Manager role to delete a customer from the system (for lack of a better example). So let’s add a new method to the Customer class—we’ll call this method Delete( ), as shown in the following code. Anyone belonging to the Agent or Manager role can invoke this method, so we’ll first output to the console the user account that invokes this method. After doing this, we’ll check to ensure that this user belongs to the Manager role. If so, we allow the call to go through; otherwise, we throw an exception indicating that only managers can perform a deletion. Believe it our not, this is the basic premise for programming role-based security.

[AutoComplete]  
public void Delete(string strName)
{
  try
  {
    SecurityCallContext sec;
    sec = SecurityCallContext.CurrentCall;
    string strCaller = sec.DirectCaller.AccountName;Console.WriteLine("Caller: {0}", strCaller);   
                  bool bInRole = sec.IsCallerInRole("Manager");
    if (!bInRole)
    {
      throw new Exception ("Only managers can delete customers.");
    }

    Console.WriteLine("Delete customer: {0}", strName);

    // Delete the new customer from the system,
    // and make appropriate updates to 
    // several databases.
  }
  catch(Exception e)
  {
    Console.WriteLine(e.ToString(  ));
  }
}

Here’s the client code that includes a call to the Delete( ) method:

using System;

public class Client 
{
  public static void Main(  ) 
  {
    try
    {
      Customer c = new Customer(  );
      c.Add("John Osborn");
      // Success depends on the role
      // under which this this method
      // is invoked.
      c.Delete("Jane Smith");
    }
    catch(Exception e)
    {
      Console.WriteLine(e.ToString(  ));
    }
  }
}

Once you’ve built this program, you can test it using an account that belongs to the local Users group, since we added this group to the Agent role earlier. On Windows 2000, you can use the following command to launch a command window using a specific account:

runas /user:dog	huant cmd

Of course, you should replace dog and thuant with your own machine name and user account, respectively. After running this command, you will need to type in the correct password, and a new command window will appear. Execute the client under this user account, and you’ll see the following output:

Add customer: John OsbornCaller: DOG	huant
                  System.Exception: Only managers can delete customers.
   at Customer.Delete(String strName)

You’ll notice that the Add( ) operation went through successfully, but the Delete( ) operation failed because we executed the client application under an account that’s missing from the Manager role.

To remedy this, we need to use a user account that belongs to the Manager role—any account that belongs to the Administrators group will do. So, start another command window using the following command:

runas /user:dogadministrator cmd

Execute the client application again, and you’ll get the following output:

Add customer: John Osborn
Caller: DOGAdministrator
Delete customer: Jane Smith

As you can see, since we’ve executed the client application using an account that belongs to the Manager role, the Delete( ) operation went through without problems.