【正文】
icular Web site and a number of popular Web servers can even provide fairly fine grained access control, they provide very primitive tools to administer these controls from the perspective of a single enterprise. This paper describes the benefits of RBAC and an implementation of RBAC on the Web (RBAC/Web), and in particular as RBAC applies to an intra puting environment. This will provide Web administrators with a capability for the first time to centrally administer and regulate user access to information in a manner that is consistent with the current set of laws, regulations, and practices that face their business today. Although this paper focuses on intras, the benefits, concepts and implementation of RBAC/Web are also applicable to a pany’ s inter environment where restrictive access to information is desired. RBAC Description Rolebased access control (RBAC) [1], [2], [3], [4], [5] is an alternative to traditional discretionary (DAC) and mandatory access control (MAC) policies that is attracting increasing attention [6], particularly for mercial applications. The principal motivation behind RBAC is the desire to specify and enforce enterprisespecific security policies in a way that maps naturally to an anization39。s structure. Traditionally, managing security has required mapping an anization39。s security policy to a relatively lowlevel set of controls, typically access control lists. With RBAC, security is managed at a level that corresponds closely to the anization39。s structure. Each user is assigned one or more roles, where roles are based on the user39。s job responsibilities and petencies in the anization. Each role is assigned one or more privileges (., information access, deletion, creation), see Figure 1. It is a user39。s membership into roles that determine the privileges the user is permitted to perform. Security administration with RBAC consists of determining the operations that must be executed by persons in particular jobs, and assigning employees to the proper roles. The RBAC framework provides for mutually exclusive roles as well as roles having overlapping responsibilities and privileges. For example, some general operations may be allowed by all employees, while other operations may be specific to a role. Role hierarchies are a natural way of anizing roles within an anization and defining the relationship and attributes of the roles. Complexities introduced by mutually exclusive roles or role hierarchies as well as regulating who can perform what actions, when, from where, in what order, and in some cases under what relational circumstances, is all handled by the RBAC software. Separation of Duty RBAC mechanisms can be used by a system administrator in enforcing a policy of separation of duties. Separation of duties is considered valuable in deterring fraud since fraud can occur if an opportunity exists for collaboration between various job related capabilities. Separation of duty requires that for particular sets of transactions, no single individual be allowed to execute all transactions within the set. The most monly used examples are the separate transactions needed to initiate a payment and to authorize a payment. No single individual should be capable of executing both transactions. The system administrator can control access at a level of abstraction that is natural to the way that enterprises typically conduct business. This is achieved by statically and dynamically regulating users39。 actions through the establishment and definition of roles, role hierarchies, relationships, and constraints. We define static separation of duty to mean that roles which have been specified as mutually exclusive cannot both be included in a user39。s set of authorized roles. With dynamic separation of duty, users may be authorized for two roles that are mutually exclusive, but cannot have both roles active at the same time. In other words, static separation of duty enforces the mutual exclusion rule at the