外文翻译--Web环境下基于角色的访问控制

附录A：英文原文

Role-Based Access Control for the Web

John F. Barkley, D. Richard Kuhn, Lynne S. Rosenthal, Mark W. Skall, and Anthony

V. Cincotta,

National Institute of Standards and Technology Gaithersburg, Maryland 20899

ABSTRACT

Establishing and maintaining a presence on the World Wide Web (Web), once a sideline for U.S. industry, has become a key strategic aspect of marketing and sales. Many companies have demonstrated that a well designed Web site can have a positive effect on their profitability. Enabling customers to answer their own questions by clicking their way through Web pages, instead of dealing with operators and voice response systems, increases the efficiency of the customer interface.

One of the most challenging problems in managing large networked systems is the complexity of security administration. This is particularly true for organizations that are attempting to manage security in distributed multimedia environments such as those using World Wide Web services. Today, security administration is costly and prone to error because administrators usually specify access control lists for each user on the system individually.

Role-based access control (RBAC) is a technology that is attracting increasing attention, particularly for commercial applications, because of its potential for reducing the complexity and cost of security administration in large networked applications. The concept and design of RBAC is perfectly suited for use on both intranets and internets. It provides a secure and effective way to manage access to an organization’s Web information. This paper describes a research effort to develop RBAC on the Web. The security and software components that provide RBAC for

networked servers using Web protocols have been implemented and are described in this paper. The RBAC components can be linked with commercially available web servers, and require no modification of the server software.

Introduction

Establishing and maintaining a presence on the World Wide Web (Web), once a sideline for U.S. industry, has become a key strategic aspect of marketing and sales. Many companies have demonstrated that a well-designed Web site can have a positive effect on their profitability. Enabling customers to answer their own questions by clicking their way through Web pages, instead of dealing with operators and voice response systems, increases the efficiency of the customer interface. Companies are seizing the Web as a swift way to streamline - even transform their organizations.

More recently companies have begun using web technology to service the public as well as private and internal clients. Web sites are set up to segregate some information from the general public, providing it to only selected or "private" clients. Typically, public internet is cordoned off from the general public by having user accounts and passwords. Additionally, Web sites are now running inside the company often created for and by employees. These internal private nets or "intranets" use the infrastructure and standards of the Internet and the World Wide Web but are cordoned off from the public Internet through firewalls.

The Web can be used as an inexpensive yet powerful alternative to other forms of communications. A plethora of corporate information (e.g., procedures, training materials, directories, forms) can be converted to electronic form and made available via the Web. With a single source for these materials the cost of maintenance is significantly reduced, while greatly simplifying the task of ensuring currency. Thus an objective of enterprise computing, creation of a company wide system irrespective of the underlying information technology infrastructure can be fulfilled.

Although the internet and intranets can offer great benefits to a company or government agency, security threats remain. To date net enthusiasts tend to focus on how to link people and businesses, not on using the network as a way to run and manage businesses securely. Although

existing Web servers can effectively provide all or nothing access to a particular 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 intranet computing 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 intranets, the benefits, concepts and implementation of RBAC/Web are also applicable to a company’s internet environment where restrictive access to information is desired. RBAC Description

Role-based 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 commercial applications. The principal motivation behind RBAC is the desire to specify and enforce enterprise-specific security policies in a way that maps naturally to an organization's structure. Traditionally, managing security has required mapping an organization's security policy to a relatively low-level set of controls, typically access control lists.

With RBAC, security is managed at a level that corresponds closely to the organization's structure. Each user is assigned one or more roles, where roles are based on the user's job responsibilities and competencies in the organization. Each role is assigned one or more privileges (e.g., information access, deletion, creation), see Figure 1. It is a user'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 organizing roles within an organization 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 commonly 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 users' 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 user'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 time an administrator sets up role authorizations, while dynamic separation of duty enforces the rule at the time a user selects roles for a session.

Role Administration and Visualization

The roles are established, manipulated and viewed using the RBAC/Web Admin tool. The Admin tool allows system administrators to create and define roles, role hierarchies, relationships and constraints. Once the

RBAC framework is established for the organization, the principal administrative actions are the granting and revoking of users into and out of roles as job assignments dictate. These maintenance tasks are easily performed using the Admin tool.

Additionally, the Admin tool is being enhanced to utilize the Virtual Reality Modeling Language (VRML, pronounced 'vermal'). VRML is an interactive, inter-networked, 3D graphics language for the Web. It is used to represent graphics, test, sound, and links to other content as either a static or dynamic picture on the Web. The inclusion of VRML into RBAC lets system administrators use an interactive computer model to check and validate the role structure, relationship, and privileges. Being able to view and interact with complex models, allows the administrator to identify conflicts, eradicate flaws and improve the implementation early in the RBAC setup.

The VRML component will enable authorized users to navigate the RBAC database, finding and linking roles, and displaying attributes and graphics associated with those roles. By presenting a 3D model of established roles, the user can easily see which roles are mutually exclusive as well as the hierarchical structure of related roles and conflicts between roles (see Figure 2). VRML's navigational controls allows the user to interactively 'walk-through' and manipulate the view perspective of the 3D model, known as a scene graph. For example, the scene graph can be rotated to show the 'backside' of the graph where role relationships may have been obscured when viewed as a 'flat', 2D graph. To improve readability, clarity and flexibility, the role hierarchy is organized into layers, where each layer contains another level of detail. By 'clicking' on a role, the role opens to reveal the next layer of related roles or information about the role, e.g., the privileges associated with that role or a user membership list.

RBAC Example

Consider the branch office of a bank. In this environment, there are roles such as branch manager, teller, and account representative, as illustrated in Figure 2.

The graph structure shows role hierarchy. The role financial_advisor inherits the role account_rep. An individual authorized for the role

financial_advisor is permitted to perform all of the operations permitted to an individual authorized for the role account_rep. Thus, an individual in the role of financial_advisor is able to create and remove accounts. Because account representatives, branch managers, internal auditors, and tellers are all employees of the bank, their corresponding roles inherit the employee role.

In Figure 2, the role account_rep is highlighted, appearing as a dark sphere, in order to show the other role relationships for account_rep. The roles teller and account_holder are shown as yellow rectangular solids to indicate that these roles have a "Dynamic Separation of Duties" (DSD) relationship with the role account_rep. This relationship is a conflict in interest relationship indicating that an individual acting in the role of account_rep cannot also be acting in either of the roles of account_holder or teller. The policy of the bank is that an account representative, an employee of the bank, can have an account in the bank but such an individual may not simultaneously process their personal account while processing accounts of others. Likewise, because a teller has an open cash drawer that must balance when closed, an individual acting in the role of account_rep and sitting at a desk away from a teller's window is not permitted to simultaneously act in the role of teller even if authorized for that role.

The role internal_auditor is shown in a red hexahedron to indicate that this role has a "Static Separation of Duties" (SSD) relationship with the role account_rep. The SSD relationship is also a conflict of interest relationship like the DSD relationship but much stronger. If two roles have a DSD relationship, then they may both be authorized for an individual but that individual may not act in both roles simultaneously. If two roles have a SSD relationship, then they may not even be authorized for the same individual. In this example, the policy of the bank is that there is a fundamental conflict of interest between the roles of internal_auditor and account_rep. Thus, these two roles may never be authorized for the same individual.

The new version of the Admin tool using VRML will allow us to represent conflicts of interest and other relationships in a more natural way and view the scene from an infinite number of viewpoints. VRML allows complex

3D objects to be created for this purpose. The user can 'enter' a selected role and explore several levels of detail (i.e., information) associated with that role. In addition, the sound capabilities of VRML can be utilized to give audio warnings when roles are used which cause conflicts of interest or other problems, or when improper procedures are used. RBAC for World Wide Web Applications

Role Based Access Control (RBAC) for the World Wide Web (RBAC/Web) is an implementation of RBAC for use by World Wide Web (Web) servers. Because RBAC/Web places no requirements on a browser, any browser that can be used with a particular Web server can be used with that server enhanced with RBAC/Web. RBAC/Web is implemented for both UNIX (e.g., for Netscape, NCSA, CERN, or Apache servers) and Windows NT (e.g., for Internet Information Server, WebSite, or Purveyor) environments.

Components of RBAC/Web are shown in Table 1. RBAC/Web for UNIX uses all of the components in Table 1. Because built-in NT security mechanisms are closely compatible with RBAC, the NT version uses only the Database, Session Manager, and Admin Tool components. RBAC/Web for NT requires no modification of Web server internals or access to source code. With RBAC/Web for UNIX, there are two ways to use RBAC/Web with a UNIX Web server.

The simplest way is by means of the RBAC/Web CGI. The RBAC/Web CGI can be used with any existing UNIX server without modifying its source code. RBAC URLs are passed through the Web server and processed by the RBAC/Web CGI. RBAC/Web configuration files map URLs to file names, while providing access control based on the user's roles. Installation of the RBAC/Web CGI is similar to the installation of the Web server.

附录B：中文翻译

Web环境下基于角色的访问控制

John F. Barkley, D. Richard Kuhn, Lynne S. Rosenthal, Mark W. Skall, 和Anthony V. Cincotta,

国家研究院所定规则及盖瑟斯堡技术，马里兰20899

摘要

建立和维持一个万维网（Web），它作为美国工业的一种附属形式，已经成为了买卖和销售战略中的重点。许多公司示范了一个设计良好的万维网能让他们在收益性上产生积极的效果。促成客户藉由Web网页按他们的方法获得他们想要的讯息，而不是通过处理操作员或声音回应系统，以增加客户接口的效率。

特别是对于尝试使用万维网服务器来管理多媒体环境安全的组织来说，最挑战性的问题之一在于管理大的网络系统时，所面对的安全管理方面的复杂性。今天，安全管理昂贵和容易出错是因为管理人通常单独为每个在系统上的使用者指定访问控制目录。

基于角色的访问控制（RBAC）是一种逐渐吸引人们注意的技术，特别是在商务应用上，因为它具有减少大型网络应用的复杂性和费用的潜力。 RBAC的概念和设计是为了能完全适应企业内部网和因特网。它提供了一个安全有效的方法去管理和组织其万维网信息的访问。本文描述了如何才能致力于在万维网上去应用基于角色的访问控制。为使用万维网协议的网络服务器提供基于角色的访问控制的安全和软件组件，这些内容都已经被实现并且在本文中得到了描述。基于角色的访问控制组件能被用于商务的万维网服务器上，并且不需要服务器软件的修正。

引言

建立和维持一个万维网（Web），作为美国工业的一种附属形式，已经成为了买卖和销售战略中的重点。许多公司示范了一个设计良好的万维网能让他们在收益性上产生积极的效果。促成客户藉由Web网页按他们的方法获得他们想要的讯息，而不是通过处理操作员或声音回应系统，以增加客户接口的效率。公司纷纷抓住万维网这样一个迅速的精简办法——甚至不惜转变他们的组织。

越来越多的新公司开始使用万维网技术去为公众或私人以及国内客户提供

服务。万维网站的建立是用来分隔一些来自普通大众的信息，提供给他唯一的选

择或设定“私人”用户。具体才说，公共网络封锁住了使用者的帐户和密码以免公开。此外，在企业内部运行的万维网站经常是为其雇员而产生设立的。这些内部私人站点或使用基础设施、因特网标准和万维网的“内部网”是通过防火墙来与公共网络相封锁的。万维网能被当作一种可供选择的便宜而又强有力的通信形式。过剩的企业信息（e.g.程序,训练材料，目录,表格）能经由万维网制作而被转换为电子形式。借助此单一途径，为这些材料维护的费用显著地减少了，这也确保了流通任务的简化。如此一来，企业计算机的一个目的：创造一个公司的大型系统，在其下分布的信息科技系统内的各部分是能被实现的。

虽然互联网和内部网能为公司或政府机构提供非常好的利益，但安全威胁依然残留。热心者们往往集中于人或生意上，而忽视了以使用网络作为运行和管理商业安全的方式。已经存在的万维网服务器能有效地提供所有的或不存在访问给一个特别的网站，许多流行的万维网伺候器甚至能更清楚而又细腻地提供访问控制，他们提供非常原始的工具来管理这些单一企业的远程控制。

本文描述了有关基于角色的访问控制和基于角色的访问控制在万维网环境

下执行（RBAC/Web）的优势，而且在个别项目中基于角色的访问控制适用于一个企业内网络计算环境。今天在此将会第一次提供给万维网管理人一种核心管理能力和管理使用者访问信息的方式，同时与法规流向保持一致并适应他们的商务要求。虽然本文的焦点在于企业内部网、利益、观念和和基于角色的访问控制在万维网环境下的执行，但对数据的限制访问需要可以应用在公司的因特网环境中。

基于角色的访问控制描述

基于角色的访问控制 (RBAC) 是传统的随意权限控制(DAC) 和强制性的访

问控制 (MAC) 的替代品，在商业申请后成为了一种正在不断吸引人们注意的技术。在基于角色的访问控制背后的主要推动力是自然的对组织结构进行规定和加强企业专项安全性策略的渴望。传统上来说, 安全管理需要把组织的安全政策放置到一个相对低水平的控制上去,传统地存取控制目录。

藉由基于角色的访问控制技术，安全在一个比较接近符合组织结构的水平上被处理。在角色以组织中的使用者其工作职责和能力为基础的地方，每个使用者被分配一个或多个角色。每个角色又被分配一个或多个权限 (例如数据访问，划除,创造)。只有进入决定特权使用者的角色范围之内后，使用者的全体操作才被允许。基于角色的访问控制的安全管理使得只有当特定的操作者被判断其动作可以被运行,然后分配职员到适当的角色后才能进行。

基于角色的访问控制结构可以提供给互斥的角色和角色有交叠处理职责的

特权。举例来说，一些一般的操作可能被所有的职员允许,当其他的操作可能是对一个角色的特性时候。角色层次是在一个组织里面组织角色而且定义关系和角色属性的自然方法。在基于角色的访问控制软件全部处理后，被互斥的角色或组织角色的复杂引入也调节了谁能运行什么行动,何时, 从哪里, 以什么次序, 和在某些情形之下表示关系的环境。

职责的分离

基于角色的访问控制机制可能被系统管理人用在执行一种政策分立的职责。自从面临在类似的工作或机会中诈骗能够发生后，分立的职责被认为在防止诈骗方面是有价值的。分立的职责必须是为了交易的特殊集合，没有简单单一的被允许去执行所有在集合里的交易。最常用的例子是

交易的分期付款和授权付款。没有单个的个体能够运行两个交易。系统管理人对企业传统的处理生意的方式是一个自然而又抽象化的程度控制访问。且由静止又动态地经过角色，角色等级，关系和限制的建立和定义管理使用者的行动被达成了。

我们定义静态职责的分离意味着互斥的给定角色不能同时被包括在用户的授权权限集合里。根据动态的职责分离，用户也许被授权了两个互斥的角色，但是不能同时操控这两个角色。换句话说，当一位管理人建立角色授权的时候，静态职责的分离迫使规则互斥；而当一个用户选择角色的时候，动态职责的分离迫使规则同样互斥。

管理和显示角色

使用基于角色的访问控制/万维网管理工具的角色被建立和操纵。管理工具允许系统管理员产生并且定义角色，角色层次，关系和限制。一旦基于角色的访问控制结构被确定是为了组织，首要的管理行动是用户进入的许可和废除并且缺乏对角色的分配指示。这些维护工作使用管理工具将被容易运行。

另外，管理工具正在被用以提高利用虚拟的真实靠模切语言（虚拟现实建模语言 ,发音 'vermal'）。虚拟现实建模语言是交谈式的、网际企业式的、同时也是用于万维网的3D立体图形语言。它用来表现图形，测试，声音和万维网上任意静态或动态图象的链接内容。基于角色的访问控制的虚拟现实建模语言让系统管理人使用一个交谈式计算机模型检查，而且使角色结构，关系和特权有效。能够观察和互相影响复杂的模型，允许管理人识别冲突，根除缺点而且早在基于角色的访问控制安装时就对安装启用进行改良。

虚拟现实建模语言成份将会使经认可的使用者能够执行基于角色的访问控制数据库，发现而且链接角色，而且显示属性和被和那些角色整合的图形。藉由一个确定角色的3D立体模型呈现，用户能很容易地看出哪一个角色是互斥的和在角色之间的相关角色，以及冲突的阶层结构。虚拟现实置标语言的导航控制允许使用者以交互式“初排”而且操纵 3D立体模型的视野远景,即一个场景曲线图。举例来说，当看“平面”或2 D 曲线图的时候，角色关系可能已经被隐藏的情况下场景曲线图可能被旋转来显示曲线图的“背部”。为了改善可读性、清晰度和适应性，角色层次被组织成层，而每个层又包含着其它级别的细节。通过一个角色，角色能开启和展现相关的角色层或角色信息。例如，与特权相关的角色或一个用户的从属清单。

基于角色的访问控制举例

考虑银行的分公司。在这环境中,有角色 , 像是部门经理，讲话者和帐户代表。

曲线图结构展示了角色的层次，角色financial_advisor继承了角色account_rep。单独被授权的角色financial_advisor被允许进行所有

account_rep角色所能进行的活动。因此，被授权的角色financial_advisor能够创建和修改帐户。因为帐户代表，部门经理，内部的审计员和出纳员都是银行的职员,他们的对应角色也继承了职员的角色。

在图2中，角色account_rep是突出的，为了显示其他角色关系，account_rep 的表现形式是一个暗球的形状。出纳员角色和account_holder以黄色矩形显示是为了说明这些角色与account_rep有一个“动态权责区分”（DSD）的关系。这个关系是一个抵触的利益关系指标，而account_rep 角色的个体权限不能在另一半的account_holder或teller角色上被给予权限。银行的政策是帐户代表或银行职员能有银行的帐户，但是如此的个体在处理其它的帐户时候不可能同时处理他们的个人帐户。同样的，因为一个出纳员有一个公开的现金抽屉且在关闭时一定结算了。一个坐在远离出纳员桌子上的account_rep角色即使被授权了出纳员的角色也不能同时被允许拥有出纳员的个体行动权限。

角色internal_auditor的表现形式是一个红色的六面体形状是为了说明这些角色与account_rep有一个“静态权责区分”（SSD）的关系。这个静态权责区分的关系同样是一个和动态权责区分关系一样相互抵触的利益关系，但是这个关系更强劲一些。如果两个角色间有一个动态权责区分的关系，那么他们可能同样被一个个体所授权，但是那个个体不可能同时在两个角色上被运用。如果两个角色间有一个静态权责区分的关系，那么他们不可能同样被一个个体所授权。在这一个例子中，银行的政策是在internal_auditor 和 account_rep的角色之间有一个基本的利害冲突，这二个角色可能无法被相同的个体所授权。

使用虚拟现实建模语言的管理工具的新版本将会允许我们以一种自然的方法表现相互抵触的利益或是其它关系，而且是由无数的情况所组成的。虚拟现实建模语言允许复杂的3D立体物体为这一个目的而被产生。使用者能“进入”一个被挑选出的角色而且探究一些和那个角色相互关联的程度方面的细节（也就是数据）。除此之外，当角色被应用的时候，虚拟现实建模语言的声音能力可能可能被利用上，在引起利害冲突、当不合适的程序被用或其他问题的时候给予声音的警告。

基于角色的访问控制在万维网中的应用

为万维网(RBAC/Web)而设的基于角色的访问控制(RBAC)是万维网(Web)服务器对基于角色的访问控制技术的具体执行。因为RBAC/Web点没有浏览器上的需求, 任何浏览器都能被用于一个特殊的用以增强RBAC/Web服务器的Web服务器。

RBAC/Web同时被UNIX（举例来说，对网景，NCSA，CERN 或阿帕契伺候器）和Windows NT（举例来说, 对英特网数据伺候器，网站或承办商）环境所应用

RBAC/Web的组件在表1中被显示。基于UNIX的RBAC/Web可以使用表1中的所有组件。因为内建的NT安全机制与基于角色的访问控制非常适合，NT版本只使用数据库，会话管理员，和管理工具组件。NT的RBAC/Web需要Web伺候器的无修正或原代码的访问。基于UNIX的RBAC/Web有两种途径以UNIX Web服务器来使用RBAC/Web。

最简单的方法是经由RBAC/Web通用网关接口（CGI）。RBAC/Web CGI不修正它的原代码，因而能被任何已存在的UNIX服务器用。RBAC URL被RBAC/Web CGI 通过网络服务器来处理。当提供基于用户的角色以访问控制的时候，RBAC/Web 配置文件名的网址文件图，RBAC/Web CGI的安装与Web的安装类似。