Share via


Application Security, Part 9

COM+ provided an infrastructure for role-based security. With role-based security, users are grouped according to their function, and are assigned permissions to perform abstract operations, each of which may involve a number of actions performed on a variety of objects. So, in COM+, application by application, one can define roles, associate Windows user accounts with those roles, and then determine which roles are authorized to access the application as whole, access particular components of the application, and execute particular methods of each component. Obviously, what access to an application, a component or a method could entail is any number of operations on any number of objects, so it apparent how, with COM+ role-based security, one can administer permissions at a coarser-grained, more practical level than it is possible to do with access control lists.

 

A key benefit of COM+ role-based security is that it can be administered using the Component Services Management Console snap-in. That saves one from having to build one’s own user interface to administer permissions.

 

A limitation, though, is that while access to COM+ components and their methods does represent a much coarser-grained and practical privilege with which to associate permissions than access to elements of the operating system, it lacks some flexibility. When authorizing a user for some operations and prohibiting them from others, we would prefer to have the users’ permissions shown to them on the user interface. So, for example, the buttons and menu items for initiating operations users are authorized to perform should be visible to them, while those for prohibited actions should be hidden. Yet, if the locus of our permission management is access to COM+ components and their methods, then everything on the user interface for which we would like to grant or deny permission would have to be mapped to a COM+ component or method in order for us to determine whether to display the user interface element or not. And even for those elements of a user interface on which actions do result in the execution of the methods of a COM+ component, figuring out whether the action is permitted for a given user may be complicated by the action resulting in the execution of not just one method, but several.

 

[This posting is provided "AS IS" with no warranties, and confers no rights.]

Comments

  • Anonymous
    March 04, 2004
    Application Security and Active Directory