Secure Information Sharing Using Attribute Certificates and Role Based Access Control^{∗}

Ganesh Godavari, Edward Chow

Department of Computer Science, University of Colorado, 1420 Austin Bluffs Parkway Colorado Springs, Colorado 80917 USA gkgodava@cs.uccs.edu, chow@cs.uccs.edu

Abstract

World Wide Web (WWW) has become a part of the way in which we transfer information. Security and authorization have become a concern for sharing of critical information. Role based access control (RBAC) provides some flexibility to security management. Public key infrastructure (PKI) can provide a strong authentication. Privilege management infrastructure (PMI) as a new technology can provide strong authorization. In order to satisfy mentioned security requirements, we have established a role based access control infrastructure and developed a prototype that uses X.509 public key certificates (PKCs) and attribute certificates (ACs). Access control is performed by access control policies that are written in XML. Policies and roles are stored in ACs. ACs are stored in LDAP servers. The access control engine provides a service that mediates the data between the users and the resources, which is also responsible for authentication and authorization. The administration tool can create key pairs, PKCs and ACs, manage users information, and so on. The scheme proposed has many advantages that satisfy the needs of intra-company information sharing using attribute certification, ”‘and eliminates some of the problems associated with the revocation procedures.”’

1 Introduction

As the WWW is fast becoming a place for sharing of information, piracy, and misuse of information are fast becoming a threat. Security and Authorization are becoming necessary. This situation not only provides excellent business opportunities but also research challenges. One of the most challenging problems is managing large networked systems is the complexity of security administration, particularly access control.

Role Based Access Control simplifies access control administration and provides better manageability in enterprise environments by allowing permissions to be managed in terms of user job roles [references]. RBAC maps user job roles to application permissions so that access control administration can be accomplished in terms of users job role. This means that administrators will have to set up roles, such as employee, manager and administrator, but once roles are created, administrators will manage membership in the roles; not permissions on objects, applications, and resources.

Many of the e-commerce applications require authentication services, in addition to the basic services provided by Public Key Infrastructures (PKI), to allow users to do what they are allowed to do. Attribute certificates have been proposed as a solution for the authorization services. Privilege Management Infrastructures (PMI) provide the necessary support for a wide use of those certificates. The main function of PMI is providing strong authorization after the authentication has taken place. Although both types of infrastructures, PKIs and PMIs, keep some kind of relation, they can operate autonomously.

Some research and development efforts have been done in this area [1, 2, 3, 4], but these efforts are still in primary phase, and no authorization mechanism is widely accepted. We were motivated by the need of using PKI, PMI and RBAC concepts to construct an authorization mechanism which uses the PERMIS model of storing the user’s roles in ACs. Access control decisions are driven by an authorization policy, and the authorization policy is also stored in an AC.

∗Draft Report 0.1

The organization of this paper is as follows. Section 2 provides an overview of the related research. Section 3 describes the architecture of the software system implemented. In Section 4 we analyze the results. Finally, in Section 5, we discuss future directions for research.

2 Related Research

2.1 Role Based Access Control

Role-based access control [6], [7], [8], [9], [10] has gained attention as a proven alternative to traditional discretionary (DAC) and mandatory access control (MAC) mechanisms. RBAC helps to specify organization’s security policies reflecting its organizational structure. In the core RBAC, a user can be assigned one or more roles, and a role can be assigned to one or more users. roles are based on the user’s job responsibilities in the organization. This provides for flexibility and finer granularity during assignment of access permissions to roles and users to roles. In rolebased model the role hierarchy partially determines which roles and permissions are available to users via various inheritance . for example A senior role can inherit permissions from junior roles. A user establishes a session during which he activates some subset of roles that he is a member of. RBAC provides Static Seperation of Duty (SSD) relations to prevent conflict of interests that arise when a user gains permissions associated with conflicting roles, and Dynamic Seperation of Duty relations to place constraints on roles that can be activated in a users session.

Figure 1: RBAC model The RBAC in Figure 1 consists of 1) a set of users (USERS) where a user is an intelligent autonomous agent, 2) a set of roles (ROLES) where a role is a job function, 3) a set of objects (OBS) where an object is an entity that contains or receives information, 4) a set of operations (OPS) where an operation is an executable image of a program, and 5) a set of permissions (PRMS) where a permission is an approval to perform an operation on objects. The cardinalities of the relationships are indicated by the absence (denoting one) or presence of arrows (denoting many) on the corresponding associations. For example, the association of user to session is one-to-many. All other associations shown in the figure are many-to-many. The association labeled Role Hierarchy defines the inheritance relationship among roles.

For more information about RBAC is available at [12].

2.2 Privilege Management Infrastructure

PMI is the information security infrastructure that assigns privilege attribute information such as privilege, capability, and role, etc., to users and issues and manages it using the X.509 Attribute Certificate. The PMI supports access control service using the user’s privilege management in application services. The function of the PMI is to specify the policy for the attribute certificate issuance and management. Then, the PMI carries out the AC-related management functions such as issuing, updating, and revoking an attribute certificate based on a specified policy.

In PMI the ACs issuer is called Attribute Authority (AA). ACs are digitally signed by the AA, so they are tamper-resistant. The trusted root is called source of authority (SOA). When a user’s authorization permissions need to be revoked, AA will issue an attribute certificate revocation list (ACRL) containing the list of ACs no long to be trusted. There are two primary models for distribution of attribute certificates: the ‘push’ or ‘pull’ model. The ‘push’ model is suitable when the client’s rights should be assigned within the client’s ‘home’ domain, whereas the ‘pull’ model is suitable when the client’s rights should be assigned within the server’s domain.

There are two types of Attribute Certificates: (1) ‘User Role specification’ attribute certificate which tells what privilege(s) a user has. It is used by the decision making service to make a decision to determine whether a user has access information or resources available in application services. (2) ‘Delegated Role Specification’ attribute certificate which tells what privilages are given for a resource(s) by a user of higher authority.