2006年01月08日

表达式和托管Bean集成方法1

我打算通过AOP集成Spring和JSF（所选择的JSF实现应该不受其具体实现策略所约束），我现在采用的方法是利用Spring的AOP为JSF提供一个ApplicationFactory。这个Factory提供给JSF一个Application代理，此Application代理将被修改它的createMethodBinding()和createValueBinding()方法来解析JSF对bean的引用，对于其他的方法，则通过默认的Application调用。Application的实现类通过配置文件来实现标识代理，因此它可以用来匹配不同的JSF实现（现阶段这个例子是用的是Sun的参考实现，不过，公司将来会应用Apache的Myfaces）

这个方法接收在JavaServer Faces表达式语言（JSF EL）中被请求的Bean的属性的名称。首先它检测被请求的属性是否能够在JSF的托管Bean中找到；然后，它检测这个属性是否能够在Spring管理的Bean中找到；如果在这两个Bean托管容器（对于Spring和JSF的这部分功能，我认为他们都是管理Bean的一个容器，不知道这么认为对不对，欢迎指正）中都无法找到，这个名称将在JSF托管Bean中进行表示和计算。如果在某些地方，在Spring和JSF的托管Bean中均有该属性的名称，Context将从JSF转换为Spring的。

例子：

faces-config.xml （部分）：

<managed-bean>
	<description>JSF managed bean referencing a spring bean</description>
	<managed-bean-name>JsfBean</managed-bean-name>
	<managed-bean-class>test.JsfBean</managed-bean-class>
	<managed-bean-scope>session</managed-bean-scope>
</managed-bean>

JsfBean.java:

package test;
public class JsfBean {
	private SpringBean _springBean;

	public JsfBean() {
		super();
	}

	public SpringBean getSpringBean() {
		return _springBean;
	}

	public void setSpringBean(SpringBean paramSpringBean) {
		_springBean = paramSpringBean;
	}
}

applicationContext.xml （部分）：

<bean id="SpringBean" class="test.SpringBean">
	<property name="text"><value>some example text</value></property>
</bean>

SpringBean.java:

package test;
public class SpringBean {
	String _text;

	public SpringBean() {
		super();
	}

	public String getText() {
		return _text;
	}

	public void setText(String paramText) {
		_text = paramText;
	}
}

showText.jsp （部分）：

<h:outputText value="#{JsfBean.springBean.text}" />

在这个例子中，Application代理将首先调用getSpringBean()方法，如果返回值为null，它将检测是否在Spring定义中存在相应的Bean，然后调用setter方法。

另外，实现ApplicationContextAware后，setApplicationContext()将在实例化每一个JSF托管Bean之前调用，这样，如果需要的话Spring就可以作用于JSF的托管Bean了。

表达式和托管Bean集成方法2

还有一种方法来集成Spring和JSF，不过我现在还说不清楚到底哪种更好些。扔上来让大家瞧瞧。

第二种方式是实现一个自定义的VariableResolver。这个自定义的Resolver能够为集成Spring和JSF提供两种功能，Spring将被作为一个简单可变的Context，另外Spring将被直接包含在JSF的托管Bean中。

Spring作为简单可变Context

applicationContext.xml （部分）：

<bean id="SpringBean" class="test.SpringBean">
	<property name="text"><value>some example text</value></property>
</bean>

SpringBean.java:

package test;
public class SpringBean {
	String _text;

	public SpringBean() {
		super();
	}

	public String getText() {
		return _text;
	}

	public void setText(String paramText) {
		_text = paramText;
	}
}

showText.jsp （部分）：

<h:outputText value="#{SpringBean.text}" />

（未完，待续）

当老板也不是那么容易的啊，连TMD写个Blog的时间都没有。FK。

归类于：技术之路 — vickymade @ 9:33 pm 评论(0)

2006年01月07日

Artech House – Role-Based Access Control 004 Core RBAC Features

Overview

The RBAC security model is both abstract and general. It is abstract, because properties that are not relevant to security are not included, and it is general because many designs could be considered valid interpretations of the model. Thus, the model is usable as a basis for the design of a variety of IT systems.

The RBAC model described here and in the next two chapters is sufficient to support a variety of security policies. In particular, an argument is made for least privilege and SoD. Least privilege is the time-honored administrative practice of selectively assigning privileges to users such that the user is given no more privilege than is necessary to perform his or her job function. The principle of least privilege avoids the problem of an individual having the ability to perform unnecessary and potentially harmful actions merely as a side effect of gaining the ability to perform desired functions. Permissions (or privileges) are rights granted to an individual, or subject acting on behalf of a user, that enable the holder of those rights to act in the system within the bounds of those rights. The question then becomes how to assign the set of system privileges to the aggregates of functions or duties that correspond to a role of a user. Least privilege provides a rationale for installing the separation boundaries that are to be provided by RBAC protection and management mechanisms. Ensuring adherence to the principle of least privilege is largely an administrative challenge that requires the identification of job functions, the specification of the set of privileges required to perform each function, and the restriction of the user to a domain with those privileges and nothing more.

SoD refers to the partitioning of tasks and associated privileges among different roles associated with a single user to prevent users from colluding with one another. These separation concepts include multiplexing shared resources, naming distinctive sets of permissions to include functional decomposition, categorically classifying users, and granting hierarchical decomposition privileges.

The major purpose of RBAC is to facilitate authorization management and review. Administration RBAC features range from the simple to the complex. Because of the wide range of possible RBAC deployments, different RBAC features apply to different environments based on their scope of control and risk profile. Even identifying the bounds of RBAC is a point of dispute. Research continues to this day to extend the RBAC model in attempts to increase its functionality in support of new policies and to integrate RBAC into a greater range of IT infrastructures and enterprise processes. For instance, work is being conducted to include RBAC as a core technology within workflow management systems (see Section 10.1) and to extend RBAC policy to include temporal issues (see Section 5.3). However, there are several basic RBAC features that are well accepted and that are being widely implemented as a major component of government and commercial IT infrastructures. To avoid diluting RBAC’s essential features and motivations and distorting its basic properties, a taxonomy has been developed to distinguish the features incorporated in several RBAC models proposed in the literature.

The RBAC model taxonomy consists of four models—core RBAC, hierarchical RBAC, static constrained RBAC, and dynamic constrained RBAC. This chapter discusses the concepts of the core RBAC model as well as approaches used for mapping the abstract concepts of core RBAC onto the concrete structures of host operating systems and applications. Core RBAC covers the basic set of features that are included in all RBAC systems. It is the inclusion of this set of features that distinguishes RBAC from other forms of authorization management systems. Chapter 4 details hierarchical RBAC. Hierarchical RBAC adds the concept of a role hierarchy, defined as a partial ordering on roles, using an inheritance relation. Chapter 5 covers constrained RBAC in terms of the static and dynamic SoD properties. Statically constrained RBAC adds constraint relations imposed on role assignment relations. Dynamic constrained RBAC imposes constraints on the activation of sets of roles that may be included as an attribute of a user’s subjects.

Before reviewing the core RBAC model’s features, we first describe the similarities and differences between roles and groups.

3.1 Roles versus ACL groups

An ACL is a lower-level mechanism that contains the names of subjects that are authorized to access the object to which it refers, as well as specific permissions that are granted to each authorized subject. Thus, when a subject wants to access an object, the system searches for an entry of the subject in the appropriate ACL. If an entry exists, and if the requested operation is part of that entry, then the system permits access. The privilege to create and modify ACLs is restricted to the owners of the objects for which the ACLs protect. To support discretionary policies, ownership or control typically resides with the creators of the objects. In an attempt to support nondiscretionary policies, which are typical of many organizations, ownership is assumed by the enterprise, with security administrators centrally controlling ACL entries on behalf of the enterprise. For administrative efficiency reasons, a group is often used as an entry on the ACL as a shorthand notation for describing a collection of individual subjects. For purposes of access control calculations, the subject’s identity is compared to the identities maintained in the group. If a match is found, the subject is allowed to perform the operation corresponding to the group entry.

At a basic level, roles can be considered to be equivalent to groups. A role can represent a collection of users, and a user can be a member of multiple roles. Similarly, a single privilege can be associated with one or more groups or roles and a single group or role with one or more privileges. As such, assigning a user to a group or role provides the user with the ability to execute those privileges that are associated with the group or role. At this level of discourse a role is not unlike that of a group within the context of an ACL. However, roles and groups have different semantics in access control models and different usage in their implementation.

Groups are implementation-specific. Therefore, the characteristics of a group may change from one implementation to another. For example, within some UNIX environments, only one group can be associated with a particular file; other operating system environments allow multiple groups to coexist among the access control entries of a file, while still other access control systems prevent a user from being a member of more than one group at a time. Commensurate with restrictions on group membership, or group usage, are restrictions on administrators or object owners’ specificity and granularity of control.

As a central element of the RBAC model, a role is defined in terms of a set of properties (with fixed characteristics). Regardless of its implementation, a role will always exhibit the properties defined by the RBAC model. A group may or may not exhibit these properties. For example, the properties of an RBAC role allow for the naming of many-to-many relations among users and permissions. For a group to meet this same property, the group structure as implemented must not place any practical restrictions on the number of the following:

Groups that could be created;
Users that could become a member of any group;
Groups to which a user can have simultaneous membership;
Individual groups that can be included within access control entries of a single access control list.

Many, but not all, application and operating system group or ACL mechanisms meet this requirement and thus may be considered equivalent to a role according to the RBAC model. Because of their compliance to the RBAC model they are known to provide the administrative benefits associated with a simple RBAC role within their scope of control.

Because RBAC is a model and not a mechanism, it may be implemented within many types of systems to include network and enterprise management systems with a scope of control that is far more expansive than a single operating system or application. Regardless of its embodiment, users and roles are treated as global entities under the RBAC model. By implementing RBAC within an enterprise management system, the system administrator treats and manages the users and roles as abstractions of system and application-specific permission. For instance, assigning a user to a role may grant the user a set of permissions within and across multiple operating systems and applications. From the enterprise perspective, it may be far more efficient to manage user permissions through global roles than through the individual groups of potentially many operating systems and applications.

Central to RBAC is the concept of role relations. By taking advantage of the fixed properties of a role, RBAC serves as a semantic construct around which an access control policy is formulated. In addition to user and permission assignment relations, the RBAC model includes user and permission inheritance relations and a variety of static and dynamic constraint relations. Although it is plausible that a group structure could be extended to provide a semantically equivalent set of relations, in general, groups are product-specific with differing characteristics and therefore are better viewed as serving rather then competing with the RBAC model roles.

3.2 Core RBAC

Core RBAC recognizes five administrative elements: (1) users, (2) roles, and (3) permissions, where permissions are composed of (4) operations applied to (5) objects. Central to RBAC is the concept of role, where a role is a semantic construct around which access policy is formulated. The most basic of these relations are user and permission assignments. In RBAC, permissions are associated with roles, and users are made members of roles, thereby acquiring the roles’ permissions. Figure 3.1 shows the relationship between users, roles, and permissions. Figure 3.1’s use of double-headed arrows indicates a many-to-many relationship. For example, a single user can be associated with one or more roles, and a single role can have one or more user members.

Figure 3.1: User, role, and permission relationships.

This arrangement provides great flexibility and granularity of assignment of permissions to roles and users to roles. Any increase in flexibility in controlling access to resources also strengthens the application of the principle of least privilege.

3.2.1 Administrative support

One of RBAC’s greatest virtues is the administrative capability that it supports. The administration of authorization data is widely acknowledged as an onerous process with a large and recurring expense. Under the core RBAC model, users are assigned to roles based on their competencies, authority, and responsibilities. User assignments can be easily revoked, and new assignments established as job assignments dictate. With RBAC, users are not granted permissions to perform operations on an individual basis; instead, permissions are assigned to their roles. Role associations with new permissions can be established, while old permissions can be deleted as organizational functions change and evolve. This basic concept has the advantage of simplifying the understanding and management of permissions: System administrators can update roles without updating the permissions for every user on an individual basis.

As an alternative to providing these conveniences, it is often the practice to establish user permissions based on a concept of "cloning." Cloning is the practice of assigning permissions to a user based on the duplication of permissions of a second user who performs a similar function to that of the first user. Cloning is usually performed without regard to the details of the permissions that are assigned to users. Although cloning may be a quick and efficient method for the establishment of permissions, due to the coarse nature of permission assignment, cloning is generally considered to be a dangerous practice.

Another advantage of RBAC is that system administrators specify access requirements to resources at the same level of abstration as typical business processes in an enterprise. Under the RBAC model, system managers administratively create roles for various job positions in the organization. For example, a role can include teller or loan officer in a bank, or doctor, nurse, or clinician in a hospital. The permissions that are assigned to a role constrain members of the role to a specific set of actions. For example, within a hospital system, the role of a doctor can include permissions to perform diagnosis, prescribe medication, and order laboratory tests; the role of researcher can be limited to gathering anonymous clinical information for studies; the role of social worker may be reviewing patient profiles to flag possible suicidal patients or to determine possible abuse cases.

3.2.2 Permissions

In modeling an access control system, system administrators may treat permission as an abstract concept that refers to the arbitrary binding of computer operations and resource objects, and, in the case of a transactionbased system, the system administrator may take processes and values into consideration. Because of this implied action, one can consider permissions to represent an atomic unit of work exercised within a computing environment. The collection of permissions assigned to a role confers the potential to perform duties, tasks, functions, or any other abstraction of a workrelated activity. Assigning a user to a role gives the user the ability to perform these activities.

Permissions that are assigned to roles reflect policy decisions on the part of the host organization. These permission assignments can be detailed in terms of both granularity of method and granularity of access. To understand the importance of granularity of method, consider the differences between the access needs of a teller and an accounting supervisor in a bank. An enterprise defines a teller role as being able to perform a savings deposit operation. This requires read and write access to specific fields within a savings file. An enterprise may also define an accounting supervisor role that is allowed to perform correction operations. These operations require read and write access to the same fields of the savings file as the teller needs. However, the accounting supervisor may not be allowed to initiate deposits or withdrawals but only perform corrections after the fact. Likewise, the teller is not allowed to perform any corrections once the transaction has been completed. These two roles are distinguished by the operations that can be executed and the values that are written to the transaction log file.

To understand the importance of the granularity of access, consider the needs of a pharmacist to access a patient’s record to check for interactions between medications and to add notes to the medication section of the patient record. Although such operations may be necessary, the pharmacist should not be able to read or alter other parts of the patient record.

The assignment of permissions to roles can comply with rules that are self-imposed. For example, a health care provider may decide to constrain the role of clinician to posting only the results of certain tests, rather than distributing them where routing and human errors can result in a violation of a patient’s right to privacy. Permission assignments may pertain to the enforcement of laws or regulations. For example, a system could constrain a nurse to adding a new entry to a patient’s history of treatments, rather than being able to generally modify a patent record. A pharmacist can be provided with permissions to dispense, but not prescribe, medication.

The type of operations and the objects that RBAC controls are dependent on the type of system in which it will be implemented. For example, within an operating system, operations might include read, write, and execute; within a DBMS, operations might include insert, delete, append, and update; and within a transaction management system, operations would take on the form of and exhibit all the properties of a transaction. The set of objects covered by the RBAC system includes all of the objects accessible by the RBAC operations. However, system objects need not be included in an RBAC scheme. For instance, access to system-level objects such as synchronization objects (e.g., semaphores, pipes, and message segments) and temporary objects (e.g., temporary files and buffers) may not necessarily be controlled within the RBAC protection set. It is the job of the resource management system of the underlying operating system to protect these objects to support process isolation and to prevent security bypass attacks, as pointed out in Section 2.3 RBAC objects need not be limited to information containers. RBAC objects can represent exhaustible system resources, such as printers, disk space, and CPU cycles.

As an illustration of the relations described above, Figure 3.2 shows a pair of binary relations: one between operation and object, referred to as a permission, and the other between role and permission.

Figure 3.2: Core RBAC static element.

3.2.3 Role activation

Consistent with many other types of models, RBAC includes the concepts of subjects and objects. In general, the properties and mappings defined by the RBAC model can be divided into two separate but dependent static and dynamic components. The static component that has been discussed thus far is defined in terms of RBAC relations that do not involve the notion of a subject (in practical terms of ten equivalent to session). In applying a dynamic security policy to a computing system, we speak of subjects, which are active entities whose access to roles, operations, and objects must be controlled. A subject acting on the user’s behalf carries out all the requests of a user. Each subject is uniquely referenced by an identifier, which is used to determine whether the subject is authorized for a role and can become active in the role. A user may be associated with multiple subjects at any moment in time. Each subject may have a different combination of active roles. This feature supports the principle of least privilege in that a user that is assigned to multiple roles may activate any subset of these roles to suit his or her tasks. Limiting the roles that can be activated by a subject restricts the subject to the space of accesses that are defined by the permissions that are assigned to the roles in activation. Chapter 5 defines constraint relations that can be applied to role activation in support of SoD policies and enhanced least privilege features.

The dynamic component of core RBAC includes role activation and subject access. Properties of core RBAC ensure that the active roles of a subject are a subset of the roles that are assigned to the subject’s user and that the active roles of a subject are applied in the performance of object access checks. In addition to these properties, the dynamic component of the core

RBAC model defines two mapping functions. The first maps a subject back to a single user, and the second maps each subject to an active role set. Definition 3.1 formally defines core RBAC.

Definition 3.1: The Core RBAC model is defined as follows:

USERS, ROLES, OPS, and OBS (users, roles, operations, and objects, repectively).
UA ⊆ USERS × ROLES, a many-to-many mapping between users and roles (user-to-role assignment relation).
assigned_users: (r:ROLES) → 2^USERS, the mapping of role r onto a set of users. Formally: assigned_users(r) = {u ∊ USERS | (u,r) ∊ UA}
PRMS = 2^{(OPS × OBS)}, the set of permissions.
PA ⊆ PRMS × ROLES, a many-to-many mapping between permissions and roles (role-permission assignment relation).
assigned_permissions(r: ROLES) → 2^PRMS, the mapping of role r onto a set of permissions. Formally: assigned_permissions(r) = {p ∊ PRMS|(p,r) ∊ PA}.
SUBJECTS, the set of subjects.
subject_user(s: SUBJECTS) → USERS, the mapping of subject s onto the subject’s associated user.
subject_roles(s:SUBJECTS) → 2^ROLES, the mapping of subject s onto a set of roles. Formally: subject_roles(s_i) ⊆ {r ∊ ROLES|(subject_user(s_i,r) ∊ UA}

Property 3.1 Role authorization A subject can never have an active role that is not authorized for its user.

∀ s:SUBJECTS, u : USERS, r :ROLES
r ∊ subject_roles(s) ⁁ u ∊ subject_user(s) ⇒ u ∊ assigned_users(r)

access: SUBJECTS × OPS × OBS → BOOLEAN;
access(s, op, o) = 1 if subject s can access object o using operation op,

Property 3.2 Object access authorization A subject s can perform an operation op on object o only if there exists a role r that is included in the subject’s active role set and there exists an permission that is assigned to r such that the permission authorizes the performance of op on o.

s:SUBJECTS, op:OPS, o:OBS

access(s, op, o) ⇒

∃r: ROLES,p:PRMS r ∊ subject_role ⁁ p ∊ assigned_permissions(r) ⁁ (op, o)

∊ p

Figure 3.3 illustrates the set of dynamic mappings and static relations that are necessary for a user to access an object. The dotted arrows depict dynamic mappings, and the solid arrows depict static relations.

Figure 3.3: User u₁ can perform operation op on object o₂ because p₂ ∊ assigned_permissions(r₂) ⁁ u₁ ∊ assigned_users (r₂) ⁁ u₁ ∊ subject_user(s₂) ⁁ r₂ ∊ subject_roles(s₂).

3.3 Mapping the enterprise view to the system view

In our terminology, privileges are system-specific, and permissions are mapped into privileges. Each system supports its own class of operations and has its own class of resources. The scope of a role pertains to the class of privileges that can be expressed by the operations and resources of the systems for which RBAC controls access. Although privileges are system-specific, users and roles can take on a common meaning across multiple systems.

User "John Smith" may possess a number of system accounts and may be able to access resources within a variety of systems. Similarly, the role accounts receivable clerk may be assigned privileges that span a number of different systems and applications. In general, users, roles, and permissions can be treated as global entities, while privileges that are ultimately assigned to a role are specific to local computing environments.

In Figure 3.4, Tom and John are loan officers. They use their role permissions to read account data, write loan data, and execute transactions A, B, and C. The role permissions authorize the users assigned to the role to access the protected resources to perform their work. To put the role permissions into effect, access rights must be set up in the servers and applications affected—in other words, the permissions must be mapped into system-specific privileges.

Figure 3.4: User-roles and role-privilege association.

The question remains, how are these role permissions reflected in real systems? This depends greatly on the type of environment and the scope of control for which RBAC is implemented. For example, when system administrators implement RBAC within an operating system, DBMS, or application environment, RBAC can be directly designed into the native resource management and access control system. In these environments, the RBAC system could directly manage the users, roles, operations, and resources that are included within these environments. With respect to a distributed heterogeneous computing environment, no single or overarching resource management or access control system exists. To further complicate the issue, the privilege names and semantics vary from system to system. For example, the read operation to access a protected file is called "r" within most UNIX systems or "READ" in RACF. A write operation could include a read operation in some systems but not in others. To deal with systemdependent permissions, a number of different approaches have been proposed and, in fact, are being implemented within enterprise management and resource-provisioning systems.

Regardless of the approach, to deliver the prescribed benefits of RBAC, core RBAC requires vendors to provide a method for mapping and maintaining role-permission relations. It is important to emphasize that the RBAC model does not dictate how these mappings are to be implemented but rather specifies that user-role and role-permission relations must be in place.

Because the RBAC model does not specify requirements for techniques in mapping an enterprise view of RBAC to the system level view, IT consumers must evaluate and compare competing products with respect to their specific needs and applications. The following sections discuss two generic approaches to providing this mapping. See Section 12.2 for RBAC model concepts implemented in commercially available enterprise security software.

3.3.1 Global users and roles and indirect role privileges

The first approach to mapping an enterprise-level RBAC view onto a system-level view involves creating and maintaining direct associations between RBAC users and local user IDs and between RBAC roles and local groups. The local administrative interface can then be used to protect local resources in terms of the RBAC system’s created user IDs and groups.

Under this approach, the RBAC system links the user IDs of user accounts on various systems to one user at the enterprise level. This makes it possible to manage all the user IDs of one user (person) from a single point. User IDs on a particular system are often organized into user groups. Accordingly, a security administrator can authorize a group to access a resource instead of having to authorize each individual user. Groups and user IDs are central to mapping RBAC entities on the enterprise level to privileges at the system level.

At the enterprise level, users are organized into roles based on their role assignments. A role is responsible for the execution of a portion of the overall work performed by the enterprise. The work is performed through the invocation of permissions that are assigned to roles. To create a mapping of an enterprise view onto a system-level group, the RBAC system populates the group with the users who are assigned to its corresponding role. For the RBAC system to grant a user membership into a local group, the user must possess an account on the system. As a consequence, for each user who is included within any group on the local system, the RBAC system must first create a local user account. The RBAC system may perform this user and role-to-user ID and group mapping over any number of local systems where there exists a single user and single role that would be mapped onto multiple systems. Thus, deleting a user’s role assignment at the enterprise level would result in the deletion of the user’s membership within multiple groups in multiple systems. Assigning a user to a role at the enterprise level would result in the creation of user IDs and the granting of group memberships within any system for which the role has been previously mapped. Using this scheme, the RBAC system can manage user IDs and groups across its scope of control through manipulating user-role assignments at the enterprise level. The mapping relations could be stored in any central database or directory for convenient access and retrieval.

Once the RBAC system has created the user IDs, groups, and group memberships at the system level, local administrators are free to protect local resources by employing user IDs and groups in expressions of local privileges. For example, a native ACL mechanism can be used in this expression of privilege. Once these local privileges are established, the users assigned to those roles mapped to those groups used as an expression of privilege in protecting a resource on a local system can log on to that system and access the resource.

In Figure 3.5, the users Tom and John are assigned to the role loan officer at the enterprise level. Tom and John’s role is mapped onto system 1 at the system level by creating corresponding user IDs and a corresponding group that includes Tom and John as group members. At the system level, a local administrative interface is used to create an ACL that gives the group loan officer read access to the files contained in the loan_data directory.

Figure 3.5: Mapping global users and roles to local user accounts, groups, and privileges.

3.3.2 Mapping permissions into privileges

To allow for the definition of system-independent permissions, the RBAC system provides abstract operations and abstract resources at the enterprise level. Each abstract operation may map one-to-many onto the real operations of real systems at the system level. Through this mapping process, system-specific interpretations of the generic operations are resolved by the creation of equivalent but system-specific operations. Similarly, abstract resources can be mapped one-to-many onto real resources on real systems. The RBAC administrator may centrally grant role permissions in terms of these abstract operations and abstract resources, resulting in the creation of ACLs (i.e., privileges) on real resources across one or more systems. Once mappings are established, any changes to permissions would result in corresponding changes to these ACLs (privileges). In Figure 3.6, because loan officers are assigned the permission to perform write operations on loans, wherever the abstract loans resource is instantiated (mapped), there would result the automatic formulation of an ACL in terms of the local system’s interpretation of the abstract operation "write." In Figure 3.6, the abstract resource "loans" is mapped to the real resource "loan_data" on system 1 and to two other real resources on other systems at the system level. The abstract operation "write" corresponds to the "w" operation on system 1.

Figure 3.6: Mapping abstract permissions assigned to the role loan officer at the enterprise level to real ACLs at the system level.

归类于：技术之路 — vickymade @ 3:59 pm 评论(0)

Artech House – Role-Based Access Control 003 Chapter 2: Access Control Policy, Models, and Mechanisms—Concepts and Examples

Chapter 2: Access Control Policy, Models, and Mechanisms—Concepts and Examples

Aknowledge of access control models, mechanisms, and concepts is essential in understanding how RBAC fits into the field of computer security. This chapter introduces these important concepts.

2.1 Policy, models, and mechanisms

While authentication mechanisms ensure that system users are who they claim to be, these mechanisms say nothing about what operations users should or should not perform within the system. To afford protection to that effect, it is necessary to use access control.

Access control is concerned with determining the allowed activities of legitimate users, mediating every attempt by a user to access a resource in the system. A given IT infrastructure can implement access control systems in many places and at different levels. Operating systems use access control to protect files and directories. Database management systems (DBMSs) apply access control to regulate access to tables and views. Most commercially available application systems implement access control, often independent of the operating system or DBMS, or both, on which they may be installed.

The objectives of an access control system are often described in terms of protecting system resources against inappropriate or undesired user access. From a business perspective, this objective could just as well be described in terms of the optimal sharing of information. After all, the greater objective of IT is to make information available to users and applications. A greater degree of sharing gives rise to increased productivity. Although on the surface, access control appears to get in the way of this objective, in reality, a well-managed and effective access control system actually facilitates sharing. A sufficiently fine-grained access control mechanism can enable selective sharing of information where in its absence, sharing may be considered too risky altogether.

When considering any access control system one considers three abstractions of control: access control policies, access control models, and access control mechanisms. Policies are high-level requirements that specify how access is managed and who, under what circumstances, may access what information. While access control policies may be application-specific and thus taken into consideration by the application vendor, policies are just as likely to pertain to user actions within the context of an organizational unit or across organizational boundaries. For instance, specific policies may pertain to the resources that can be accessed by consultancies, or other business partners. Such policies may span multiple computing platforms and applications. Policies may pertain to resource usage within or across organizational units or may be based on need-to-know, competence, authority, obligation, or conflict-of-interest factors. Although there are several well-known access control policies, generating such a list is of limited value, since business objectives, tolerance for risk, corporate culture, and the regulatory responsibilities that influence policy differ from enterprise to enterprise, and even from organizational unit to organizational unit. The access control policies within a hospital may pertain to privacy and competency (e.g., only doctors and nurse practitioners may prescribe medication), and hospital policies will differ greatly from those of a military system, or a financial institution. Even within a specific business domain, policy will differ from institution to institution. Furthermore, access control policies are dynamic in nature, in that they are likely to change over time in reflection of ever evolving business factors, government regulations, and environmental conditions. However, because policy requirements can rarely be completely determined in advance, access control systems are best designed to flexibly accommodate a wide variety of changing policies.

At a high level, access control policies are enforced through a mechanism that translates a user’s access request often in terms of a simple table lookup—to grant or deny access. Access control mechanisms come in a wide variety of forms, each with distinct policy advantages and disadvantages. Although no well-accepted standard yet exists for determining their policy support, access control mechanisms can be characterized in a number of different ways, each bearing policy implications. In general, access control mechanisms require that security attributes be kept about users and resources. User security attributes consist of things like user identifiers, groups, and roles to which users belong, or they can include security labels reflecting the level of trust bestowed on the user. Resource attributes can take on a wide variety of forms. For example, they can consist of sensitivity labels, types, or access control lists. In determining the user’s ability to perform operations on resources, access control mechanisms compare the user’s security attributes to those of the resource. Access control checks can be determined (evaluated) based on a previously determined set of rules. For example, the security label of the user must be greater than or equal to the security label of the resource for the user to read the contents of the resource. Access control checks can also be determined based on an attribute-matching algorithm. The user may perform a read operation on a resource if the user’s identity, and read operation pair is included in the access control list of the resource. Other characteristics of access control mechanisms include attribute review and management capabilities. For example, can the access control system determine the permissions that are associated with a user or the users that can access a resource, or better yet both? Who can specify permissions? Can permission specification be delegated, and if so, does delegation infer further delegation?

From a consumer’s perspective, determining the policy implications of a given access control mechanism is a formidable task. The fact that most enterprises need to deal with a wide variety of access control mechanisms only compounds this problem.

To provide greater policy support and control, a number of enterprise management and resource-provisioning vendors offer administrative capabilities over the native access control mechanisms of file management, database management, applications, and host and network operating systems. The result is an access control management system, on top of an access control management system, on top of potentially still another access control system. What are the policy implications of this arrangement?

Rather than attempting to evaluate and analyze access control systems exclusively at the mechanism level, security models are usually written to describe the security properties of an access control system. Access control models are written at a level of abstraction to accommodate a wide variety of implementation choices and computing environments, while providing a conceptual framework for reasoning about the policies they support. Access control models are of general interest to both users and vendors. They bridge the rather wide gap in abstraction between policy and mechanism.

Models can be promoted for their support of policy, and mechanisms can be designed for their adherence to the properties of the model. Users see an access control model as an unambiguous and precise expression of requirements. Vendors and system developers see access control models as design and implementation requirements.

Access control models and mechanisms are often characterized in terms of their policy support. On one extreme an access control model may be rigid in its implementation of a single policy. On the other extreme, a security model will allow for the expression and enforcement of a wide variety of policies and policy classes. From the 1990s to the present, security researchers have sought to develop access control mechanisms and models that are largely independent of the policy for which they can be used. This is a generally considered to be a desirable objective in that it allows the use of a common mechanism for a wide variety of purposes.

2.2 Subjects and objects

There are many access control models and mechanisms, most of which are defined in terms of subjects and objects. A subject is a computer system entity that can initiate requests to perform an operation or series of operations on objects. The subjects may be users, processes, or domains: A domain is a protection environment in which a process executes. At some level of discourse, a subject is considered to be a process or task that operates on behalf of the user within a computing environment. An object is a system entity on which an operation can be performed. Within the context of an operating system, an object might represent a file, while within the context of a DBMS, an object might represent a table or a view. An executable image of a program residing in memory or stored on disk is considered to be an object; however, during its execution it becomes part of a process and, as such, is treated as part of the subject. Access to an object usually implies access to the information it contains, but it may pertain to an exhaustible system resource, such as a device. Other examples of objects include buffers, registers, blocks, pages, segments, file directories, programs, processors, and printers.

An object is an abstract concept that is useful for purposes of generically modeling access control approaches and describing access control mechanisms. However, from an enterprises’ perspective, there are two types of objects: resource objects and system objects. Resource objects are the objects of general interest to the system’s users and as such justify the very existence of the system. System objects are those objects that serve the system and that are merely necessary for its correct operation. It is because of the sensitivity of resource objects that system objects need to be protected.

In many situations a subject can be thought of as a user, but within a computer system, a subject is more precisely defined as a process or a collection of processes that act on a user’s behalf. Although users can typically be considered human beings, users can also represent other requesting entities such as machines or devices. It is imperative that all subjects have unique identifiers. For instance, subjects acting on behalf of human users may inherit the user’s ID obtained through the identification and authentication process. However, a user may sign onto the system as different subjects depending on which resources and applications the user wishes to access. For instance, a user may have a need to invoke multiple applications. Under these circumstances, two or more subjects would correspond to the same user. Because a subject can invoke or create other subjects, subjects can be represented as objects where the children subjects may be executed across platforms or applications, or both.

2.3 Reference monitor and security kernel

Since its introduction in the "Anderson Report" [1], the Reference Monitor concept has served the security community in two ways. First, it provides an abstract model of the necessary properties in achieving a high-assurance access control mechanism. Second, it has been used as guidance in the design, development, and implementation and subsequent analyses of secure IT systems.

The reference monitor (see Figure 2.1) is an abstract concept, whereby all accesses that subjects make to objects are authorized based on the information contained in an access control database. Conceptually, the reference monitor represents the hardware and software portion of an operating system that is responsible for the enforcement of the security policy of the system. The access control database is the embodiment of this policy in terms of subject and object attributes and access rights. When a subject attempts to perform an operation (e.g., read or write) on an object, the reference monitor must perform a check, comparing the attributes of the subject with that of the object. In addition, the reference monitor, with respect to some security policy, must control the specific checks that are made and all modifications to the access control database.

Figure 2.1: Reference monitor: All attempts by a subject to access an object are controlled by the reference monitor in accordance with a security policy embodied in the access control database. Security-relevant events are stored in the audit file.

As an abstraction, the reference monitor does not dictate any specific policy to be enforced by the system, nor does it address any particular implementation. Rather, the reference monitor defines an assurance framework that has been used for over 3 decades in the design, development, and implementation of highly secure IT systems, and it has served as the foundation in evaluation of the relative degrees of trust that can be assigned to a multiuser computing system.

The abstract requirements of a reference monitor are comprised of three fundamental implementation principles, described as follows:

Completeness: It must be always invoked and impossible to bypass.
Isolation: It must be tamper-proof.
Verifiability: It must be shown to be properly implemented.

These principles provide architectural guidance pertaining to the design and development process of an access control system. The degree to which a system complies with these design principles has served as a metric for measuring the level of confidence in the correctness of the system’s security controls.

2.3.1 Completeness

The completeness principle requires that a subject can reference an object only by invoking the reference monitor. Although this principle may seem intuitive—and although it might be expected that any reasonable operating system would meet this requirement—few if any mainstream operating systems completely adhere to this principle. The difficulty in meeting the absolute meaning of this principle stems from two issues. The first issue is what are considered to be the objects in the system. In general, objects are interpreted to be any system entities that can store information. Obvious places where information may be stored include files, directories, memory, and buffers. Most operating systems make reasonable attempts at controlling access to these resources. However, there is a wide variety of not so obvious places where information such as file names, segments, processors, and status and error messages and registers are stored. The completeness principle requires that all objects must be protected—not just the obvious ones.

The second architectural challenge pertaining to the completeness principle is the prevention of access to objects through methods (documented or otherwise) other than through the invocation of the policy-preserving access checker. For example, a subject could bypass a file system and issue a read request directly to the physical location of a file on disk. Access control is a basic function of not only operating systems; it is included within DBMSs and other large application programs. How does the DBMS prevent its objects (e.g., table and views) from being accessed through the underlying operating system? How do operating systems prevent objects that are under the control of the file management system from being accessed through lower-level kernel functions?

2.3.2 Isolation

The isolation principle states that the access mediation function is tamperproof. It must be impossible for a penetrator to attack the access mediation mechanism in a manner that affects the proper performance of access checks. Even though most resource management systems are designed to protect themselves against accidental and overt break-in attempts, meeting the absolute requirements of the isolation principle of the reference monitor usually requires a security architecture consisting of both hardware and software features.

The implementation of a security kernel (Figure 2.2) is one way to achieve this isolation. The security kernel is a minimal implementation of the security-relevant features of the system. The security kernel is implemented as a primitive operating system function responsible for the enforcement of security policy. It is implemented on top of the hardware base and beneath non-security-relevant operating system functions in a domain of its own execution. Systems typically achieve this isolation using the same hardware features that are commonly used to prevent user programs from corrupting operating system code and data. The security kernel runs in the most privileged domain and has access to all memory and instructions, while the less privileged domains have access to only a portion of memory and a subset of system instructions. The important security feature is that the kernel executes in the most privileged domain and is thus protected from the code that is executed in the outer two rings. Although a process may run in any one of these domains at any moment in time, when the process is running in a given domain, that process is protected from corruption by other processes through process isolation mechanisms.

Figure 2.2: Multidomain architecture: The security kernel is an interface layer on top of hardware and controls operating system and user code and date.

Since human programmers create process isolation features as well as all other security-relevant software, kernel code is subject to flaws and thus must be verified to be correct. This brings us to the third principle of the reference monitor.

2.3.3 Verifiability

The principle of verifiability is met through software engineering practices and design criteria. The idea is that the security kernel is made as small and simple as possible, by excluding any functionality for which the security of the system is not dependent, and by reducing the kernel to a small set of clean kernel interfaces. This is made possible through the use of sound software engineering practices. For instance, the security kernel should make use of modularity, abstract specification, and information hiding. Since the ultimate goal is to demonstrate the correctness of the kernel, thorough code inspections and positive and negative testing are critical. In extreme cases, formal mathematical modeling, formal specification, and verification techniques are applied in an attempt to prove the correctness of the kernel’s implementation.

2.3.4 The reference monitor—necessary, but not sufficient

The reference monitor concept does not charge a system with enforcing any particular access control policy. It is the job of enterprises to articulate these requirements for their computer systems. From an assurance perspective, the design principles of the reference monitor should be viewed as a necessary prelude to assurance, but the reference monitor is not sufficient. Even if all vendors were to rigorously adhere to the design principles of the reference monitor, most enterprises have little control over what policies are supported by the products they buy. Essentially, consumers are forced to make do with the policy and access control management decisions of their vendors. This book introduces three additional design principles that are viewed by its authors as critical components of any access control system. These principles are described as follows

Flexibility: The system should be able to enforce the access control policies of the host enterprise.
Manageability: The system should be intuitive and easy to manage.
Scalability: The system’s management and enforcement functions should scale to the number of users and the number of resources that are scattered across the computing platforms of the host enterprise.

By inserting these additional principles, we acknowledge that an access control system consists of more than a robust access mediation function, and includes the properties of policy configuration, ease of use, and, to some extent, interoperability.

2.4 DAC policies

DAC is a means of restricting access to objects based on the identity of users or the groups to which they belong, or both. The controls are discretionary in the sense that a user or subject given discretionary access to a resource is capable of passing that information along to another subject. To provide this discretionary control, DAC mechanisms usually include a concept of object ownership, where the object’s "owner" has control permission to grant access permission to the object for other subjects. This definition of DAC has its origins with the TCSEC [2] and is rationalized based on the DoD’s regulatory requirements for need-to-know access to classified or sensitive information: "… no person may have access to classified information unless … access is necessary for the performance of official duties." By far the most common mechanism for implementing DAC policies is through the use of ACLs.

DAC mechanisms tend to be very flexible and are widely used in commercial and government sectors. Throughout the mid 1980s and 1990s, many organizations considered DAC mechanisms to be the standard of due care. During this period virtually every computer vendor demonstrated DAC compliance by undergoing a C2 TCSEC (discretionary protection) evaluation.

Even though DAC mechanisms are in wide commercial use today, they are known to be inherently weak for two reasons: First, granting read access is transitive. For example, when Chris grants Frank read access to a file, nothing stops Frank from copying the contents of Chris’s file to an object that Frank controls. Frank may now grant any other user access to the copy of Chris’s file unbeknownst to Chris. Second, DAC mechanisms are vulnerable to "Trojan horse" attacks. Because programs inherit the identity of the invoking user, Frank may, for example, write a program for Chris that, on the surface, performs some useful function, while at the same time reads the contents of Chris’s files and writes the contents of the files to a location that is accessible by both Chris and Frank. Frank may then move the contents of the files to a location not accessible to Chris. Note that Frank’s Trojan horse program could have destroyed the contents of Chris’s files. When investigating the problem, the audit files would indicate that Chris destroyed his own files. What a dope!

2.5 Access control matrix

Many systems use Lampson’s access control matrix [3] to represent and interpret the particular security policy. From a theoretical perspective, the access control matrix has traditionally been used to represent the secure state of an access control system. The access matrix is an array containing one row per subject in the system and one column per object. Table 2.1 illustrates a simple access control matrix. The entries in the matrix specify the operations of, or the type of access that each subject has to, each object. The basic function of an access control system is to ensure that only the operations specified by the matrix can be executed.

Table 2.1: Example Access Control Matrix
Subject/Object	File_1	File_2	File_3	Process_1

Chris	Read, write	—	Write	—
Janet	—	Execute	—	Suspend
Barbara	—	Read	Read	—
Frank	Read	—	—	—

Although an access control matrix is an interesting construct from a theoretical perspective, for a system with a large number of users and objects, the matrix will become very large and will be sparsely populated. As such, an access control system is rarely implemented as a matrix but is almost always implemented as a representation of the matrix. There are two primary representations of the access control matrix as implemented in computer systems today: ACLs and capability lists.

2.5.1 ACLs and capability lists

In a capability system, access to an object is allowed if the subject that is requesting access possesses a capability for the object. A capability is a protected identifier that both identifies the object and specifies the access rights to be allowed to the accessor who possesses the capability. In a capabilitybased system, access to protected objects is granted to the would-be accessor possesses a capability for the object. This approach corresponds to storing the matrix by rows. Table 2.2presents the capability lists corresponding to the access control matrix. Each subject is associated with a capability list, which stores its approved operations to all concerned objects. A subject possessing a capability is proof of the subject having the access privileges. The principle advantage of capabilities is that it is easy to review all accesses that are authorized for a given subject. On the other hand, it is difficult to review the subjects that can access a particular object. To do so would entail an examination of each and every capability list. It is also difficult to revoke access to an object given the need for a similar examination. For this reason, capability lists have been criticized in their support of DAC policies and therefore not commercially popular.

Table 2.2: Capability List
Subject

Chris	File_1: Read, Write	File_3: Write
Janet	File_2: Execute	Process_1: Suspend
Barbara	File_2: Read	File_3: Read
Frank	File_1: Read

ACLs implement the access control matrix by representing the columns as lists of users attached to a protected object. Each object is associated with an ACL that stores the subjects and the subject’s approved operations for the object. The list is checked by the access control system to determine if access is granted or denied. Table 2.3 presents the ACLs corresponding to the access control matrix in Table 2.1.

Table 2.3: ACL
Object

File_1	Chris: Read, write	Frank: Read
File_2	Janet: Execute	Barbara: Read
File_3	Chris: Write	Barbara: Read
Process_1	Janet: Suspend

The principal advantage of ACLs is that they make it easy to review the users that have access to an object as well as the operations that users can apply to the object. In addition, it is easy to revoke access to an object by simply deleting an ACL entry. These advantages make ACLs ideal for implementing DAC policies that are object-oriented. Another advantage is that the lists need not be excessively long, if groups of users with common accesses to the object are attached to the object instead of the group’s individual members. Although the use of groups adds the need for additional administrative functions for managing membership within groups, the availability of groups generally makes the administration of ACLs more efficient. Generally speaking, the creation and management of groups should be strictly controlled, since becoming a member of a group can change the objects accessible to any member.

2.5.2 Protection bits

A DAC mechanism familiar to most users is the implementation of protection bits that are commonly included in UNIX operating systems. Protection bit mechanisms are similar to ACLs; however, instead of associating users and operation entries, bits are associated with an object. Protection bits divide users into three categories, described as follows

Self: The owner of a file;
Group: A collection of users sharing common access to a file;
Other: Everyone else besides the owner or the group members.

The access control system regulates access to a file by associating read (r), write (w), or execute (x) operations with each of these categories of users. For example, assume that a file has the following protection bits:

   (rwx) (r-x) (--x)

This string of bits indicates that self (the owner) has read, write, and execute permission to the file; the members of the group that is associated with the object have read and execute permission to the file; and all other system users have execute permission to the file. Note that the "–" marking indicates that the corresponding operation indicator is not present, thereby effectively denying the associated categories of users that particular operation on the file.

The user who created the file, by default, becomes the owner of the file. The owner of the file is typically the only one besides the superuser who can modify the protection bits.

Also note that there is only one group that is available for each file. The system administrator controls group memberships, so that as membership within these groups changes so will the capabilities of users to access files.

One problem with the protection bits method is that it is an access control mechanism that does not completely correspond to the access control matrix—thus, the system cannot accurately grant access to an object on an individual basis. For this reason many newer versions of UNIX and UNIXlike operating systems include ACL mechanisms.

2.6 MAC policies and models

In addition to DAC policies, the TCSEC defines MAC policies that are known to prevent the Trojan horse problem. With regard to this policy, security levels are assigned to users, with subjects acting on behalf of users and objects. Security levels have a hierarchical and a nonhierarchical component. For instance the hierarchical components might include unclassified (U), confidential (C), secret (S), and top-secret (TS) while the nonhierarchical components may include NATO and NUCLEAR. The security levels are partially ordered under a dominance relation, often written as "≥". For example, TS ≥ S. ≥ C. ≥ U and S (NATO, NUCLEAR) ≥ S (NUCLEAR) ≥ S. The security level of the user, often referred to as the user’s clearance level, reflects the level of trust bestowed to the user and must always dominate the security levels that are assigned to the user’s subjects. For example, Chris who is cleared to the S (NUCLEAR) level may initiate sessions at the S (NUCLEAR), S, C, or U levels. The security levels that are assigned to objects reflect the sensitivity of the contents of the objects.

Bell-Lapadula model With respect to the security level of a subject and the security level of an object, the Bell-LaPadula model [4] defines access control decisions in accordance with two properties

Simple security property: A subject is permitted read access to an object if the subject’s security level dominates the security level of the object.
Star property: A subject is permitted write access to an object if the object’s security level dominates the security level of the subject.

Satisfaction of these properties prevents users from being able to read information that dominates (i.e., is above) their clearance level. The simple security property directly supports this policy, never allowing a subject to read information that dominates the invoking user’s clearance level. The star property supports the MAC policy indirectly, by disallowing subjects from writing information of level x into a container (contents of an object) that could be subsequently read by a subject with a security level that is dominated by x. Intuitively, the star property prevents high information from ending up in a low container where a low user could read it.

With respect to the Bell-LaPadula model it is important to distinguish a user from her or his subjects. To illustrate this point consider a user Ralph, who is cleared to the top-secret level. Ralph’s range of capabilities includes the ability to read and write all objects for which his clearance level dominates. Ralph’s subjects, on the other hand, do not enjoy this same freedom. Although we can trust Ralph not to leak top-secret information, we are not able to levy such trust on Ralph’s subjects because subjects are typically computer programs, which may be compromised. Therefore, for Ralph to successfully write to an object at, for example, the secret level, Ralph must adjust his session to a level that is dominated by the secret security level of the object (see Figure 2.3).

Figure 2.3: User’s range of capabilities versus subject’s permitted accesses.

Now consider the case where Frank, who is cleared at the confidential level, wishes to steal secret nuclear instructions using the same Trojan horse program that he used to steal Chris’s files. Frank once again tricks Chris [who is cleared S, (NUCLEAR)], into invoking his malicious software, this time while invoking a S (NUCLEAR) session. Although Frank's Trojan horse will be able to successfully read the S(NUCLEAR) instructions, under the simple security property, the Trojan horse will fail in its attempt to write the instructions to a location that is accessible to Frank. Note, however, that Frank's malicious program may still destroy any of Chris's files that are labeled at Chris's session level or above. If Chris invokes Frank's software during an unclassified session, Frank, or more accurately speaking, Frank's program, is able to destroy all of Chris's files.

2.7 Biba's integrity model

Even though the Bell-LaPadula security model controls the writing of information, its policy is to protect confidentiality (read protection). The multilevel security policy does nothing to prevent unauthorized modification of information. Soon after the Bell-LaPadula security model was introduced, users quickly recognized that there was a need for a model with a property similar to the star property to prevent a process at a higher security level from reading lower-level objects without being negatively affected by information at the lower security level.

The Biba integrity model [5] was introduced in 1977 not as an alternative but as an adjunct to the Bell-LaPadula model. As the Bell-LaPadula model pertains exclusively to confidentiality issues while ignoring integrity issues, the Biba model (a dual of the Bell-LaPadula model) addresses integrity issues while sacrificing confidentiality. Under Biba, read and write restrictions are based on integrity levels (consisting of a hierarchical and categorical component) assigned to subjects and objects. The integrity level associated with a user indicates the user's level of trust regarding modification of information at that level, and the integrity level associated with an object reflects the object's sensitivity regarding its modification. For example, these may include critical (C), important (I), and ordinary (O). The properties of the Biba model are similar to the Bell-LaPadula model except that the dominance relations controlling read and write are reversed. These relations are described as follows

Simple integrity property: A subject is permitted read access to an object if the object's security level dominates the security level of the subject.
Integrity star property: A subject is permitted write access to an object if the subject's security level dominates the security level of the object.

In compliance with the properties of this model, writes from lower levels are prohibited, as are reads from higher levels to lower levels.

2.8 Clark-Wilson model

While the TCSEC did a great deal to spur research and development of computer security products, most of the commercial world recognized that it was of limited benefit for their operations. Clark and Wilson documented the differences between commercial and military security requirements in detail in 1987 [6], arguing that the primary concern for most commercial applications is integrity, rather than secrecy. For example, the 600-year-old principle of double-entry bookkeeping helps to ensure the accuracy and integrity of accounts by requiring that every credit entry be matched by a debit entry to ensure a balance between the source and destination of funds. Integrity in the computer security context refers to the accuracy and authenticity of information, as well as the need to ensure that objects are modified only in authorized ways by authorized personnel.

Clark and Wilson documented a generalized view of commercial security policies, showing how they differed from the military-oriented policies that are the focus of the TCSEC. They proposed two principles as most important in ensuring information integrity: well-formed transactions and SoD. Wellformed transactions constrain the ways in which users can modify data, thus ensuring that all data that starts in a valid state will remain so after the execution of a transaction. The basic unit of access control in the ClarkWilson model is the "access control triple," composed of user, transformation procedure, and constrained data item (see Figure 2.4).

Figure 2.4: Clark-Wilson access control triple.

A transformation procedure (TP) is a transaction, and a constrained data item (CDI) is one for which integrity must be preserved. Unconstrained data items (UDIs) are those that are not protected by the integrity model. Integrity verification procedures (IVPs) ensure that a data item is in a valid state. Clark and Wilson proposed nine rules to ensure the integrity of data. They are described as follows:

For any CDI, there must also be an IVP that ensures that the data item is in a valid state.
Every TP that modifies a CDI must be certified to modify CDIs only in valid ways.
A CDI can only be modified by a certified TP.
Every TP must be certified to log its changes to CDIs.
Every TP that takes input from a UDI must be certified to ensure that it will transform UDIs to CDIs only in valid ways.
Only certified TPs can modify UDIs.
A user can access CDIs only through TPs for which the user is authorized.
Every user must be authenticated by the system before executing a TP.
Only a security administrator can authorize users for TPs.

Unlike the Bell-LaPadula security model, which relies on access mediation in the operating system kernel, Clark and Wilson's approach relies on application-level controls. This difference in design results from the goals of the two models. The military multilevel security model seeks to control information flow, which can be defined in terms of low-level read and write operations. The commercial integrity model, as defined by Clark and Wilson, must ensure that information is modified only in authorized ways by authorized people, a requirement that is impossible to meet using only control over kernel-level operations. The importance of control over transactions, as opposed to simple read and write access, can be seen by considering typical banking transactions. Tellers may execute a savings deposit transaction, requiring read and write access to specific fields within a savings file and a transaction log file. An accounting supervisor may be able to execute correction transactions, requiring exactly the same read-and-write access to the same files as the teller. The difference is the process executed and the values written to the transaction log file.

SoD is another major component of the Clark and Wilson model that contributes to integrity, preventing authorized users from making improper modifications. This goal is achieved indirectly by separating all operations into multiple subparts and requiring that a different person perform each subpart. The process of purchasing and paying for some item, for example, might involve authorizing a purchase order, recording the arrival of the item, recording the arrival of the invoice, and authorizing payment. The last step should not be performed unless the previous three have occurred. If a different person performs each step, improper modification should be detected and reported, unless some of these people conspire. If one person can execute all of these steps, then fraud is possible—an order is placed and payment made to a fictitious company without any actual delivery of an item. In such a case, the books appear to balance; the error is in the correspondence between real and recorded inventory.

2.9 The Chinese wall policy

The Chinese wall policy is simple and easy to describe; however, as we will see, its implementation and deployment is less straightforward. Brewer and Nash [7] identified the policy to address conflict-of-interest issues related to the consulting activities within banking and other financial disciplines. Like Clark-Wilson, the Chinese wall policy is application-specific in that it applies to a narrow set of activities that are tied to specific business transactions. The stated objective of the Chinese wall policy is to prevent illicit flows of information that can result in a conflict of interest. Consultants naturally are given access to proprietary information to provide a service for their clients. When a consultant gains access, for example, to the competitive practices of two banks, the consultant gains knowledge—amounting to insider information—that can undermine the competitive advantage of one or both institutions or that can be used for personal profit. The objective of the Chinese wall policy is to identify and prevent the possibility for the flow of information that can give rise to such conflicts.

Company-sensitive information is categorized into mutually disjoint conflict-of-interest categories (COIs). Each company belongs to only one COI, and each COI has two or more member companies. The membership within a COI includes like companies, whereby a consultant obtaining sensitive information regarding one company would risk a conflict of interest if he or she were to obtain sensitive information in regard to another. Several COIs may coexist. For example, COI₁ may pertain to banks, while COI₂ may pertain to energy companies. The Chinese wall policy aims to prevent a consultant from reading information for more than one company in any given COI.

There are several observations that we can make regarding this policy with respect to read operations: First, as long as a consultant has not read information belonging to any institution, the consultant is not yet bound by the policy and is free to read any sensitive information of any institution. Note that although a consultant may be free to read sensitive information under the Chinese wall policy, she or he may be restricted from reading sensitive information with respect to another policy—say a DAC policy. Second, once a consultant has read sensitive information of say, bank A, the consultant is prohibited from reading sensitive information belonging to any other bank included in the COI of which bank A is a member. Third, all consultants are free to read all the public information of all institutions.

As is evident, the Chinese wall policy is relatively straightforward regarding read operations. We now consider the implications of write operations with respect to this policy as defined in the Brewer-Nash model.

2.10 The Brewer-Nash model

This model views data as objects, each belonging to a company dataset. The company datasets are further categorized into COIs.

Similar to Bell-LaPadula, Brewer-Nash defines two rules, one for reading and one for writing. Under the read rule, subject S can read object O only if one of the following is true

O is in the same company dataset as some object previously read by S.
O belongs to a COI class for which S has yet to read an object.

Under the write rule, subject S can write object O only if the following are true:

S can read O under the read rule.
No object can be read within a different company dataset than the one for which write access is requested.

Note that the Brewer-Nash rules do not make a distinction between users and subjects, as does the Bell-LaPadula model, but instead recognizes subjects to include both users and the processes that are acting on behalf of the user. However, similar to Bell-LaPadula, the Brewer-Nash rule for writing takes into consideration the possibility of a Trojan horse.

In illustrating the need for the write rule, consider the case in which Chris has read access to energy company A objects and read and write access to bank A objects, and Frank has read access to energy company A and bank B objects. A Trojan horse program running with Chris's privileges may read bank A objects and write to energy company B objects, giving Frank read access to both bank A and bank B objects.

It is also interesting to note the temporal differences between these two models. With respect to Bell-LaPadula, the policies regarding reading and writing are applied within the life span of a subject-user session. With respect to the Brewer-Nash model, the policy regarding reading applies for the life of the user. Once a user reads an object from a company data set, the user is forever precluded from reading an object from the data set of another company belonging to the same COI.

2.11 Domain-type enforcement model

The domain-type enforcement (DTE) model is an abstraction of the concepts involved in the DTE mechanism. The DTE mechanism [8], in turn, is an enhanced type enforcement (TE) mechanism, which is a table-oriented access control mechanism, developed by Boebert and Kain in the 1980s [9] in support of the Bell-LaPadula MAC model. In particular the DTE mechanism has been used in firewalls [10] and operating systems [11] and has been shown to support a variety of security policies expressible through RBAC models [12].

The DTE model, like many other access control models, divides the computerized system into two logical entities: subjects and objects. Subjects are active entities (usually processes). Objects are passive entities (e.g., files, directories, devices, and memory segments). A domain is associated with a subject. A type is associated with an object. The assignment of a "domain" label for a subject generally depends upon its function (e.g., a business process transaction). An object is assigned a type based on its integrity requirements. Access control permissions are associated with both domains and types. This gives rise to two groups of permissions: domain-domain permissions and domain-type permissions. Each of these two groups of permissions is represented using corresponding table types. The domain-domain access control table (DDAT) is a two-dimensional table with an entry for each ordered pair of domains. Similarly, the domain-type access control table (DTAT) is a two-dimensional table with an entry for each (domain, type) pair. Since there can be more than one permission associated with a domain-domain pair or domain-type pair, each entry in these tables contains a set of the permissions. All the entries in these two types of tables together constitute the DTE database for an environment.

Examples of domain-domain permissions (in the context of a UNIX operating system) are create (C) and kill (K). Examples of domain-type permissions are read (R), write (W), execute (E), and browse directory (T). The semantics of domain-type permissions should be self-evident. The domaindomain permissions are created to express allowed interactions between subjects. For example, a subject A (process A) can create an instance of another process (process B) only if there exists a create entry between subject A's domain and subject B's domain.

The DDAT and DTAT tables in DTE are conceptually similar to the access control matrix described in Section 2.5. However, DTE considerably reduces table entries by grouping subjects into domains and objects into types before specifying access control permissions.

Several comparisons can be made between the concepts of the DTE model and the RBAC model. RBAC ties users to roles and describes how a role limits the operations available to a user. DTE ties subjects to domains and describes how a domain limits the operations available to a subject. It is these similarities in concepts that have been utilized by Hoffman [12] to implement RBAC-expressible policies in the DTE-based secure operating system LOCK. Specifically RBAC model entities have been mapped to DTE model entities and the underlying DTE mechanism then facilitates implementation of the RBAC policy. Hoffman's implementation takes a set of roles, a set of users, and user-role assignments and links them to DTE model entities like subjects and domains. Each subject is assigned a role, and users are associated with a subject. For every subject, the role of the subject must be an authorized role for the subject's user. Similarly, a set of domains is associated with a role. Since a subject is already associated with a role, the domain of a subject should be in the set of domains authorized for the role. Thus, by constraining subject-role association and user-subject association using the user-role assignments of the RBAC model and by constraining the subject-domain association using the role-domain assignment, a DTE model can be made to implement the policies represented by an RBAC model. Furthermore, the abstract set of permissions associated with a role takes a concrete form when roles are assigned to domains, since the domains in a DTE model encapsulate the processes relevant to a platform (e.g., daemons, file systems, and system utilities in an operating system). Since domains are associated with other domains and object types through DDAT and DTAT table entries, the specification of permissions associated with a role becomes complete.

References

Anderson, J. P., Computer Security Technology Planning Study, Volume II, ESD-TR-73-51, Electronic Systems Division, Air Force Systems Command, Hanscom Field, Bedford, MA, 01730 (October 1972).
DoD National Computer Security Center, Department of Defense Trusted Computer Systems Evaluation Criteria, December 1985, DoD 5200.28-STD.
Lampson, B., "Protection," ACM Operating Sys. Reviews, 8(1), 1974, pp. 18–24.
Bell, D. E., and L. J. LaPadula, Secure Computer Systems: Mathematical Foundations and Model, Bedford, MA: The Mitre Corporation, 1973. See also D. E. Bell and L. J. LaPadula, Secure Computer System: Unified Exposition and MULTICS Interpretation, MTR-2997 Rev. 1, Bedford, MA: The MITRE Corporation, March 1976; also ESD-TR-75-306, rev. 1, Electronic Systems Division, Air Force Systems Command, Hanscom Field, Bedford, MA, 01731.
Biba, K. J., Integrity Considerations for Secure Computer Systems, Bedford, MA: The MITRE Corporation, 1977.
Clark, D. D., and D. R. Wilson "A Comparison of Commercial and Military Computer Security Policies," IEEE Symposium of Security and Privacy, 1987, pp. 184–194.
Brewer, D., and M. Nash, "The Chinese Wall Security Policy," Proc. IEEE Computer Society Symposium on Research in Security and Privacy, April 1989, pp. 215–228.
Badger, L., et al., "A Domain and Type Enforcement Prototype," Usenix Computing Systems, Volume 9, Cambridge, MA, 1996.
Boebert, W., and R. Kain, "A Practical Alternative to Hierarchical Integrity Policies," Proceedings of the 8th National Computer Security Conference, October 1985.
Ostendorp, K. A., et al., "Domain and Type Enforcement Firewalls," DARPA Information Survivability Conference and Exposition, 2000, DISCEX ‘00, Vol. 1, 1999, pp. 351–361.
Tidswell, J., and J. Potter, An Approach to Dynamic Domain and Type Enforcement, Microsoft Research Institute, Department of Computing, Macquarie University, NSW, Australia, 2000.
Hoffman, J., "Implementing RBAC on a Type-Enforced system," Proceedings of the 13th Annual Computer Security Applications Conference, December 1997.

归类于：公司 — vickymade @ 3:57 pm 评论(0)

Artech House – Role-Based Access Control 002 Introduction

Overview

Access control—or authorization, in its broadest sense—has existed as a concept for as long as humans have had assets worth protecting. Guards, gates, and locks have been used since ancient times to limit individuals’ access to valuables. A need for access control in fact prompted the invention of what can be regarded as the world’s first secure computing system. In 1879, a Dayton, Ohio, saloonkeeper named James Ritty invented the "incorruptible cashier," which later became known as the cash register. Ritty’s invention reduced the common problem of employee pilfering by permitting access to the cash drawer only when a sale was rung up by entering the amount of the sale in full view of the customer. By recording the amount of sales and keeping a running total, the register made it possible for storeowners to ensure that the cash drawer contents matched the total sales made during the day.

In today’s information technology, authorization is concerned with the ways in which users can access resources in the computer system, or informally speaking, with "who can do what." Access control is arguably the most fundamental and most pervasive security mechanism in use today. Access control shows up in virtually all systems and imposes great architectural and administrative challenges at all levels of enterprise computing. From a business perspective, access control has the potential to promote the optimal sharing and exchange of resources, but it also has the potential to frustrate users, impose large administrative costs, and cause the unauthorized disclosure or corruption of valuable information.

Access control can take many forms. In addition to determining whether a user has rights to use a resource, the access control system may constrain when and how the resource may be used. For example, a user may have access to a network only during working hours. Some organizations may establish more complex controls, such as requiring that two staff members conduct certain high-risk operations such as opening a vault or launching a missile. The definition and modeling of access control stem from seminal papers of the early 1970s, the early standardization efforts of the 1980s, and the emergence of RBAC that began in the early 1990s, and it continues to this day. This chapter introduces the origins, history, and central concepts of access control, reviews popular forms of access controls in use today, and introduces the basic concepts of RBAC and its advantages for system, application, and network security.

1.1 The purpose and fundamentals of access control

Access control is only one aspect of a comprehensive computer security solution, but it is one of the most visible. Every time a user logs on to a multiuser computer system, access control is enforced. To gain a better understanding of the purpose of access control, it is worth reviewing the risks to information systems. Information security risks can be broadly categorized into the following three types, confidentiality, integrity, and availability, which can be remembered with the convenient mnemonic "CIA." These categories are described as follows:

Confidentiality refers to the need to keep information secure and private. This category may include anything from state secrets to confidential memoranda, financial information, and security information such as passwords.
Integrity refers to the concept of protecting information from being improperly altered or modified by unauthorized users. For example, most users want to ensure that bank account numbers used by financial software cannot be changed by anyone else and that only the user or an authorized security administrator can change passwords.
Availability refers to the notion that information is available for use when needed. Attacks that attempt to overload corporate Web servers, widely reported in the popular press, are attacks on availability.

Access control is critical to preserving the confidentiality and integrity of information. The condition of confidentiality requires that only authorized users can read information, and the condition of integrity requires that only authorized users can alter information in authorized ways. Access control is less obviously central to preserving availability, but it clearly has an important role: An attacker who gains unauthorized access to a system is likely to have little trouble bringing it down.

1.1.1 Authorization versus authentication

Authorization and authentication are fundamental to access control. They are distinct concepts but often confused. Part of the confusion stems from the close relationship between the two; proper authorization in fact is dependent on authentication.

Authentication is the process of determining that a user’s claimed identity is legitimate. Every computer user is familiar with passwords, the most common form of authentication. If Alice logs in as alice46 and then provides the correct password for user identification (ID) alice46, she has authenticated herself to the system. Less common forms of authentication include biometrics (e.g., fingerprint readers) and smart cards. Authentication is based on one or more of the following factors

Something you know, such as the password, personal identification number (PIN), or lock combination;
Something you have, such as a smart card, automatic teller machine (ATM) card, or key;
Something you are, or a physical characteristic, such as a fingerprint or retinal pattern, or a facial characteristic.

Clearly, authentication is normally stronger if two or more factors are used. A password can be guessed; a key can be lost; and face-recognition systems have a significant false positive rate, so using only one of these authentication methods may not provide an acceptable level of security. This is why banks require both cards and PINs to access ATMs rather than only a password, or only a key or card. If the card were lost, a thief would have to guess the PIN in only three tries to beat the authentication system.

While authentication is a process of determining who you are, authorization determines what you are allowed to do. Authorization refers to a yes or no decision as to whether a user is granted access to a system resource. An information system must maintain some relationship between user IDs and system resources, possibly by attaching a list of authorized users to resources, or by storing a list of accessible resources with each user ID. Note that authorization necessarily depends on proper authentication. If the system cannot be certain of a user’s identity, there is no valid way of determining if the user should be granted access.

1.1.2 Users, subjects, objects, operations, and permissions

A reasonably consistent terminology has developed over the past 3 decades for describing access control models and systems. Almost any access control model can be stated formally using the notions of users, subjects, objects, operations, and permissions, and the relationships between these entities. It is important to understand these terms, because the reader will encounter them not only in this book but also in most of the literature on access control and computer security.

The term user refers to people who interface with the computer system. In many designs, it is possible for a single user to have multiple login IDs, and these IDs may be simultaneously active. Authentication mechanisms make it possible to match the multiple IDs to a single human user, however.

An instance of a user’s dialog with a system is called a session.

A computer process acting on behalf of a user is referred to as a subject. Note that in reality, all of a user’s actions on a computer system are performed through some program running on the computer. A user may have multiple subjects in operation, even if the user has only one login and one session. For example, an e-mail system may be operating in the background, fetching e-mail from a server periodically, while the user operates a Web browser. Each of the user’s programs is a subject, and each program’s accesses will be checked to ensure that they are permitted for the user who invoked the program.

An object can be any resource accessible on a computer system, including files, peripherals such as printers, databases, and fine-grained entities such as individual fields in database records. Objects are traditionally viewed as passive entities that contain or receive information, although even early access control models included the possibility of treating programs, printers, or other active entities as objects [1].

An operation is an active process invoked by a subject. Early access control models that were concerned strictly with information flow (i.e., read- and-write access) applied the term subject to all active processes, but RBAC models require a distinction between subject and operation. For example, when an ATM user enters a card and correct PIN, the control program operating on the user’s behalf is a subject, but the subject can initiate more than one operation—deposit, withdrawal, balance inquiry, or others.

Permissions (or privileges) are authorizations to perform some action on the system. As used in this book, and in most computer security literature, the term permission refers to some combination of object and operation. A particular operation used on two different objects represents two distinct permissions, and similarly, two different operations applied to a single object represent two distinct permissions. For example, a bank teller may have permissions to execute debit and credit operations on customer records, through transactions, while an accountant may execute debit and credit operations on the general ledger, which consolidates the bank’s accounting data.

1.1.3 Least privilege

Least privilege is the time-honored administrative practice of selectively assigning permission to users such that the user is given no more permission than is necessary to perform his or her job function. The principle of least privilege avoids the problem of an individual having the ability to perform unnecessary and potentially harmful actions merely as a side effect of granting the ability to perform desired functions. The question then becomes how to assign the set of system permissions to the aggregate of functions or duties that correspond to a role of a user or subject acting on behalf of the user. Least privilege provides a rationale for where to install the separation boundaries that are to be provided by the access control mechanism. Ensuring adherence to the principle of least privilege is largely an administrative challenge that requires the identification of job functions, the specification of the set of permissions required to perform each function, and the restriction of the user to a domain with those privileges and nothing more.

Strict adherence to least privilege requires an individual to have different levels of permission at different times, depending on the task or function being performed. It must be recognized that in some environments and with some permissions, restricting permission because it is nominally unnecessary may inconvenience the user or place an additional burden on administrators. However, granting of excess privilege that potentially can be exploited to circumvent protection, whether for integrity or confidentiality, should be avoided whenever possible. It is also important that permissions not persist beyond the time that they are required for performance of duties.

1.2 A brief history of access control

Although security issues had been addressed in some early time-sharing computer systems from the 1960s, the discipline of computer security began to progress rapidly in the early 1970s. At this time large resource-sharing systems were becoming commonplace in government, military, and large commercial organizations. The field developed both in government and military systems, and in the commercial arena where applications such as ATMs required strong security.

1.2.1 Access control in the mainframe era

The growth in multiuser computer systems and the increased dependence of defense systems on computers led to efforts by the U.S. Defense Science Board to investigate the vulnerability of government systems in the late 1960s. University researchers also considered the problem. The earliest work in defining a formal, mathematical description of access control is that of Lampson [2], who introduced the formal notions of subject and object and an access matrix that mediated the access of subjects to objects. An access matrix is a simple conceptual representation in which the (i,j) entry in the matrix specifies the rights that subject i has to object j. An example is shown in Figure 1.1. Subjects (processes invoked by users) are allowed to access objects such as files or peripherals according to the rights specified in the matrix. For example, user Bob is allowed read and write access to the payroll file, and read access to the accounts receivable and accounts payable file.

	`General ledger`	`Payroll`	`Accounts receivable`	`Accounts payable`
`Alice`	`R,W`		`R`	`R`
`Bob`		`R,W`	`R`	`R`
`Charles`	`R`		`R`	`R`

Figure 1.1: Access matrix.

A RAND Corporation report from 1970 [3] provided a comprehensive analysis of security for DoD computer systems. Included in the report was the definition of a method to implement multilevel—relating to documents classified by a security level, such as confidential, secret, or top-secret— access control on a resource-sharing system, with separate considerations for local access and remote access where password-based authorization would be required. This document also discussed the basic requirements for controlling access to information based on a user’s clearance level and the classification level of files stored on the system. Proposals for a multilevel secure system were extended in a U.S. Air Force report [4] that included engineering development plans for such a system along with communications.

Bell and LaPadula [5] formalized military access control rules into a mathematical model suitable for defining and evaluating computer security systems. As formulated in this model, multilevel secure systems implement the familiar government document classification rule: Users are only allowed to access information that is classified at or below their own clearance level. Conceptually, this is a very simple policy, readily understood and followed by humans. However, as with much in information technology, implementing this seemingly simple policy on a computer system can be tricky. Unexpected loopholes and nonobvious interactions between different components of the system can leave a computer security system vulnerable. The Bell-LaPadula model was significant because it provided a formal (i.e., mathematical) model of the multilevel security policy, making it possible to analyze properties of the model in detail.

Two basic rules are required in the formal model: the simple security rule and the *-property, commonly known as "no read up" and "no write down." The simple security rule is obvious: A user with a particular clearance level cannot be allowed to read information above that level (e.g., a user with secret clearance cannot read top-secret documents). The *-property, which is essentially the reverse of the simple security rule, is required to maintain system security: A user operating at a particular clearance level can write information only at that level or above. For example, if a user is logged in at secret level, programs or processes operated by that user are not permitted to write information at the confidential level, although it could be written to a higher level, such as top-secret. (Note that this rule makes sense where we are concerned with processes operating on a computer. Obviously, a human being could log in at a high level, then print out or memorize information and re-enter it after logging in at a lower level.) Also included in the Bell-LaPadula model was the notion of categories, which refers to a vertical breakdown of security compartments across levels. In addition to having the proper clearance level, a user is required to be cleared for all of the categories attached to a classified document. For example, a document might be classified [Secret, nuclear, NATO]. To access the document, a user would need a clearance of secret or above and must also be cleared for the two categories—nuclear and NATO. (Chapter 2 provides a more detailed discussion of these rules.) This policy ensures that information cannot be downgraded either through unintentional or malicious actions of a process.

A 1976 paper by Harrison, Ruzzo, and Ullman showed that safety is inherently undecidable in a conventional access matrix view of security [6]. In other words, it is impossible to know whether a given configuration considered "safe" with respect to some security requirement would remain safe. If the system is started with a set of access rights to objects, it is impossible to know that the system will not eventually grant access rights that are not in the original matrix. Although the proof of this result is somewhat technical, the underlying reason for the undecidability is that users can give away access rights. If the system has no control over what rights are passed from one user to another, there is no way to be sure that an unauthorized user will not eventually receive rights improperly, through some chain of rights delegation.

1.2.2 Department of Defense standards

Codification of access control models in standards took a significant step forward in 1983, when the U.S. Department of Defense (DoD) published its Trusted Computer System Evaluation Criteria (TCSEC) [1], commonly known as the "Orange Book," for its orange cover. This standard defined in detail two important access control modes for military systems: discretionary access control (DAC) and mandatory access control (MAC). As the name suggests, DAC is a mode in which the creators or owners of files assign access rights, and a subject with discretionary access to information can pass that information on to another subject.

By itself, DAC is insufficient for implementing the document classification scheme used by the military. Since users in the DAC model of security can give away rights to access objects, the Harrison, Ruzzo, Ullman undecidability result applies to DAC. To provide a truly secure scheme in which a system is guaranteed to remain secure, MAC is required.

As usually implemented, MAC controls provide the multilevel security policy as formalized by the Bell-LaPadula model described in Section 1.2.1. (Chapter 2 provides a more detailed treatment of DAC and MAC policies.) The key feature of MAC is that, as its name implies, it is required for the mediation of all accesses of objects on the system. Since the access control system mediates all access to objects using rules imposed externally, users cannot give away permissions for object access. Since users are limited in the actions they can take, the access controls can ensure that the system will remain in a secure state regardless of user actions.

1.2.3 Clark-Wilson model

One goal of the TCSEC was to encourage a market for secure operating systems and computer security products. Many writers argued that systems meeting the lower levels of TCSEC requirements would be sufficient for commercial use. The hope was that a uniform market for security products would develop, with the TCSEC providing guidance for both commercial and military security.

Despite efforts to promote TCSEC-compliant systems as commercial security solutions, most commercial firms recognized that DAC and MAC were not sufficient for their needs. TCSEC-oriented systems are focused on the information flow and confidentiality of information. In a widely referenced 1987 paper, Clark and Wilson [7] argued that while confidentiality was important to commercial users, their primary concern pertains to integrity (i.e., ensuring that information is modified only in appropriate ways by authorized users).

When Clark and Wilson formalized business security practices into a security model, the result was quite different from the military security model formalized by Bell and LaPadula. The two central concepts in the Clark-Wilson model are the well-formed transaction and separation of duty (SoD). Well-formed transactions constrain the user to change data only in authorized ways. For example, a bank teller cannot modify an arbitrary part of a customer record, only those data fields that are incorporated into the particular transaction being run, such as a savings deposit or withdrawal. Complementing the well-formed transaction is the ancient principle of SoD, which ensures the consistency of changes made to critical data. A division manager, for example, can request an expenditure, but another person must approve it, and a third audits the completed transaction to ensure that fraud has not occurred. Implementing these rules in a computer system has been found to be as challenging as implementing information flow policies. One of the motivations of RBAC was to make commercial security policies easier to manage.

1.2.4 Origins of RBAC

Like the multilevel security policy formalized by Bell and LaPadula, RBAC has its roots in historical practices that predate the formal model, except that RBAC’s features stem primarily from the commercial world. Also like multilevel security, RBAC is conceptually simple: Access to computer system objects is based on a user’s role in an organization. Roles with different privileges and responsibilities have long been recognized in business organizations, and commercial computer applications dating back to at least the 1970s implemented limited forms of access constraints based on the user’s role within the organization. For example, on-line banking applications in that period included both teller and teller supervisor roles that could execute different sets of transactions, while simultaneously users at ATMs were able to execute another set of transactions against the same databases.

In the late 1980s and early 1990s researchers began recognizing the virtues of roles as an abstraction for managing privileges within applications and database management systems. A role was seen as a job or position within an organization. A role exists as a structure separate from that of the users who were assigned to the roles. Dobson and McDermid [8] used the term functional roles. Baldwin [9] called these structures named protection domains (NPDs) and stated that they could be related and organized into hierarchies based on NPD permission subsets. Also recognized was the use of roles in support of the principle of least privilege in which a role is created with minimum permissions in specification of duty requirements [10]. The Brewer and Nash model [11] presented a basic theory for use in implementing dynamically changing access permissions. The model is described in terms of a particular commercial security policy, known as the Chinese wall. The model is developed by first defining what a Chinese wall means and then defining a set of rules (SoD requirements) such that no user can ever access data from the wrong side of the wall. Nash and Poland [12] discussed the application of role-based security to cryptographic authentication devices commonly used in the banking industry.

These role-based systems were relatively simple and application-specific. That is, there was no general-purpose model defining how access control could be based on roles, and little formal analysis of the security of these systems. The systems were developed by a variety of organizations, with no commonly agreed upon definition or recognition in formal standards.

In 1992, NIST initiated a study [13] of both commercial and government organizations, and found that access control needs were not being met by products on the market at the time, many of which implemented only TCSEC-style discretionary controls, considered by many organizations as the "standard of due care." In many enterprises within industry and civilian government, end users do not "own" the information for which they are allowed access as assumed by DAC. For these organizations, the corporation or agency is the actual "owner" of system objects, and discretionary control on the part of the users may not be appropriate. Conventional MAC, focused on preserving confidentiality, is also inadequate for these organizations. Although enforcing a need-to-know policy is important where classified information is of concern, there existed a general need to support subject-based security policies, such as access based on competency, the enforcement of conflict-of-interest rules, or access based on a strict concept of least privilege. Supporting such policies requires the ability to restrict access based on a user function or role within the enterprise.

A solution to meet these needs was proposed in 1992 by Ferraiolo and Kuhn [14], integrating features of existing application-specific approaches into a generalized RBAC model. This paper described, in a simple formal manner, the sets, relations, and mappings used in defining roles and role hierarchies, subject-role activation, and subject-object mediation, as well as the constraints on user-role membership and role-set activation. Three basic rules were required:

Role assignment: A subject can execute a transaction only if the subject has selected, or been assigned to, a role. The identification and authentication process (e.g., login) is not considered a transaction. All other user activities on the system are conducted through transactions. Thus, all active users are required to have some active role.
Role authorization: A subject’s active role must be authorized for the subject. With rule 1, this rule ensures that users can take on only roles for which they are authorized.
Transaction authorization: A subject can execute a transaction only if the transaction is authorized for the subject’s active role. In concert with rules 1 and 2, this rule ensures that users can execute only transactions for which they are authorized.

The formal description of the model is given in Figure 1.2. A key feature of this model is that all access is through roles. A role is essentially a collection of permissions, and all users receive permissions only through the roles to which they are assigned, as shown in Figure 1.3. Within an organization, roles are relatively stable, while users and permissions are both numerous and may change rapidly. Controlling all access through roles therefore simplifies the management and review of access controls.

Original formal description of RBAC
For each subject, the active role is the one that the subject is currently using: AR(s : subject) = {the active role for subject s}
Each subject may be authorized to perform one or more roles: RA (s : subject) = {authorized roles for subject s}
Each role may be authorized to perform one or more transactions: TA (r : role) = {transactions authorized for role r}
Subjects may execute transactions. The predicate exec(s,t) is true if and only if subject s can execute transaction t at the current time; otherwise it is false: exec (s:subject,t:tran) = {true iff subject s can execute transaction t} Role assignment: A subject can execute a transaction only if the subject has selected or been assigned a role: s : subject,t : tran ⋅ exec(s,t) ⇒ AR (s) ≠ Ø Role authorization: A subject’s active role must be authorized for the subject: s: subject ⋅ AR(s) ⊆ RA (s) Transaction authorization: A subject can execute a transaction only if teh transaction is authorized for teh subject’s active role: s: subject,t : tran ⋅ exec(s,t)⇒ t ∊ TA (AR(s))
Note that because the conditional in rule 3 is "only if," this rule allows for the possibility that additional restrictions may be placed on transaction execution. That is, the rule does not gurantee a transaction to be executable just because it is in TA[AR(s)]. The set of transactions potentially executable by the subject’s active role. For example, a trainee for a supervisory role may be assigned the role of supervisor but may have restrictions applied to his or her role that limit accesible transactions to a subset of those normally allowed for the supervisor role.

Original formal description of RBAC

For each subject, the active role is the one that the subject is currently using:

AR(s : subject) = {the active role for subject s}

Each subject may be authorized to perform one or more roles:

RA (s : subject) = {authorized roles for subject s}

Each role may be authorized to perform one or more transactions:

TA (r : role) = {transactions authorized for role r}

Subjects may execute transactions. The predicate exec(s,t) is true if and only if
subject s can execute transaction t at the current time; otherwise it is false:

exec (s:subject,t:tran) = {true iff subject s can execute transaction t}

Role assignment: A subject can execute a transaction only if the subject has
selected or been assigned a role:
- s : subject,t : tran ⋅ exec(s,t) ⇒ AR (s) ≠ Ø
Role authorization: A subject’s active role must be authorized for the subject:
- s: subject ⋅ AR(s) ⊆ RA (s)
Transaction authorization: A subject can execute a transaction only if teh
transaction is authorized for teh subject’s active role:
- s: subject,t : tran ⋅ exec(s,t)⇒ t ∊ TA (AR(s))

Note that because the conditional in rule 3 is "only if," this rule allows for the
possibility that additional restrictions may be placed on transaction execution.
That is, the rule does not gurantee a transaction to be executable just because it is
in TA[AR(s)]. The set of transactions potentially executable by the subject’s active
role. For example, a trainee for a supervisory role may be assigned the role of
supervisor but may have restrictions applied to his or her role that limit accesible
transactions to a subset of those normally allowed for the supervisor role.

Figure 1.2: Formal description of RBAC from Ferraiolo and Kuhn [4].

Figure 1.3: RBAC relationships.

The most common method of implementing access control in a computer system is through access control lists (ACLs). All system resources, such as files, printers, and terminals, have a list of authorized users attached. This makes it easy and quick to answer the per object review question: "What users have access to object X?" Much more difficult is the per subject review question: "What objects can user X access?" Answering this question requires scanning all objects on the computer system, which may number in the millions; recording their access control lists; and finally reporting on user X. Measurements of real systems have shown that this process can take more than a day. A side effect of this scheme is that ACLs make it easy to add permissions to an object but hard to revoke all of a particular user’s permissions. In many systems, users are combined into groups, which are then used as entries in ACLs.

Readers familiar with conventional group mechanisms will recognize a superficial similarity between RBAC and groups. As normally implemented, a group is a collection of users, rather than a collection of permissions, and permissions can be associated with both users and the groups to which they belong, as shown in Figure 1.4. Because users may access objects based on either their user or group ID, it is possible for users to retain access permissions that should be revoked when group permission is removed from the object. The permission based on the individual user ID is in effect a loophole in the enforcement of the security policy. The RBAC requirement that all access be through roles helps to strengthen security significantly in real applications by eliminating this loophole.

Figure 1.4: Group access control relationships.

A second important feature of the Ferraiolo-Kuhn model is that roles are hierarchical—roles can inherit permissions from other roles Figure 1.5 —while groups are normally treated as flat collections of users. Also included in this model was a provision for constraints on role membership, although specific types of constraints were not proposed.

Figure 1.5: Example of a functional role hierarchy.

The 1992 paper showed that this model subsumes the Clark-Wilson model (i.e., the Clark-Wilson model is included as a special case). A subsequent NIST publication [15] investigated RBAC in more detail, proposing additional functions beyond those included in the 1992 model, and included specific forms for constraints to implement separation-of-duty requirements.

George Mason University Professor Ravi Sandhu, a well-known and influential security expert, described the Ferraiolo-Kuhn RBAC model as "an important innovation, which makes RBAC a service to be used by application…. Instead of scattering security in application code, RBAC will consolidate security in a unified service which can be better managed while providing the flexibility and customization required by individual applications" [16]. Dr. Sandhu went on to conduct extensive research and publish numerous papers in the area of RBAC. Several of his students have joined him in this research, and some have produced doctoral theses in areas related to RBAC.

In 1994, Nyanchama and Osborn [17] proposed a very generalized form of role organization called a role graph model. The authors showed that roles could be organized based on three role relationships: partial, shared, and augmented privileges. The role graph model is particularly useful in analyzing privilege sharing, which is critical in detecting and preventing conflict of interest relationships between roles. Gligor introduced the notion of "role types," which allow role administration to be simplified with parameterized types that are instantiated to produce roles. This work became the subject of the first U.S. patent in the area of RBAC [18].

In 1996, Sandhu and colleagues [19] introduced a framework of RBAC models, RBAC96, breaking down RBAC into four conceptual models. Shown in Figure 1.6, this framework specified a base model, RBAC0, that contains the minimal features of a system implementing RBAC. Two advanced models, RBAC1 and RBAC2, include RBAC0, but add (respectively) support for hierarchies and for constraints such as SoD. A fourth component, RBAC3, includes all aspects of the lower-level models. The Sandhu et al. RBAC96 framework established a modular structure for RBAC systems, providing for simplified commercial implementations that could offer basic RBAC0 functionality, or more advanced features as required by customers.

Figure 1.6: Sandhu et al. RBAC96 framework.

Largely due to a series of conferences sponsored by the Association for Computing Machinery (ACM), founded by Professor Sandhu and David Ferraiolo of NIST, a robust RBAC research community had developed, and today commercial implementations are providing ever more sophisticated RBAC systems. RBAC began to see application in a wide variety of areas. Early work by Barkley [20] showed that RBAC has a natural application in health care. Workflow management, an economically important field that deals with the automation of business processes, is another area where RBAC seems to be ideally suited to not only provide security, but serve as a framework for workflows as well. Barkley and Cincotta [21] and Bertino, Ferrari, and Atluri [22] introduced RBAC-based workflow systems.

In 2000, NIST initiated an effort to establish an international consensus standard for RBAC, publishing a proposal [23] in the ACM RBAC workshop. The proposed standard follows the RBAC96 structure and incorporates features developed out of subsequent discussions and formal comments received from the research and commercial vendor communities. In 2002 the proposed standard was submitted to the international standards process, and commercial firms have already begun building products that will conform to the RBAC standard.

What is most striking about RBAC’s history is its rapid evolution from a concept to its commercial implementation and deployment. Although this success can be attributed to a variety of factors, recognition of RBAC’s dual policy and productivity advantages have undoubtedly contributed to its present stature. In this respect, RBAC differs from many other security concepts, in that its costs of deployment need not be justified based solely on perceived threats and system vulnerabilities. Although RBAC allows for the enforcement of a wide variety of important access control policies that are either impractical or even impossible to enforce in its absence, RBAC’s productivity advantages alone are often sufficient in justifying its deployment. When taken together, these dual motivators can lead to a strong business justification. To improve the efficiency of heath care systems, the U.S. Health Insurance Portability and Accountability Act of 1996 (HIPAA) explicitly calls out RBAC requirements [24], and the U.S. Federal Aviation Administration cites RBAC in its specifications for National Airspace System security [25]. RBAC is now being prescribed as a generalized approach to access control. For instance, RBAC was found to be "the most attractive solution for providing security features in multidomain digital government infrastructure" [26] and has shown its great relevance in meeting the complex security needs of Web-based applications [27].

Although RBAC can be justified squarely on economics, something else was going on over the last decade. During this period, hundreds of papers were published on topics revolving on the theme of RBAC. As we have discussed, RBAC is a packaging of closely related and dependent access control and management features and ideas. Although the focus of RBAC is clearly on access control, in many respects RBAC can be viewed as a model for regulation and management of user actions and activities within IT environments. Furthermore, these activities have been encapsulated into highly intuitive role structures that appear naturally within most business environments. As it turns out, role structures not only apply to resource provisioning systems and access control and policy management systems, they also fit naturally into workflow, process management, collaborative, and virtual enterprise environments. When RBAC models first appeared, these enterprise applications were not envisioned. However, once published, and thoroughly examined, other researchers quickly began expanding and elaborating on RBAC concepts and structures.

The pervasiveness of RBAC’s application within modern day IT infrastructures is significant. Today, RBAC features are included at all levels of enterprise computing, including operating system, database management system, network, and enterprise management levels. RBAC is being incorporated and integrated within infrastructure technologies such as public key infrastructure (PKI), workflow management systems, and directory and Web services. In addition, RBAC is being proposed as an enabling technology in formulating metapolicies within collaborative and virtual enterprise systems.

1.3 Comparing RBAC to DAC and MAC

The principle motivations behind RBAC are the ability to specify and enforce enterprise-specific access control policies and to streamline the typically burdensome process of authorization management. RBAC represents a major advancement in flexibility and detail of control from the existing standards of DAC and MAC.

As defined in the TCSEC and commonly implemented, DAC is an access control policy and mechanism that permits system users to allow or disallow other users access to the objects under their control. The TCSEC DAC policy is defined as follows:

A means of restricting access to objects based on the identity of subjects or groups, or both, to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restricted by MAC) [1].

DAC, as the name implies, permits the granting and revocation of access permissions to be left to the discretion of the individual users. A DAC mechanism allows users to grant or revoke access to any of the objects under their control without the intercession of a system administrator.

For many enterprises within industry and civilian government, end users do not "own" the information to which they are allowed access as is assumed by DAC policies. For these organizations, the corporation or agency is the actual "owner" of system objects, and it may not be appropriate to allow users to give away access rights to the objects. With RBAC, access decisions are based on the roles individual users have as part of an organization. This includes the specification of duties, responsibilities, and qualifications. For example, the roles an individual associated with a hospital can assume include doctor, nurse, clinician, and pharmacist. Roles in a bank include teller, loan officer, and accountant. Roles can also apply to military systems; for example, target analyst, situation analyst, and traffic analyst are common roles in tactical systems. An RBAC policy is based on the functions or the actions that a user is allowed to perform within the context of an organization (referred to as either privileges or permissions). The users cannot normally pass their permissions on to other users at their discretion. For example, a doctor who may posses the permission to prescribe medication should not be able to pass that permission onto a clinician.

Security policy often supports higher level organizational objectives, such as maintaining and enforcing ethics pertaining to a judge’s chambers, or the laws and respect for privacy associated with the diagnosis of ailments, treatment of disease, and the administering of medication within a hospital. To support such policies, a capability to centrally control and maintain access rights is required. The security administrator, not the users for which the policies apply, must diligently represent the organization in specifying the access policy over organizational resources.

As such, RBAC is sometimes described as a form of MAC in the sense that users are unavoidably constrained by and have no influence over the enforcement of the organization’s protection policies. However, RBAC is different from TCSEC MAC. MAC is defined in the TCSEC as follows:

A means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to information of such sensitivity [1].

As rationalized in the TCSEC, MAC supports DoD requirements and regulations pertaining to unauthorized access to classified information, and in particular to the protection of the confidentiality (reading or observing) of sensitive information. Systems that support MAC policies are concerned with the unlawful flow of information from a high level to a low level. As such, policy support is with respect to controlling reading and writing. However, control over write operations is only concerned with preventing the indirect unlawful observation of sensitive information, and not with its integrity (unauthorized modification or destruction).

With regard to RBAC controls, policies may pertain to issues of confidentiality or integrity, or both: "Who can perform what actions?"

To distinguish RBAC from the policy specifics of MAC, RBAC is often characterized as nondiscretionary access control. RBAC allows for the nondiscretionary enforcement of a variety of protection policies that can be tailored on an enterprise-by-enterprise basis. The policies enforced within a stand-alone or distributed system are the net result of the administrative configuration of various components of RBAC.

1.4 RBAC and the enterprise

RBAC has emerged as the primary alternative to MAC and DAC because it is much better suited to the needs of commercial users than these earlier models. This section introduces a simple economic model that demonstrates RBAC’s cost effectiveness and then discusses how RBAC fits into a large organization.

1.4.1 Economics of RBAC

From a business perspective RBAC has the potential to offer several benefits. This includes greater administrative productivity in performing common authorization management functions. These administrative functions pertain to assigning permissions for new user access to resources (both new users and new resources), reviewing and selectively removing accesses that are no longer necessary (and potentially harmful) with respect to a user’s change of job assignment, and the completeness and immediacy of the removal of permissions in the event of a user’s separation from the enterprise. These same features have demonstrated their ability to increase user productivity by reducing the downtime between administrative events, where the enterprise would be deprived of productivity during the period when the user is unable to access system resources. There is usually a direct relationship between the cost of administration and the number of associations that must be managed in order to administer an access control policy: The larger the number of associations, the costlier and more error-prone access control administration. In most organizations, the use of RBAC reduces the number of associations that must be managed.

A simple economic model can be used to approximate the savings that results from using a role-based approach [28]. Job positions typically are occupied by more than one individual, and most positions require more than one permission in order for an individual in a job position to carry out the responsibilities of that position. One can describe the associations authorizing permissions to individuals who perform the responsibilities of a job position as an ordered pair consisting of a set of individuals and a set of permissions (U, P) where:

U = the set of individuals in a job position;
P = the set of permissions required to perform that job position.

The number of associations required to directly relate the individuals to those permissions is |U|⋅|P|, where

|U| = the number of individuals in the set U;
|P| = the number of permissions in the set P.

In other words, for each individual in U, there is an association for each permission in P.

A role can be described as a set of permissions. Thus, the set P can refer to a role, or a job position whose user-role and role-permission associations are represented by the ordered pair (U, P). The number of user-role and role-permission associations required to authorize each user in the set U for each of the permissions in the set P where P represents a role is |U| + |P| (i.e., an association with the role P for each individual in U and an association with the role P for each permission in P).

For a job position, if |U| + |P| < |U| ⋅ |P|, then the administrative advantage of RBAC over relating users directly with permissions is realized for that job position. A sufficient condition for |U| + |P| < |U| ⋅ |P| is |U|,|P|, > 2, which is typically the case for most job positions in most organizations.

If n is the number of job positions within an organization, then the administrative advantage of RBAC is realized organizationwide when

(Note that this is only an approximation, as users may frequently fill more than one role in an organization, and roles may be hierarchically related.)

In addition to cost savings due to greater administrative and user productivity, RBAC has the advantage of avoiding future expenses incurred through breaches of security or privacy policies. Because RBAC can map naturally to organizational and business structures, is more configurable then conventional identity-based access control mechanisms, and can be managed at an abstraction above and across the systems and applications for which it controls access, RBAC can enforce a greater number and type of access control policies. Depending on the type of RBAC deployment these policies can include the enforcement of least privilege (the time-honored administrative practice of assigning privileges to users’ that are minimally necessary for the performance of duty), and separation-of-duty policies (thus avoiding situations that can lead to a conflict of interest). RBAC can also increase user productivity by allowing users greater access to more resources and the ability to better delegate administrative responsibility to customers and partners where possible.

1.4.2 Authorization management and resource provisioning

At the lowest level, administrators control user access rights through the creation and maintenance of ACLs on a system-by-system basis. ACLs specify, for each protected resource, a list of individual users, or groups composed of individual users, with their respective modes of access (e.g., read or write) to the resource. This use of ACLs has proved problematic for a variety of reasons. ACLs are tied to particular resources. ACLs further complicate matters because they are managed on a system-by-system basis. A large number of users, each with many privileges, imply a very large number of user-privilege associations that are spread over potentially large numbers of independently managed platforms and applications. Thus, when a user takes on different responsibilities within the enterprise, administering these changes entails a thorough review, resulting in the selective addition or deletion of the user’s privileges, typically within numerous systems.

Authorization management and resource provisioning tools, which typically incorporate RBAC, have been developed to assist administrators in dealing with these challenges.

Security administrators who manage users, resources, and privileges on more than one platform must perform many similar tasks on different systems. Because each system has its own proprietary administrative interface, even routine tasks require security administrators to have detailed knowledge of each type of security system. They spend valuable time logging on and off different security systems while performing each task locally.

As organizations grow, users typically require access to more and more systems, including one or more applications that the user interacts with on a daily basis, an e-mail server, systems used for occasional transactions such as entering travel reimbursements or managing retirement accounts, and possibly print servers, Web sites, and a host of other systems that require authorization. All of these systems require some form of authentication and access control, and they may be changed and updated independently of one another, making it difficult for users to keep their passwords consistent across all systems. Some organizations may explicitly require that users not use the same passwords for different systems, particularly if the systems vary in sensitivity. Managing authentication and access control across multiple systems is the key problem in authorization management.

Maintaining user IDs, role memberships, permissions, and the associations between roles and permissions are all tasks included in authorization management. In most cases, system administrators must deal with these problems on a daily basis, as organizations gain and lose employees, and jobs and permissions change within the organization. Managing permissions for a large number of applications is thus not only a problem for users; it represents an enormous challenge for enterprise system administrators.

Although there are many authorization management solutions to this challenge, they all provide a means of centralizing authorization information on a server. Broadly speaking, there are two common ways of dealing with the problem of centralizing authorization, as shown in Figures 1.7 and Figures 1.8.

Figure 1.7: User-pull authorization architecture.

Figure 1.8: Server-pull authorization architecture.

In the first approach, which has been termed user pull [29], the user is authenticated by the authorization server, obtains some sort of credential to access applications, and then presents the credentials as authorization to the applications. The second approach, termed server pull [29], requires applications to authenticate users, but centralizes information about user privileges on an authorization server. When a user attempts to invoke an application, the application queries the authorization server to determine the user’s permissions.

Before users can begin accessing the applications they need to do their jobs, the organization must set up access permissions for them throughout the network. This is the problem of resource provisioning. In addition to thousands of employees, the company may need to establish permissions for contractors, business partners, and customers who access corporate data on the Internet. Equally important is the task of decommissioning permissions held by employees leaving the company. Surveys of corporations have found that current and prior employees are the top two sources of security breaches. Past employees are cited as a security problem nearly as often as current employees, because of the problem of deleting permissions after employees leave [30]. Creating and maintaining proper access permissions in a fast-changing business environment is a complex problem, which has led to the development of sophisticated tools typically costing from $600,000 to $800,000 [31]. Resource provisioning typically requires cooperation among computer systems from the corporate human resources, information systems, and a broad collection of other corporate departments depending on the user’s job. If "Bob Smith" is hired, he must be given permissions for all the resources needed in his job. With conventional access control systems, this would mean assigning his user ID to every resource he will access. The direct linking of user with permission is not only timeconsuming; it invariably leads to errors as user assignments change, resulting in users having permissions they should not have.

RBAC does not permit users to be directly associated with permissions. With RBAC, permissions are authorized for roles, and roles are authorized for users. The permissions that are authorized for a role may span multiple platforms and applications. Thus, when administering RBAC two different types of associations must be managed (i.e., associations between users and roles and associations between roles and permissions). When a user’s job position changes, only the user-role associations change. If the job position is represented by a single role, then when a user’s job position changes, there are only two user-role associations to change: To implement these changes, it is necessary to remove the association between the user and the user’s current role and to add an association between the user and the user’s new role. Complexities introduced by organizational hierarchies and constraints such as separation-of-duty requirements are hidden by the access control software. This conceptually simple approach is what gives RBAC its power and flexibility.

References

DoD, Trusted Computer System Evaluation Criteria (TCSEC), DoD 5200.28-STD.
Lampson, B. W., "Dynamic Protection Structures," AFIPS Conference Proceedings, 35, 1969, pp. 27–38.
Ware, W. H., Security Controls for Computer Systems (U): Report of Defense Science Board Task Force on Computer Security, Santa Monica, CA: The RAND Corporation, February 1970.
Anderson, J. P., Computer Security Technology Planning Study Volume II,ESD-TR-73-51, Electronic Systems Division, Air Force Systems Command, Hanscom Field, Bedford, MA, 01730, October 1972.
Bell, D. E., and L. J. LaPadula, Secure Computer Systems: Mathematical Foundations and Model, Bedford, MA: The Mitre Corporation, 1973. See also D. E. Bell and L. J. LaPadula, Secure Computer System: Unified Exposition and MULTICS Interpretation, MTR-2997 Rev. 1, Bedford, MA: The MITRE Corporation, March 1976, and ESD-TR-75-306, rev. 1, Electronic Systems Division, Air Force Systems Command, Hanscom Field, Bedford, MA 01731.
Harrison, M., W. Ruzzo, and J. Ullman, Protection in Operating Systems, CACM 19, No. 8, August 1976, pp. 461–471.
Clark, D. D., and D. R. Wilson, "A Comparison of Commercial and Military Computer Security Policies," IEEE Symposium of Security and Privacy, 1987, pp. 184–194.
Dobson, J. E., and J. A. McDermid, "Security Models and Enterprise Models," in Database Security II: Status & Prospects, C. E. Landwehr (ed.), North Holland, 1989, pp. 1–39.
Baldwin, R. W., "Naming and Grouping Privileges To Simplify Security Management in Large Database," in Proceedings IEEE Computer Society Symposium on Research in Security and Privacy, April 1990, pp. 184–194.
Thomsen, D. J., "Role-Based Application Design and Enforcement," in Database Security, IV: Status and Prospects, S. Jajodia and C. E. Landwehr (eds.), North Holland, 1991, pp. 151–168.
Brewer, D. F. C., and M. J. Nash, "The Chinese Wall Security Policy," Proceedings IEEE Computer Society Symposium on Research in Security and Privacy,April 1989, pp. 215–228.
Nash, M., and K. Poland, "Some Conundrums Concerning Separation of Duty," presented at the IEEE Symposium on Security and Privacy, Oakland, CA, 1990.
Ferraiolo, D., D. Gilbert, and N. Lynch, "An Examination of Federal and Commercial Access Control Policy Needs," in Proceedings of the NIST-NSA National (USA) Computer Security Conference, 1993, pp. 107–116.
Ferraiolo, D., and D. R. Kuhn, "Role-Based Access Control," in Proceedings of the NIST-NSA National (USA) Computer Security Conference, 1992, pp. 554–563.
Ferraiolo, D. F., J. Cugini, and D. R. Kuhn, "Role-Based Access Control (RBAC): Features and Motivations," in Proceedings of the 11th Annual Computer Security Application Conference, New Orleans, LA, December 11–15 1995, pp. 241–248.
Sandhu, R. S., et al., "Role-Based Access Control: A Multidimensional View," Proceedings of the 10th Annual Computer Security Applications Conference, December 1994, pp. 54–62.
Nyanchama, M., and S. L. Osborn, "Access Rights Administration in Role-Based Security Systems," Proceedings of the IFIP WG11.3 Working Conference on Database Security, 1994. See also M. Nyanchama and S. L. Osborn, "The Role Graph Model and Conflict of Interest," ACM Transactions on Information and System Security (TISSEC), Vol. 2, No. 1, February 1999, pp. 3–33.
Deinhart, K., et al., "Method and System for Advanced Role-Based Access Control in Distributed and Centralized Computer Systems," U.S. Patent 5,911,143, June 8, 1999.
Sandhu, R., et. al., "Role-Based Access Control Models," IEEE COmputer, Vol. 29, No. 2, February 1996.
Barkley, J. F., "Application Engineering in Health Care," Second Annual CHIN Summit, June 9, 1995.
Barkley, J. F., and A. V. Cincotta. "Implementation of Role/Group Permission Association Using Object Access Type," U.S. Patent 6,202,066, 2002.
Bertino, E., E. Ferrari, and V. Atluri, "A Flexible Model for the Specification and Enforcement of Authorizations in Workflow Management Systems," 2nd ACM Workshop on Role-Based Access Control, November 1997.
Sandhu, R., D. Ferraiolo, and R. Kuhn, "The NIST Model for Role-Based Access Control: Towards a Unified Standard," Proc. 5th ACM Workshop on Role-Based Access Control, July 26–27, 2000.
U.S. Health Insurance Portability and Accountability Act of 1996 (HIPAA) at http://cms.hhs.gov/hipaa.
Federal Aviation Administration, National Airspace System (NAS) Protection Profile Template Supplement, Version 1.0. http://www.faa.gov/aio/common/documents/NAS_PP_Supp_v1.pdf.
Joshi, J., et al., "Digital Government Security Infrastructure Design Challenges," IEEE Computer, 33(2), February 2001, pp. 66–72.
Joshi, J. B. D., et al., "Security Models for Web-Based Applications," Communications of the ACM, 44(2), February 2001, pp. 38–44.
Ferraiolo, D. F., J. F. Barkley, and D. R. Kuhn, "A Role-Based Access Control Model and Reference Implementation Within a Corporate Intranet," ACM Transactions on Information and System Security (TISSEC), Vol. 2, No. 1, February 1999, pp. 34–64.
Park, J. S., and R. Sandhu, "RBAC on the Web by Smart Certificates," Proc. ACM Workshop on Role-Based Access Control 1999: 1–9, New York: ACM Press.
Daniels, J., "This is Not a Game: The Weakest Link," SANS Institute, August 9, 2001.
Messmer, E., "Role-Based Access Control on a Roll," Network World, July 30, 2001 at http://www.nwfusion.com/news/2001/0727burton.html.

归类于：技术之路 — vickymade @ 3:06 pm 评论(0)

Artech House – Role-Based Access Control 001 Preface And Acknowledgments

Preface

Role-based access control (RBAC) is a technology that is attracting a great deal of attention, particularly for commercial applications, because of its potential for reducing the complexity and cost of security administration in large networked applications. Under RBAC, security administration is greatly simplified by using roles, hierarchies, and constraints to organize privileges. RBAC reduces costs within an organization, because it takes into account that employees change much more frequently than the duties within positions. Under RBAC, if, for example, an employee moves within an organization, only his or her role assignment is changed. Accordingly, it is unnecessary to revoke his or her existing privileges and assign a completely new set of privileges. RBAC can be configured to support a wide variety of access control policies, including traditional discretionary access control (DAC) and mandatory access control (MAC), as well as organization-specific policies. Recently, RBAC has also been found to be a natural access control facility for workflow management systems. The concept and design of RBAC make it perfectly suited to a wide variety of application and system software environments, for both stand-alone and distributed deployments. It provides a safe and effective way to manage access to an organization’s information, while reducing administration costs and minimizing errors.

Over the past decade, interest in RBAC has increased dramatically, with most major information technology (IT) vendors offering a product that incorporates some form of role-based access. The profusion of new RBAC products offers many advantages for security administrators and software developers, but sorting out the capabilities of different products can be challenging. Until now, RBAC research has been documented in hundreds of research papers, but not consolidated in book form. This book explains RBAC and its administrative and cost advantages and implementation issues and the migration from conventional access control methods to RBAC. Specialized topics—including role hierarchies, separation of duties, combining RBAC with military security models, and recent efforts toward standardization—are detailed. To enable system integrators to integrate RBAC into the various IT infrastructures found in an enterprise-like Web applications, such as Java and Federated Database Systems, the book provides an analysis of research ideas and prototypes built so far. The book also describes RBAC implementations in various commercial products and includes a case study documenting a large organization’s migration to a role-based security architecture.

Intended audience

This book is designed to be useful to three groups of readers: (1) security professionals, technology managers, and users in industry, government, and military organizations, including system administrators responsible for security, policy officials, and technology officers; (2) software developers for database systems, enterprise management, security, and cryptographic products; and (3) computer science and IT students and instructors. The treatment is not excessively formal; mathematical descriptions of RBAC properties are included as sidebars, but the text is understandable without reference to them. Because computer security is such a rapidly changing field, we have included a discussion of research and commercial product documentation through this year.

Acknowledgments

First of all, we want to thank Tim Grance of the National Institute of Standards and Technology (NIST). Much of NIST’s contribution to RBAC research can be traced to Tim’s early persistent and continuing support, leadership, and counsel. We would also like to thank Andrew Marshall of TD Bank in Canada for his detailed review of material in Chapters 3 and 4 and his great insight regarding the application of role hierarchies to commercial business structures, and Leann Michaels for advice and counsel regarding medical applications, functions, and roles that were applied throughout this book. The authors also thank Dr. Martin Kuhlmann and Axel Kern of Systor Security Solutions, Mr.Wiley Vasquez and Gary Holland of BMC Software, and Harald Kopper of Siemens AG for providing technical documentations pertaining to "Enterprise Security Administration" product offerings from their respective organizations. We are grateful to Michael Gallaher, Alan O’Connor, and Brian Kropp of the Research Triangle Institute and Greg Tassey of NIST for their excellent analysis of the economic impact of RBAC.

Finally, we also thank the many contributors to the RBAC field from the public, academic, and private sectors, such as Gail-Joon Ahn, Vijay Atluri, Elena Ferrari, Arif Ghafoor, James Joshi, Trent Jaeger, Serban Gavrila, Virgil Gligor, Bill Majurski, Tony Cincotta, Wayne Jansen, Janet Cugini, Elisa Bertino, and Konstantin Beznosov.

归类于：技术之路 — vickymade @ 3:01 pm 评论(0)

2006年01月06日

tree2小试

tree2是Myfaces的tomahawk控件中的一个，在使用tomahawk控件之前一定先确定已经按照myfaces的要求配置好web.xml文件。
Myfaces网站tomahawk栏目的Extensions Filter 子栏目中有如下一段话：
If you just use standard JSF component, but don’t use any MyFaces’ extended component (beginning with t:),
then you don’t need the Extensions Filter.
However, if you use some of the MyFaces’ extended components like t:inputFileUpload, t:inputHTtml, t:inputCalendar, …
then you most likely need to have this filter configured in your webapp.
大概意思是，如果你在项目中没有使用到Myfaces的扩展组件（t:开头的），则你不需要配置这个Filter.
可是，如果你用了Myfaces的扩展组件，你必须为你的web程序配置这个Filter.
配置如下：

<filter-name>MyFacesExtensionsFilter</filter-name>

<filter-class>org.apache.myfaces.component.html.util.ExtensionsFilter</filter-class>

<init-param>

<param-name>maxFileSize</param-name>

<param-value>20m</param-value>

<description>Set the size limit for uploaded files.

Format: 10 - 10 bytes

10k - 10 KB

10m - 10 MB

1g - 1 GB

</description>

</init-param>

</filter>

<!– extension mapping for adding <script/>, <link/>, and other resource tags to JSF-pages –>

<filter-mapping>

<filter-name>MyFacesExtensionsFilter</filter-name>

<!– servlet-name must match the name of your javax.faces.webapp.FacesServlet entry –>

<servlet-name>Faces Servlet</servlet-name>

</filter-mapping>

<!– extension mapping for serving page-independent resources (javascript, stylesheets, images, etc.) –>

<filter-mapping>

<filter-name>MyFacesExtensionsFilter</filter-name>

<url-pattern>/faces/myFacesExtensionResource/*</ url-pattern>

</filter-mapping>

要使用MyFaces的tomahawk控件，要在页面引用<%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%>。
在页面中添加tree2的标签：

<t:tree2 id="sortTree" var="node" varNodeToggler="t" showRootNode="false" value="#{tree.treeData}">

</t:tree2>

建立托管Bean,用于填充tree。

public class TreeBacker implements Serializable

{

public TreeNode getTreeData ( )

{

TreeNode treeData = new TreeNodeBase ( "foo-folder" , "Inbox" , false ) ;

TreeNodeBase personNode = new TreeNodeBase("person", "Eddie L", false);

//personNode.getChildren().add(new TreeNodeBase("document","Eddie doc one", true));

TreeNodeBase doc = new TreeNodeBase("document","Eddie doc one", true);

doc.setIdentifier("No.1");

personNode.getChildren().add(doc);

treeData.getChildren().add(personNode);

System.out.println ( "Create Tree

..ok" ) ;

return treeData ;

}

其中TreeNodeBase personNode = new TreeNodeBase("person", "Eddie L", false);中的"person"的作用是表示渲染得时候显示什么样式，
跟页面中<f:facet name="person"></f:facet>相对应。
在页面中

<f:facet name="person">

<h:panelGroup>

<f:facet name="expand">

<t:graphicImage value="../images/person.png" rendered="#{t.nodeExpanded}" border="0" />

</f:facet>

<f:facet name="collapse">

<t:graphicImage value="../images/person.png" rendered="#{!t.nodeExpanded}" border="0" />

</f:facet>

<h:outputText value="#{node.description}" styleClass="nodeFolder" />

</h:panelGroup>

</f:facet>

<t:graphicImage value="../images/person.png" rendered="#{t.nodeExpanded}" border="0" />显示Tree每一个节点的图片。rendered属性的意思是是否渲染的意思，
jsf中渲染的意思是把jsf组件树当前的状态转换成html。在jsf的生命周期里，渲染响应在最后一个周期，rendered值为false在渲染相应这个周期就不运行。
在处理叶子节点上，需要特殊的注意。因为对叶子节点是需要操作的。可能需要点击叶子节点连接到一个页面，或者执行某些action等。

<f:facet name="document">

<h:panelGroup>

<h:commandLink immediate="true" styleClass="#{t.nodeSelected ? ’documentSelected’:'document’}" actionListener="#{t.setNodeSelected}" action="#{tree.okListener}" id="clickbutton">

<t:graphicImage value="../images/document.png" border="0" />

<h:outputText value="#{node.description}" />

<f:param name="docNum" value="#{node.identifier}" />

</h:commandLink>

</h:panelGroup>

</f:facet>

commandLink标记可以有n个参数，参数分为参数名和参数值。在程序里可以读取。
编写action事件：okListener

FacesContext context = FacesContext.getCurrentInstance ( ) ;//取得上下文

String a = context.getExternalContext ( ).getRequestParameterMap ( )

.get ( "docNum" ).toString ( ) ;

a的值就是docNum的值。
identifier的值在创建树的时候一起加进去的：
TreeNodeBase doc = new TreeNodeBase("document","Eddie doc one", true);
doc.setIdentifier("No.1");

这样。一个tree2的应用基本就算ok了。

归类于：公司 — vickymade @ 11:37 am 评论(1)

FacesContext保存组件树

FacesContext保存了组件书的一个引用，由它为请求进行渲染；
贯穿整个请求处理生命周期，你可以通过FacesContext访问组件树；
而且贯穿整个生命周期，你可以更改或替换他的当前组件树。

归类于：公司 — vickymade @ 11:37 am 评论(0)

JSF commandButton的immediate属性

把这个属性设置成True,他就会直接执行Action的方法，不执行一些get方法，不会读取一些必要的信息。

归类于：公司 — vickymade @ 11:36 am 评论(1)

JSF SelectItems 使用

jsf提供了<h:selectOneMenu>标签，来定义单选下拉框，直接写在jsp的文件里的做法，很简单，不写了。

在托管Bean里初始化这个标签的时候，可以使用SelectItem[] 数组类型，也可以使用List 、Map等类型。

具体做法如下：

private List<SelectItem> okItems = null;

/**

* @return Returns the okItems.

public List < SelectItem > getOkItems ( )

{

this.okItems = new LinkedList< SelectItem >();

this.okItems.add(new SelectItem("a","aaa"));

this.okItems.add(new SelectItem("b","bbb"));

return okItems ;

}

然后在jsp页面中：

<h:selectOneMenu id="sortpid" value="#{booksort.sortPid}">

<f:selectItems value="#{booksort.okItems}" />

</h:selectOneMenu>

selectItems他拥有一个value这个属性，赋值为托管Bean里的初始化下拉框的那个属性，也就是okItems。

归类于：公司 — vickymade @ 11:36 am 评论(1)

MyEclipse运行MyFaces出现空白页面的问题，我的解决方法。

      用MyEclipse创建一个Web Project的项目，然后让这个项目支持MyFaces。运行，结果不报错而且只显示出一个空白的页面，右键查看网页的源代码，里面只显示出了网页的一些基本html代码，没有出现任何有关jsf的一些内容。然而，我只让他支持JSF，却一切正常，什么东西都显示出来了。

      发现这个问题以后，去csdn和QQ的群里面问了很多人，都没有出现过这些问题。我都开始纳闷了。。。。。

      然后我做了一个实验，我把MyFaces官方的blank代码直接复制到tomcat的webapp目录却正常显示了。我把这个blank的代码全部复制到MyEclipse的项目里，然后同步服务器，同样的问题就又出现了，还是出现了一个大白页面。。这个问题整整让我郁闷了好几天，到底是我配置的问题呢，还是MyEclipse插件的问题呢？因为我把这个blank的代码直接放到webapp目录里，却一切正常，我想这说明我的配置应该是没有错误的。那问题就出在MyEclipse上了。

      然后我在Eclipse的选项里面查看MyEclipse的选项，找到了Project Capabilities里有对jsf项目的一些jar的设置，在这个选项里面我发现在下方有一个copy jsf jar and package Tlds to /WEB-INF/lib, if not present 的复选框，把这个勾打掉，然后再用MyEclipse建立web Project项目，然后支持MyFaces,自己手工的把blank的所有jar都复制到/WEB-INF/lib里，同步服务器。哇靠了！亲爱的MyFaces组件都出来了！

      到目前为止，我还没有弄明白，为什么用MyEclipse带的所有jar就会出现这些问题，我也仔细察看了，新建的MyFaces项目里的classpath都没有jsf-api.jar，最后还使用了最土的办法，自己手工copy那些jar。

哪位大兄弟也遇到过这样的问题，还有更好的解决方法，一定要告诉我啊。还有就是，错误的根在哪里呢？我还没弄明白。我觉得MyEclipse他自带的那些jar按道理来说不应该有问题的。可能原因还在其它的地方。

归类于：公司 — vickymade @ 11:35 am 评论(0)

Pages (29): « 1 2 3 4 5 6 » ... Last »

表达式和托管Bean集成方法1

表达式和托管Bean集成方法2

Spring作为简单可变Context

Overview

3.1 Roles versus ACL groups

3.2 Core RBAC

3.2.1 Administrative support

3.2.2 Permissions

3.2.3 Role activation

3.3 Mapping the enterprise view to the system view

3.3.1 Global users and roles and indirect role privileges

3.3.2 Mapping permissions into privileges

Chapter 2: Access Control Policy, Models, and Mechanisms—Concepts and Examples

2.1 Policy, models, and mechanisms

2.2 Subjects and objects

2.3 Reference monitor and security kernel

2.3.1 Completeness

2.3.2 Isolation

2.3.3 Verifiability

2.3.4 The reference monitor—necessary, but not sufficient

2.4 DAC policies

2.5 Access control matrix

2.5.1 ACLs and capability lists

2.5.2 Protection bits

2.6 MAC policies and models

2.7 Biba's integrity model

2.8 Clark-Wilson model

2.9 The Chinese wall policy

2.10 The Brewer-Nash model

2.11 Domain-type enforcement model

References

Overview

1.1 The purpose and fundamentals of access control

1.1.1 Authorization versus authentication

1.1.2 Users, subjects, objects, operations, and permissions

1.1.3 Least privilege

1.2 A brief history of access control

1.2.1 Access control in the mainframe era

1.2.2 Department of Defense standards

1.2.3 Clark-Wilson model

1.2.4 Origins of RBAC

1.3 Comparing RBAC to DAC and MAC

1.4 RBAC and the enterprise

1.4.1 Economics of RBAC

1.4.2 Authorization management and resource provisioning

References

Preface

Intended audience

Acknowledgments

news

导航

分类

Java链接

Windows底层开发

书籍下载站

休闲

开源项目

朋友

经营管理

网络

跬步千里

软件工程

最新日志

存档

最新评论