Chapter 12. Using COM+ Role-based Security

AspGrid is a COM component. Starting from version 3.0, AspGrid is also an MTS component, i.e. it is specifically designed to run under MTS (Microsoft Transaction Server). Windows 2000 combines COM and MTS into a single technology known as COM+, and MTS is from now on called Component Services. AspGrid can and should be registered under MTS/Component Services. See Chapter 1 for instructions on how to do it.

Among many other things, COM+ offers component security in the form of client authorization via the mechanism of roles.

A COM+ Role is an abstraction that represents a group of users sharing the same security privilege. Within a COM+ application (formerly known as MTS package) where a COM+ component is registered, you can create one or more roles specific to your application's security policy and assign user and group accounts to those roles. Members of a role can then be granted (or denied) access to your component as a whole, or certain methods exposed by the component, thereby enforcing your security policy.

Some COM+ components are pre-programmed to check at run-time whether or not the current client belongs to a certain role, and depending on that take some action (such as perform or omit a database UPDATE). AspGrid uses this approach.

The security requirements of your AspGrid-based application may warrant that certain individuals should only be given read-only access to the underlying data. Other users should be allowed to modify existing records but not delete or add new ones. Still others can add new records, but not modify or delete existing ones. And, of course, the lucky few with the highest privilege level should have full read/write access to the data.

The Grid object provides three properties, Grid.CanEdit, Grid.CanDelete and Grid.CanAppend, that can be used to disable the control buttons "Edit", "Delete" and "Add New", respectively, thereby enforcing the security constraints imposed on a user.

Accordingly, AspGrid is programmed to recognize three COM+ roles: CanDelete, CanEdit and CanAppend. A user can be included in any or all of these roles. For example, if the user jsmith is included in the CanDelete role, she will be allowed to perform deletions. However, if the role CanDelete is present but jsmith is not included in it, AspGrid will force the CanDelete property to False and, as a result, there will be no Delete buttons on the grid for jsmith to use.

Go to Start/Settings/Control Panels/Administrative Tools and fire up Component Services. If you have not done so already, create a new COM+ application and add AspGrid.dll to it as described in Chapter 1. Right-click on the newly created application and choose Properties. On the Security tab, check the box "Enforce access checks for this application":

If you now try to run any ASP script that calls AspGrid, you will most probably receive the following error:

This is COM+ security in action. We enabled access check on the application but created no roles and therefore did not grant anyone access to the object. To fix this error, we will create a new role and call it everyone (the role name is not important in this particular case). Highlight the Roles node, right-click on it and select "New->Role". Enter "everyone" in the popup dialog. Expand the node "everyone", highlight the node Users underneath it, right-click on it and select "New->User". Select the user account Everyone from the "Select Users or Groups" dialog and click OK.

We now need to associate the role everyone with our component to avoid the access denied error described above. Highlight the node Persits.Grid.1 under Components, right-click on it and select Properties. On the Security tab, check the box "Enforce component level access checks" and also the box "everyone" underneath it:

We must shut down the COM+ application for these changes to take effect. Right-click on the AspGrid application and choose "Shut down". Now we should be able to run our ASP script without an error.

It may seem like we went through all these trouble just to fix something that was not broken to begin with. However, what we actually did was switch on COM+ security around the AspGrid component, and at the same time enable everyone to create the AspGrid object. It is database updates that we want to put restraints on, not object creation.

Now let us create the three roles that AspGrid recognizes: CanAppend, CanDelete and CanEdit. Once the roles are created, shut down the application again and re-run your ASP script. If everything was done properly, AspGrid should come up with no Delete, Edit or Add New buttons as we have not added any actual users to our roles, so everyone is denied all three privileges.

If you have Anonymous access enabled for your virtual directory, the ASP script (and, therefore, AspGrid) will run under the user account IUSR_MACHINE. If you add this user account to any or all of the three roles, AspGrid will respond by displaying the respective control buttons, thereby allowing the user to perform the updates she is entitled to.

If your ASP script is protected by Basic or NTLM authentication, AspGrid will run under the currently logged-in user (such as your login account) and not IUSR_MACHINE, so you will need to add that account to the roles to make AspGrid show its control buttons.

Note that roles can be associated not only with users, but also with groups.

The following pseudo-code describes the algorithm AspGrid uses:

MTS under NT4 apparently works differently from Component Services in Windows 2000. The MTS Role-based security is enabled by default, which means you do not need to go through the trouble of creating an everyone role and adding the Everyone user account to it. Create an MTS package, register AspGrid.dll in it and create the three roles (CanEdit, CanAppend and CanDelete). Then populate the roles with user accounts as appropriate.

In many cases, your Web server will be running multiple instances of AspGrid. Conceivably, every instance will require its own security policy, and therefore, its own set of COM+ roles. By default, the Grid object looks for the COM+ roles CanEdit, CanAppend and CanDelete.

Setting the property Grid.RoleExt to a string extension makes AspGrid look for the roles CanEditExt, CanAppendExt and CanDeleteExt instead. For example, the line

makes this instance of AspGrid use the roles CanEdit2, CanAppend2 and CanDelete2. This way you can implement multiple security policies on the same server.