Article Preview
TopIntroduction
The American National Standard for Information Technology Role-Based Access Control (ANSI RBAC) (ANSI, 2004) is a specification of an access control system in which permissions are associated with roles, and users are assigned to appropriate roles. RBAC is an approach to address the needs of commercial enterprises better than lattice-based mandatory access control (MAC) (Bell & LaPadula, 1975) and owner-based discretionary access control (DAC) (Lampson, 1971). A role can represent competency, authority, responsibility, or specific duty assignments. The ANSI RBAC standard consists of two main parts: the RBAC Reference Model, and the RBAC System and Administrative Functional Specification. Both parts cover four components: the minimum set of features included in all RBAC systems (Core RBAC), role hierarchies (Hierarchical RBAC), static constraint relations (Static Separation of Duty Relations), and dynamic constraints (Dynamic Separation of Duty Relations). A major purpose of RBAC is to facilitate access control administration and review.
Many papers propose ways to support or implement RBAC using commercial technologies, e.g., Oracle (Notargiacomo, 1995), NetWare (Epstein & Sandhu, 1995), Java (Giuri, 1998), DG/UX (Meyers, 1997), J2EE (Zhang, Sheng, Niu, Wang, & Zhang, 2006; Bindiganavale & Ouyang, 2006), object-oriented systems (Barkley, 1995), object-oriented databases (Wong, 1997), MS Windows NT (Barkley & Cincotta, 1998), enterprise security management systems (Awischus, 1997). Evidence of RBAC becoming a dominant access control paradigm is the approval of the American National Standard Institute (ANSI) RBAC Standard (ANSI, 2004) in 2004.
At the same time, commercial middleware technologies−such as Common Object Request Broker Architecture (CORBA) (OMG, 1999), COM+ (Oberg, 2000), Enterprise Java Beans (EJB) (DeMichiel, Yalçinalp, & Krishnan, 2001)−matured, with distributed enterprise applications routinely developed with the use of middleware. Each middleware technology, however, comes with its own security subsystem (Eddon, 1999; OMG, 2002; Hartman, Flinn, & Beznosov, 2001), sometimes dependent on and specific to the underlying operating system (OS). For instance, COM+ security (Eddon, 1999) is tied into Microsoft Windows OS and its services.
The ability of a particular middleware technology to support specific types of access control policy is an open and practical question. It is not a simple question for the following three reasons.
First, different middleware technologies and their subsystems are defined in different forms and formats. For example, CORBA is specified in the form of open application programming interfaces (APIs), whereas EJB is defined through APIs as well as the syntax and semantics of the accompanying extensible markup language (XML) files used for configuring the EJB container. COM+ is defined through APIs as well as graphical user interfaces (GUI) for configuring the behavior of a COM+ server. The variations in the form, terminology, and format of the middleware definitions lead to the difficulty of identifying the correspondence among the (security and other) capabilities of any two middleware technologies.