Role-based access control in DCOM

Abstract

The explosive growth of the Web, the increasing popularity of PCs and the advances in high-speed network access have brought distributed computing into the mainstream. To simplify network programming and to realize componentbased software architecture, distributed object models have emerged as standards. One of those models is distributed component object model (DCOM) which is a protocol that enables software components to communicate directly over a network in a reliable, and e cient manner. In this paper, we investigate an aspect of DCOM concerning software architecture and security mechanism. Also, we describe the concept of role-based access control (RBAC) which began with multi-user and multi-application on-line systems pioneered in the 1970s. And we investigate how we can enforce the role-based access control as a security provider within DCOM, specially in access security policy. Ó

Analysis of ANSI RBAC Support in EJB

“…The work most relevant to ours addresses support for RBAC in middleware. Ahn (2000) outlines a proposal for enforcing RBAC policies for distributed applications that utilize Microsoft's Distributed Component Object Model (DCOM) (Brown & Kindel, 1998;Microsoft, 1998). His proposal employs the following elements of Windows NT's architecture: (1) a registry for storing and maintaining the role hierarchy and permission-to-role assignment (PA); (2) user groups for simulating roles and maintaining user-to-role assignment (UA); and…”

“…(3) a custom built security provider that follows the RBAC model to make access control decisions, which are requested and enforced by the DCOM run-time. Since the support for role hierarchy is indicated, but not explained, by Ahn (2000), we assume that the Windows NT registry can be used to encode the hierarchy so that the RBAC security provider can refer to it while making authorization decisions. Similar to the proposals for RBAC support in operating systems, the use of OS user groups for simulating roles enables activation of more than one role.…”

Analysis of ANSI RBAC Support in COM+

“…The work most relevant to ours addresses support for RBAC in middleware. Ahn [57] outlines a proposal for enforcing RBAC policies for distributed applications that utilize Microsoft's Distributed Component Object Model (DCOM) [29,58]. His proposal employs the following elements of Windows NT's architecture: (1) registry for storing and maintaining the role hierarchy, and permission-to-role assignment (PA), (2) user groups for simulating roles and maintaining user-to-role assignment (UA), and (3) a custom-built security provider that follows the RBAC model to make access control decisions, which are requested and enforced by the DCOM run-time.…”

“…His proposal employs the following elements of Windows NT's architecture: (1) registry for storing and maintaining the role hierarchy, and permission-to-role assignment (PA), (2) user groups for simulating roles and maintaining user-to-role assignment (UA), and (3) a custom-built security provider that follows the RBAC model to make access control decisions, which are requested and enforced by the DCOM run-time. Since the support for role hierarchy is indicated but not explained in [57], we assume that the Windows NT registry can be used to encode the hierarchy so that the RBAC security provider can refer to it while making authorization decisions. Similar to the proposals for RBAC support in operating systems, the use of OS user groups for simulating roles enables activation of more than one role.…”

“…Yet, like with the pull model in client-server systems, all assigned roles are activated, leaving no choice to the user. Ahn does not indicate in [57] support for any kind of SoD, nor does he explain how RBAC policies can be enforced consistently and automatically in a multi-computer deployment of DCOM-accessible objects.…”