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 sup...

The Ponder language provides a common means of specifying security policies that map onto various access control implementation mechanisms for firewalls, operating systems, databases and Java. It supports obligation policies that are event triggered conditionaction rules for policy based management of networks and distributed systems. Ponder can also be used for security management activities such as registration of users or logging and auditing events for dealing with access to critical resources or security violations. Key concepts of the language include roles to group policies relating to a position in an organisation, relationships to define interactions between roles and management structures to define a configuration of roles and relationships pertaining to an organisational unit such as a department. These reusable composite policy specifications cater for the complexity of large enterprise information systems. Ponder is declarative, stronglytyped and object-oriented which makes the language flexible, extensible and adaptable to a wide range of management requirements.

We propose a new distributed security infrastructure, called SDSI (pronounced "Sudsy"). SDSI combines a simple public-key infrastructure design with a means of defining groups and issuing group-membership certificates. SDSI's groups provides simple, clear terminology for defining access-control lists and security policies. SDSI's design emphasizes linked local name spaces rather than a hierarchical global name space.

While Mandatory Access Controls (MAC) are appropriate for multilevel secure military applications, Discretionary Access Controls (DAC) are often perceived as meeting the security processing needs of industry and civilian government. This paper argues that reliance on DAC as the principal method of access control is unfounded and inappropriate for many commercial and civilian government organizations. The paper describes a type of non-discretionary access control - role-based access control (RBAC) - that is more central to the secure processing needs of non-military systems then DAC. 1 Introduction The U.S. government has been involved in developing security technology for computer and communications systems for some time. Although advances have been great, it is generally perceived that the current state of security technology has, to some extent failed to address the needs of all. [1], [2] This is especially true of organizations outside the Department of Defense (DoD). [3] The curre...

We introduce the RT framework, a family of Rolebased Trust-management languages for representing policies and credentials in distributed authorization. RT combines the strengths of role-based access control and trustmanagement systems and is especially suitable for attributebased access control. Using a few simple credential forms, RT provides localized authority over roles, delegation in role definition, linked roles, and parameterized roles. RT also introduces manifold roles, which can be used to express threshold and separation-of-duty policies, and delegation of role activations. We formally define the semantics of credentials in the RT framework by presenting a translation from credentials to Datalog rules. This translation also shows that this semantics is algorithmically tractable. 1

The protection mechanisms of current mainstream operating systems are inadequate to support confidentiality and integrity requirements for end systems. Mandatory access control (MAC) is needed to address such requirements, but the limitations of traditional MAC have inhibited its adoption into mainstream operating systems. The National Security Agency (NSA) worked with Secure Computing Corporation (SCC) to develop a flexible MAC architecture called Flask to overcome the limitations of traditional MAC. The NSA has implemented this architecture in the Linux operating system, producing a Security-Enhanced Linux (SELinux) prototype, to make the technology available to a wider community and to enable further research into secure operating systems. NAI Labs has developed an example security policy configuration to demonstrate the benefits of the architecture and to provide a foundation for others to use. This paper describes the security architecture, security mechanisms, application programming interface, security policy configuration, and performance of SELinux.

Separating management policy from the automated managers which interpret the policy facilitates the dynamic change of behaviour of a distributed management system. This permits it to adapt to evolutionary changes in the system being managed and to new application requirements. Changing the behaviour of automated managers can be achieved by changing the policy without have to reimplement them -- this permits the reuse of the managers in different environments. It is also useful to have a clear specification of the policy applying to human managers in an enterprise. This paper describes the work on policy which has come out of two related ESPRIT funded projects, SysMan and IDSM. Two classes of policy are elaborated -- authorisation policies define what a manager is permitted to do and obligation policy define what a manager must do. Policies are specified as objects which define a relationship between subjects (managers) and targets (managed objects). Domains are used to group the object...

We address the problem of authorization in large-scale, open...

As the World Wide Web has been used to build increasingly complex applications, developers have been constrained by the Web’s static document model. “Active ” content can add simple animations to a page, but it can also transform the Web into a “platform ” for writing and distributing programs. A variety of mobile code systems such as Java [Gosling et al.

Modern distributed systems contain a large number of objects, and must be capable of evolving, without shutting down the complete system, to cater for changing requirements. There is a need for distributed, automated management agents whose behavior also has to dynamically change to reflect the evolution of the system being managed. Policies are a means of specifying and influencing management behavior within a distributed system, without coding the behavior into the manager agents. Our approach is aimed at specifying implementable policies, although policies may be initially specified at the organizational level (c.f. goals) and then refined to implementable actions. We are concerned with two types of policies. Authorization policies specify what activities a manager is permitted or forbidden to do to a set of target objects and are similar to security accesscontrol policies. Obligation policies specify what activities a manager must or must not do to a set of target objects and essen...