Attribute relations in access control mechanisms or languages allow accurate and efficient specification of some popular access control models. However, most of the access control systems including today's de-facto access control protocol and specification language, XACML, does not provide sufficient syntactic and semantic support for the specification of attribute relations in their scheme. In this paper, we show the deficiencies of XACML in specifying such capabilities in the implementations of the Multilevel Security, Hierarchical Role Based policies and Separation of Duty requirements of access control systems. In comparison, we then demonstrate the attribute relation mechanism provided by a relation-based access control mechanism - the Policy Machine.

While mobile handheld devices provide productivity benefits, they also pose new risks. User authentication is the best safeguard against the risk of unauthorised use and access to a device's contents. This paper describes two novel types of Smart Card (SC) with unconventional form factors, designed to take advantage of common interfaces built into many current handheld devices.

As a major component of any host, or network operating system, access control mechanisms come in a wide variety of forms, each with their individual attributes, functions, methods for configuring policy, and a tight coupling to a class of policies. To afford generalized protection, NIST has initiated a project in pursuit of a standardized access control mechanism, referred to as the Policy Machine (PM) that requires changes only in its configuration in the enforcement of arbitrary and organization specific attribute-based access control policies. Included among the PM's enforceable policies are combinations of policy instances (e.g., Role-Based Access Control and Multi-Level Security). In our effort to devise a generic access control mechanism, we construct the PM in terms of what we believe to be abstractions, properties and functions that are fundamental to policy configuration and enforcement. In its protection of objects under one or more policy instances, the PM categorizes users and objects and their attributes into policy classes, and transparently enforces these policies through a series of fixed PM functions, that are invoked in response to user or subject (process) access requests.

Role-based Access Control (RBAC) models have been implemented not only in self-contained resource management products such as DBMSs and Operating Systems but also in a class of products called Enterprise Security Management Systems (ESMS). ESMS products are used for centralized management of authorizations for resources resident in several heterogeneous systems (called target systems) distributed throughout the enterprise. The RBAC model used in an ESMS is called the Enterprise RBAC model (ERBAC). An ERBAC model can be used to specify not only sophisticated access requirements centrally for resources resident in several target systems, but also administrative data required to map those defined access requirements to the access control structures native to the target platforms. However, the ERBAC model (i.e., the RBAC implementation) supported in many commercial ESMS products has not taken full advantage of policy specification capabilities of RBAC. In this paper we describe an implementation of ESMS called the 'Role Control Center' (RCC) that supports an ERBAC model that includes features such as general role hierarchy, static separation of duty constraints, and an advanced permission review facility (as defined in NIST's proposed RBAC standard). We outline the various modules in the RCC architecture and describe how they collectively provide support for authorization administration tasks at the enterprise and target-system levels.

In this article we propose a standard for role-based access control (RBAC). Although RBAC models have received broad support as a generalized approach to access control, and are well recognized for their many advantages in performing large-scale authorization management, no single authoritative definition of RBAC exists today. This lack of a widely accepted model results in uncertainty and confusion about RBAC's utility and meaning. The standard proposed here seeks to resolve this situation by unifying ideas from a base of frequently referenced RBAC models, commercial products, and research prototypes. It is intended to serve as a foundation for product development, evaluation, and procurement specification. Although RBAC continues to evolve as users, researchers, and vendors gain experience with its application, we feel the features and components proposed in this standard represent a fundamental and stable set of mechanisms that may be enhanced by developers in further meeting the needs of their customers. As such, this document does not attempt to standardize RBAC features beyond those that have achieved acceptance in the commercial marketplace and research community, but instead focuses on defining a fundamental and stable set of RBAC components. This standard is organized into the RBAC Reference Model and the RBAC System and Administrative Functional Specification. The reference model defines the scope of features that comprise the standard and provides a consistent vocabulary in support of the specification. The RBAC System and Administrative Functional Specification defines functional requirements for administrative operations and queries for the creation, maintenance, and review of RBAC sets and relations, as well as for specifying system level functionality in support of session attribute management and an access control decision process.

Formally defines a wide variety of separation-of-duty (SoD) properties, including the best known to date, and establishes their relationships within a formal model of role-based access control (RBAC). The formalism helps to remove all the ambiguities of informal definition and offers a wide choice of implementation strategies. We also explore the composability of SoD properties and policies under a simple criterion. We conclude that the practical implementation of SoD policies requires new methods and tools for security administration, even within applications that already support RBAC, such as most database management systems.