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:
Server object, ASP 0178 (0x80070005)
The call to Server.CreateObject failed while checking permissions. Access is denied to this object.
/grid33/test.asp, line 29
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.
|
IMPORTANT: AspGrid enforces role-based security
only if the respective role is present in your COM+ application. For example,
if the role CanDelete has not been added to your COM+ application,
everyone will be allowed to delete. However, once you add this role,
only users assigned to it will be allowed to delete.
|
The following pseudo-code describes the algorithm AspGrid uses:
If ObjectContext.IsSecurityEnabled Then
If RoleExists("CanAppend") Then
If Not ObjectContext.IsCallerInRole("CanAppend") Then
Grid.CanAppend = False
End If
End If
If RoleExists("CanDelete") Then
If Not ObjectContext.IsCallerInRole("CanDelete") Then
Grid.CanDelete = False
End If
End If
If RoleExists("CanEdit") Then
If Not ObjectContext.IsCallerInRole("CanEdit") Then
Grid.CanEdit = False
End If
End If
End If
