access control with role attribute certificates

Ž .Computer Standards & Interfaces 22 2000 43–53www.elsevier.comrlocatercsi

Access control with role attribute certificates

Jing-Jang Hwang, Kou-Chen Wu, Duen-Ren Liu )

Institute of Information Management, National Chiao-Tung UniÕersity, 1001 Ta Hsueh Road, Hsinchu, 300 Taiwan

Accepted 18 November 1999

Abstract

The goal of access control is to counter the threat of unauthorized operations involving computer or communicationŽ .systems. Role-based access control RBAC is a new paradigm for access control, different from the traditional schemes

such as the capability scheme or the access control list scheme. To realize the RBAC scheme, we define role attributecertificates following a generic specification in X.509. Our certificate is a vehicle for carrying role-assignment informationabout a certificate subject. The certificate is certified, issued, and revoked by a central administrator, called the Role

Ž .Attribute Certification Authority RACA ; as a result, the access control information conveyed in the certificate is centrallymanaged. The certificate is sent to application sites where the information is required for access control decisions;consequently, a scheme using this special type of attribute certificate gains the advantage of reducing communication. Thedrawback with this approach is that role attribute certificates must be accompanied by a public-key certificate, whose

Ž .functioning depends on the existence of a public-key infrastructure PKI . q 2000 Elsevier Science B.V. All rights reserved.

Keywords: Public-key certificate; Attribute certificate; X.509 standard recommendation; Role-based access control

1. Introduction

Telecommunication Standardization Sector of theŽ .International Telecommunication Union ITU-T rec-

ommends the X.509 standard as a framework forentity authentication in open systems. The documentthat includes this recommendation is entitled ‘‘OpenSystems Interconnection — The Directory: Authen-

w xtication Framework’’ 6 . In this document, an infor-mation structure for public-key certificates and pro-cedures for using these certificates are defined. Waysto manage certificates, such as through generation orrevocation, are also given.

) Corresponding author. Fax: q886-3-5723-792.Ž .E-mail address: [email protected] D.-R. Liu .

A certificate as defined by this standard is anelectronic document that describes the owner of akey pair, a public and a private key, and that bindsthe keys to the owner, who is the certificate subject.Such a certificate is called a public-key certificatebecause it conveys a subject’s public-key informa-

Ž .tion along with his the subject’s identity informa-Žtion. Separately and in a secure way, the subject i.e.,

.owner holds the corresponding private key. If theŽprivate key is used to encrypt a message i.e., to sign

.a message , then only the matching public-key willŽwork to decrypt the message i.e., to verify the

.signature . Public-key certificates are conventionallyavailable on public directories, which are accessibleover the Internet. Individuals or entities can authenti-cate the communicating certificate subject by verify-

Ž .ing his the subject’s digital signature on a message.

0920-5489r00r$ - see front matter q 2000 Elsevier Science B.V. All rights reserved.Ž .PII: S0920-5489 99 00029-X

( )J.-J. Hwang et al.rComputer Standards & Interfaces 22 2000 43–5344

In the same document, the standardization agencydefines attribute certificates. The major differencebetween the two types of certificate — the attributecertificate and the public-key certificate — is thatthe former carries attribute information about a sub-

Ž .ject an individual or an entity while the latter bindsa subject’s public-key together with his identity.While the public-key information enables other indi-viduals or entities to authenticate the communicatingcertificate subject, the attribute information can beuseful for purposes other than authentication. At-tribute certificates are, however, often presented witha public-key certificate because successful entity au-thentication is the first step in establishing a commu-nication session.

In this paper, we define a particular type ofattribute certificate — the role attribute certificate,which carries information about roles assigned to thecertificate subject in accordance with his responsibil-ities and capabilities. The usefulness of this type ofcertificate is obvious because the roles that a mem-ber plays in an organization restrict him to certainprivileges in terms of access to information re-sources. Their usefulness is more apparent in thefield of electronic commerce because effective au-thorization control relies on information carried byrole attribute certificates. For example, role attributecertificates can enable a system to make sure thatelectronic purchase orders are properly authorized.

Sandhu et al. have developed a theory of accesswcontrol based upon the concept of roles 1,4,11,

x12,15 . The theory shifts the study of access controlto a new paradigm. In traditional methods, policieson access control are formulated around users and

Ž .objects. With the role-based access control RBACapproach, users do not have discretionary access toobjects; instead, access permissions are administra-tively associated with roles, and users are assigned toappropriate roles. This idea extends the scope ofaccess control from internal-level system security toapplication-level authorization management.

In this paper, we introduce role attribute certifi-cates as an instrument for realizing Sandhu’s RBACscheme. A role attribute certificate provides recipi-ents with assurance that the subject really holdsspecific roles. It also connects access control infor-mation with the subject’s public-key certificate, andthis connection allows system designers to stream-

line access control with authentication. We define aninformation structure for role attribute certificatesbased on the specification for generic attribute cer-tificates defined in X.509, and describe their usagefor access control in RBAC environments. Detailedformat of the information structure is described inSection 5. Since procedures for generating attributecertificates in general are not given in that standardww x x6 : p. 49 , we also define an organizational structureand procedures for the management of role attribute

Ž .certificates in enterprises see Section 6 . The sug-gested procedures are based on the architecture formanaging X.509 public-key certificates.

The work presented in Sections 5 and 6 supple-ments the standard defined for generic attribute cer-tificates in X.509. As indicated in the NISTs Federal

Ž .Public-key Infrastructure FPKI technical specifica-ww x xtions 3 : pp. 12, 32 , the use of attribute certificates

needs further study. Thus, our result extends thestate-of-the-art standardization work. However, wenote that the suggested supplements to the genericattribute certificate in X.509 are mainly explored foraccess control. The usage of other types of attribute

w xcertificate needs further study 5,9,13,17 . Moreover,the standardization recommendation of our approachneeds to be proposed and discussed by proper agen-cies.

2. Public-key certificates and attribute certificates

The three terms, public-key certificate, user cer-tificate, and certificate, are defined as synonyms bythe X.509 standard. In this paper, a certificate refersto a public-key certificate or to an attribute certifi-cate. When we use the term certificate, its meaningwill be clear from the context.

A public-key certificate provides any recipient ofŽa digital signature with a copy of the sender’s i.e.,

.the signatory’s public key, plus assurance that theŽpublic-key — and the private key held by the

.sender — really belong to the sender. This assur-ance is delivered in the form of the Certification

Ž .Authority’s CA’s signature on the certificate. TheCA’s signature guarantees for users the integrity aswell as the authenticity of the certificate. As a result,certificates can be placed in open directories, without

( )J.-J. Hwang et al.rComputer Standards & Interfaces 22 2000 43–53 45

the need for the latter to make special efforts toprotect them.

By definition, each public-key certificate con-tains, as a minimum, the subject’s distinguishedname, a copy of his public-key, and the name of theCA that issued it. The certificate is digitally signedŽ .i.e., certified by the CA. Normally, more informa-tion is coded into public-key certificates. Includedare an expiry date, the serial number of the certifi-cate, the version of the certificate, the signaturealgorithm identifier, and the optional unique identi-fier of the certificate subject. Extensions for variouspurposes can also be coded, including indicators ofintended or restricted key usage, indicators of certifi-cate policies, and subject and issuer attributes. Table1 shows the ASN.1 data type used to representpublic-key certificates.

The fields of the extensions in the data typeshown in Table 1, though defined as optional, areworthy of discussion. Extensions can be included torestrict the usage of a certificate. For instance, the

Ž .key usage extension field keyUsage EXTENSIONcan be used to convey information about the purposeof the certified public key, for example, use for adigital signature, for non-repudiation, key encipher-ment etc., or a combination of these purposes. Asanother example, the certificate policies extension

Ž .fields certificatePolicies EXTENSION list certifi-cate policies recognized by the issuing CertificationAuthority. Inclusion of extensions can, on the otherhand, expand application of the certificate. For ex-ample, the subject directory attributes extension fieldŽ .subjectDirectoryAttributes EXTENSION can beused to convey any attribute value for the certificate

Table 1ww x xASN.1 representation of a public-key certificate 6 : p. 11

� �Certificate::sSIGNED SEQUENCEversion Version DEFAULT v1,serialNumber CertificateSerialNumber,signature AlgorithmIdentifier,issuer Name,validity Validity,subject Name,subjectPublicKeyInfo SubjectPublicKeyInfo,issuerUniqueIdentifier UniqueIdentifier, OPTIONAL,subjectUniqueIdentifier UniqueIdentifier, OPTIONAL

4extensions Extensions OPTIONAL

subject. Information, such as a postal address, birthdate or a picture, can be useful in giving a communi-cating entity confidence that the certificate subject isindeed the intended person. These extensions provideextra information; as a result, authentication basedupon public-key certificates has become more realis-tic and workable in open systems.

Nevertheless, the use of extensions must not beextended too far. The primary purpose of the public-key certificate is entity authentication, as indicatedby the title of the X.509 standard recommendation.Though this standard has defined a variety of exten-sions, we must resist the temptation to use them toomuch. We must consider alternatives when we wantto streamline other functions together with the au-thentication purpose. In other words, we prefer touse separate structures to convey information that isnot directly related to authentication, rather thancode all kinds of information about the owner intothe certificate.

Certified attributes associated with an individualor an entity, for purposes other than authentication,may be conveyed in a separate structure, defined asan attribute certificate. A subject may have multipleattribute certificates associated with each of his pub-lic-key certificates: one for receiving privileges as aprofessional, one for conveying medical informationabout a patient, one for storing the academic recordsof a student, and so forth. Attribute certificatesconnect application-oriented information with thesubject’s public-key certificate. Because most appli-cations begin with authentication, this connectionallows system designers to streamline applicationsby using this process at the beginning.

Table 2 shows the ASN.1 data type used torepresent attribute certificates. Among the data fields,the baseCertificateID field associates an attributecertificate with a public-key certificate whose subjectbears the attributes defined by the field SEQUENCEOF Attributes, and the issuer specifies the CA whocertified the information included in this attributecertificate. We prefer that a separate CA, rather thesame CA for certifying public-key certificates, bearthe responsibility of certifying attribute information.In this way, we comply with the principle of separa-tion of duties.

Attribute information about a subject may changebefore the expiry date given in an attribute certifi-


Table 2ww x xASN.1 representation of an attribute certificate 6 : p. 49

�AttributeCertificateInfo::sSEQUENCEVersion Version DEFAULT v1,

�Subject CHOICEw xBaseCertificateID 0 IssuerSerial,w x 4SubjectName 1 GeneralNames ,

issuer GeneralNames,signature AlgorithmIdentifier,serialNumber CertificateSerialNumber,attrCertValidPeriod AttCertValidityPeriod,attriburtes SEQUENCE OF Attribute,issuerUniqueID UniqueIdentifier OPTIONAL,

4extensions Extensions OPTIONAL

cate. Using the role attribute certificate presented inthis paper as an example, an employee may beassigned new roles; subsequently, the role attributecertificate of the employee must be replaced so as toaccommodate this change. Good management ofchanges is essential for successful application of theconcept of attribute certificates.

When employees are reassigned roles, old roleattribute certificates must be revoked and new cer-tificates created. Certificate revocation is one part ofchange management. No specific information struc-tures for attribute certificate revocation is, however,defined in X.509; instead, the same structure usedfor public-key certificate revocation lists is suggestedas a solution. Based on the format of the X.509 v2public-key certificate revocation list, each revocationentry consists of the serial number of the revokedcertificate, reÕocation date, and Extension fields.The reasonCode extension can be used to specifythe reason for revocation. Table 3 shows the entrycontent of an attribute certificate revocation list.

Besides defining the information structure of roleattribute certificates, we will describe in this paperthe procedure a user can use to get his role attributecertificate from the Role Attribute Certification Au-

Ž .thority RACA . Procedures for generating attribute

ww xcertificates in general are not given in X.509 6 : p.x49 . As indicated in the FPKI technical specifications

ww xproposed by NIST in the United States 3 : pp. 12,x32 , several aspects of attribute certificates need

further study. Focusing on role attribute certificatesas a particular type of attribute certificate, we specifymanagerial procedures and practical applications thatextend the current state-of-the-art standards of digitalcertificates.

3. Role-based access control

Access control is one of the essential functions ofw xinformation security 7,14 . Its purpose is to ensure

that only authorized persons are given access tocertain information resources. Traditionally, accesscontrol has been considered as one part of the operat-ing system. Two types of policies have been imple-

Ž .mented in many systems: 1 Mandatory AccessŽ .Control MAC , which uses security labels to en-

force mandatory policies and was developed fornational defense systems in the United States, andŽ . Ž .2 Discretionary Access Control DAC , which al-lows a system to control access to objects on thebasis of an individual user’s permissions or denialsand is built into most business systems. RBAC is anew paradigm. Privileges that an individual userreceives are granted based on the role or roles thisuser plays in organizations, and security policies areformulated according to the job functions associatedwith these roles in organizations.

The term ‘‘role’’ as applied to organizations hasw xmultiple meanings 12 . A role like that of a physi-

cian or a pharmacist demands specific task compe-tency; a role like that of a project supervisor involvesauthority and responsibility. In other cases, a rolelike that of a duty physician includes duty assign-ments rotated between several members of an orga-nization.

Table 3Entry content of an attribute certificate revocation list

Ž .Serial number Serial number of the revoked certificate unique for the issuerRevocation date UTC TimeExtension reasonCode Identifies the reason for revocation of this certificate


Sandhu et al. have defined a fundamental modelfor developing the RBAC scheme — RBAC . De-0

fined in this model are sets of users, roles, permis-sions, and duty sessions. Relationships between anytwo of the sets can be explained from an organiza-

Ž .tional perspective as follows: 1 users are assignedroles and thus bear the responsibilities involved in

Ž .the assigned roles; 2 roles are granted permissionsto access information resources based upon the infor-mation required to perform the job functions in-

Ž .volved in the roles; 3 users are in duty sessionswhen they go on duty. Fig. 1 shows the basicconcept of the fundamental model of RBAC . In this0

figure, the double-arrows indicate one-to-many rela-tionships; for instance, one user may be assigned

Ž .several roles users ∏ roles , and one role musthave several users to bear various responsibilitiesŽ .users ∑ roles . In the same figure, a single-arrowmeans a one-to-one relationship; for instance, a duty

Žsession is conducted by a single user users§.sessions . From this figure, we know that the RBAC0

model allows a single user to go on duty with severalroles at the same time. Such one-to-many or many-to-many relationships as shown in Fig. 1 are com-mon in organizations.

In advanced models of RBAC, administrators canplace constraints. Various types of constraints, alsocalled security policies, have been defined in pub-

ww x xlished papers 12 : p. 44 . For example, it is possiblefor a maximum number of users to simultaneouslyactivate duty sessions for the same role; this is acardinality constraint placed on the role.

It is a common practice in organizations that auser cannot be assigned to a role unless he satisfiesprerequisite conditions, such as that he completes theduties of a particular role within a certain period oftime; this is called the prerequisite constraint. An-other type of constraint requires that a user not beallowed to play two roles with conflicting interests;this is called a mutual exclusive constraint. In addi-

w xFig. 1. A RBAC model: the basic model 12 .

w xFig. 2. A consolidated model for RBAC 12 .

tion, constraints can be placed on the time or work-ing place for activation of duty sessions. In short,constraints can apply to duty sessions, hierarchicalrelations between roles, user assignments to rolesŽ .UA relations in Fig. 2 , permission assignments to

Ž .roles PA relations in Fig. 2 , user functions associ-ated with a session, and role functions associatedwith a session. Combining the concept of constraintswith the fundamental RBAC model in Fig. 1, weillustrate a complete RBAC model in Fig. 2.

4. Using X.509 attribute certificates to conveyaccess control information

Systems for realization of the RBAC scheme mustinclude subsystems which can perform three major

Ž . Ž .functions: 1 administration, 2 duty establishment,Ž .and 3 access control enforcement.

As required by the administrative function, RBACsystems must provide tools administrators can use todefine the three sets of users, roles, and permissions,to assign users to roles, to grant permissions to roles,and to specify various constraints, as shown in Fig.2. In the RBAC scheme, constraints are formal rep-resentations of security policies, which are oftenstated in natural languages as regulations in organi-zations. As required by the duty establishment func-tion, systems must be able to establish a duty sessionwhen a user goes on duty. A duty session, also calleda communication session, begins with identity au-thentication steps and proceeds through a communi-cation period.

As required by the function of access controlenforcement, decisions must be made to accept ordeny a user’s request to the application server forperforming operations or accessing target resources.


To make the decision, the application server needs toverify the user’s privileges on the basis of the accesscontrol information, including the privilege assign-

Ž .ments the PA relations and the user assignmentsŽ .the UA relations in Fig. 2.

There are at least two approaches to allocating theinformation about privilege assignments in RBACsystems. In the first approach, the information isregarded as being application-dependent, and isplaced along with the resource, often at the applica-tion server site. In the other approach, the accesscontrol information is regarded as being required bya job function of a role and is centrally managed in apool of role privileges.

Information about user assignments is also re-quired for access control enforcement. Similarly, thisinformation can be placed locally at the sites ofapplication servers or centrally at one single sitemanaged by RBAC administrators. The local-placingapproach has the advantage that fetching this accesscontrol information can be done at the same site ofthe application server. This advantage, however,comes at the expense of a requirement that theinformation be registered and stored locally in ad-vance. On the other hand, the central-placing ap-proach offers the advantages of effective registrationand efficient storage, but at the expense of a require-ment for additional communication overhead for theapplication server to fetch this user assignment infor-mation from the RBAC administrator.

We offer a third approach using role attributecertificates to place information about user assign-ments to roles and related constraints. Fig. 3 showsan overview of a system for access control using roleattribute certificates. During the administration phase,RBAC administrators make user-role assignmentsand permission assignments. Then, the RACA, theauthority who issues certificates, accesses the user-role assignments database, prepares certificates, cer-tifies them, and issues them to users. RACA cannotexist alone; it must be part of a public-key infrastruc-

Ž .ture PKI , in which the authority of CA, the Certifi-cation Authority of public key certificates, is higher.During the duty session phase, a duty session beginswith identity authentication steps and proceedsthrough a communication period. The public-keycertificate is used for the purpose of identity authen-tication. During the access control enforcement

Fig. 3. System overview for access control using role attributecertificates.

phase, the role attribute certificate is used to providethe access control information for verifying the user’sprivileges. The role attribute certificate is bound withthe public-key certificate to streamline authorizationvalidation along with the identity authentication.

The underlying theory of our approach is con-structed on the basis of the X.509 standard and therole-based access control concept. In our approach,we use role attribute certificates as vehicles forconveying role-assignment information to realizeRBAC scheme. The proposed approach brings theadvantage of integrating both functions of identityauthentication and access control. The role attributecertificate is defined according to a generic specifica-tion in X.509, and its detailed format is presented inSection 5. Since the X.509 standard does not regu-late the generation and management procedures ofattribute certificates, we also describe the proceduresin Section 6. The issuance and revocation of roleattribute certificates are based on the architecture formanaging public-key certificates in X.509. Section 7illustrates the use of this particular type of certificateduring access control enforcement in an assumedRBAC environment.

The proposed approach has the advantage of cen-tral management because the role attribute certifi-cates are certified, issued, or revoked by a central

Ž .authority — the RACA see Section 6 . It also hasthe advantage of reducing communication overheadbecause certificates go from one application site to

Ž .other sites as the work flow requires see Section 7 .We will discuss the merits of this approach further in


Section 8. The main drawback of this approach is theneed for a PKI. The cost of a PKI will not bejustifiable unless the PKI also serves as a basis for

w xentity authentication 2,8 .

5. Defining role attribute certificates based onX.509

A role attribute certificate is a special attributecertificate, embedded in which are the subject’s roleattributes. The role attributes refer primarily to theuser-role assignments shown in Fig. 2. When an

Ž .employee i.e., a user is assigned a role, he isimplicitly authorized to assume the privileges autho-rized for the role. This is a fundamental concept ofthe RBAC scheme.

An important question relevant to RBAC is this:is it sufficient to allow assumption of a role’s privi-

ww xleges with membership information of the role? 11 :xp. 58 . The membership information indicates that a

user is assigned with the qualified role names or roleidentifiers. Some scholars have claimed that otherorganizational policies and constraints can be takeninto consideration when authorizing users to assume

ww x xa role’s privileges 4 : p. 6 . From our viewpoint,besides role names or role identifiers, additionalinformation that is related to individual users canprovide further description of the user-role assign-ments relations. This is called qualifier information.Examples of qualifier information include ‘‘the dutyshift of the certificate subject’s rotated role,’’ ‘‘thevalidity period of the certificate subject’s role mem-bership,’’ ‘‘the limitation on number of times the

certificate subject can assume the role’s privileges,’’to name a few. Qualifier information is related toindividual employees; that is to say, different em-ployees assigned the same role may have differentqualifier information. This qualifier information canbe considered as constraints on the user’s duty ses-

Ž .sion. Thus, role names or role identifiers togetherwith qualifier information are important access con-trol information; we suggest that they be coded inrole attribute certificates.

Table 4 shows the data format of the role attributecertificate, which is defined on the basis of the data

Žformat of generic attribute certificates in X.509 see.Table 2 . Among the data fields, the BaseCertifi-

cateID field associates a role attribute certificatewith a public-key certificate whose subject bears therole attributes defined by the field RoleAttributes,and the Issuer specifies the RACA, who certifiedthe information included in this role attribute certifi-cate. We prefer that a separate RACA, rather thesame CA for certifying public-key certificates, bearthe responsibility of certifying role attribute informa-tion. In this way, we comply with the principle ofseparation of duties. By embedding the serial numberof the subject’s public-key certificate, the relation-ship between the role attribute certificate and itsholder can be validated.

Table 4 also depicts the deployment of an em-ployee’s role attributes in his role attribute certifi-cate. The role attributes include role identifiers andtheir qualifier information. Role identifiers are ar-ranged in sequence in the attribute field of thecertificate; qualifier information is represented in thetuple - role identifier, qualifier type, qualifier value

Table 4The contents of role attribute certificates

RoleCertificateInfo

Ž .Subject BaseCertificateID serialNumber of X.509 publickey certificateSubjectName

Issuer GeneralNameof RACAsignature AlgorithmIdentifierserialNumber RoleCertificateSerialNumberattrCertValidityPeriod RoleCertValidityPeriodRoleAttributes SEQUENCE OF Qualified Role IdentifiersExtensions Role qualifiers Role id Qualifier type Qualifier value– – –

Role id Qualifier type Qualifier value– – –Signature on the above information


) and is coded in the extension field. For instance,-role id: SectionManagerOfProductionLine, qual-–ifier type: duty shift, qualifier value: day shift)– –indicates that the employee has been assigned therole of SectionManagerOfProductionLine, and thathis duty shift is the dayshift. As a second exam-ple, -role id: ProjectMember, qualifier type: Or-– –ganizationName, qualifier value: ABC company)–states that the certificate subject is a person from theABC company, and that he is a member of a cooper-ative project group. To make these identifiers under-standable and recognizable by applications, the roleidentifiers and qualifier information need to be de-fined before role attribute certificates are used.

6. Management of role attribute certificates

6.1. Issuance of certificates

In organizations, executives assign to employeeroles that match their qualifications and businessneeds. As it is shown in Fig. 4, assignment can bedone in functional departments or in the departmentof human resource management. For example, an

Ž .employee in the Information Technology IT depart-ment may be assigned roles by the department headand may also be assigned as a member to a projectgroup by the Human Resource Management Depart-ment. All such assignments will be stored in acentral database managed by the RACA.

RACA is the authority who issues certificates.The authority accesses the user-role assignmentsdatabase, prepares certificates, certifies them, andissues them to users.

Fig. 4. Procedure for issuing role attribute certificates.

Role attribute certificates are public declarationsof a subject’s roles. To protect information fromforgery and modification, certification by RACA isnecessary. As the X.509 standard recommends, dif-ferent authorities are in charge of certifying twotypes of certificate. RACA, however, cannot existalone; it must be part of a PKI, in which the author-ity of CA, the Certification Authority of public-keycertificates, is higher.

6.2. ReÕocation of role attribute certificates

Role assignments to users may change. For exam-ple, an assignment as a project member must cometo an end when the project is completed; an assign-ment as a department head must be terminated if anew assignment replaces the old one. Therefore, amechanism must be developed for managing changes.

A straightforward solution to this problem is toŽ .use the certificate revocation list CRL . The same

data structure of the CRL for public-key certificatescan be applied. In that structure, a field is used to

Ž .specify the reason for the revocation see Section 2 .

7. Use of role attribute certificates in access con-trol enforcement

We use role attribute certificates in an environ-ment in which access control is based on the RBACtheory. When an initiator requests an informationresource from an application server during an RBACduty session, he uses his public-key certificate forthe purpose of identity authentication and uses hisrole attribute certificate to provide the Access Con-

Ž .trol Decision Function ACDF with the access con-trol information stored in his role attribute certificate.Since the role attribute certificate embeds the serialnumber of the initiator’s public-key certificate, therelationship between the attribute certificate and itsholder is confirmed. This binding streamlines autho-rization validation along with the identity authentica-tion function.

A user’s access request consists of, at least, hisdistinguishing role identifier, requested operations,and target objects. To agree to the request, the role


must be authorized to have the privileges on therequested operations and target objects.

Similar to the concept of access control lists intraditional systems, authorized operations and rolesare bound together with target objects as shown inFig. 5. As shown in Fig. 5, the access control list ofa target object binds the authorized roles and theauthorized operations to the object itself. For exam-ple, Secretary, Project Member, and Salesperson areroles that are permitted to read and write the objectof a particular letter. The role identifiers to which anemployee is assigned are recorded in the attributefield of his role attribute certificate. The informationis available to the ACDF at the site of the applicationserver.

In most scenarios, access control decisions mustobey the security policies established for internalcontrol to insure proper organizational functioning.Many of the policies are context-dependent. A prac-tical system is likely to require several ways to storeinformation obtained from different points in thebroad spectrum of access control information re-quirements. Some of the rules may be stored in thelocal knowledge bases at the application server, asshown in Fig. 5. For instance, a production manageris allowed to operate the application of a production

Ž .management system the target , but this must hap-pen during his duty shift. Such a rule is expressed asfollows:

Ž .Rule class: roless‘‘production manager’’ &&Ž .Qualifier typess‘‘duty shift’’–

Ž .IF CurrentTimessQualifier value–Ž .Then GrantAccesssYes

Fig. 5. Access control decision phase.

As a second example, a member of a cooperativeproject can access project related information only ifthe target file is in the directory which belongs to theproper organization. This policy can be representedas follows:

Ž .Rule class: roless‘‘project member’’ &&Ž .Qualifier typess‘‘Organization Name’’–

Ž .IF DirOwnerssQualifier value–Ž .Then GrantAccesssYes

If the rules in local knowledge bases are role-de-pendent like the rules given above, informationneeded to check the rules can be conveyed in rolecertificates. For example, duty-shift information isrole-dependent and is stored as qualifier informationin a role attribute certificate.

8. Merits and discussion

The RBAC scheme is comprehensive in scope.Much access control information is required in sys-tems to realize the scheme. Because of the variousinformation needs, we must define representationstructures for different types of access control infor-mation. For instance, a rule-based expression may beadequate for representation of constraint-type secu-rity policies, and a simple data structure of tablesmaybe good for representing user-role assignmentsŽ .UA relations in Fig. 2 and role-privilege assign-

Ž .ments PA relations in Fig. 2 . Furthermore, whereeach type of information should be placed in asystem must also be examined.

We use role attribute certificates to convey accesscontrol information. As defined in Section 5, theinformation conveyed in the certificate primarilyconsists of user-role assignments. Related con-straints, such as qualifier information about assign-ments, can be included in the Extensions field of thecertificate. As stated in Section 4, our approach toplacing this type of information in certificates gainsthe advantages of both central management and re-ducing communication. RACA is an RBAC adminis-trator who is responsible for certification, issuance,and revocation of certificates; as a result, certificatesare centrally managed. To provide information forlocal enforcement of access control, the certificate


goes to the location where it is needed; consequently,no communication connections are needed in orderto fetch user-role assignment information.

Nevertheless, this approach is only one part of acomplete solution. Where other types of access con-trol information should be placed must be examinedfurther and is beyond the scope of this paper.

To understand better the merits of using roleattribute certificates, we can compare this approachwith that adopted for the Secure European System in

Ž .a Multi-vendor Environment SESAME Projectw x10,16 , which is an implementation based on thestandards defined for open system security services.In SESAME, access control information is managed

Ž .centrally on the Privilege Attribute Server PAS .Users have to establish a connection to PAS andrequest proof of their privileges. PAS codes therequested privileges into a Privilege Attribute Cer-

Ž .tificate PAC , which is later presented by the certifi-cate owner to application servers. The differencesbetween the two types of certificate, role attributecertificates and PACs, include the following.

Ø In SESAME, for a login session, each usertakes exactly one role. Therefore, if a user intends toassume another role, he has to request a new PAC.In our approach, a role attribute certificate containsall the subject’s qualified role identifiers; thus, it canbe used in several sessions.

ŽØ A PAC is valid for a short time period a few.hours ; thus, the revocation problem is avoided. A

role attribute certificate, however, is basically goodfor a long period of time, and CRL is used to solvethe problem caused by changes in role attributes.

Ø In SESAME, user authentication is carried outŽ .in the authentication server AS , and access control

information is obtained from PAS. In our method,subjects themselves can hold public-key certificatesand role attribute certificates. Role attribute certifi-cates together with public-key certificates enable thesession process, i.e., authentication and authorizationvalidation, to be performed on application servers.This streamlined authorization with the authentica-tion function may be one benefit referred to by

ww x xVendenwauver et al. 16 : p. 297 : ‘‘We think thatthe mix of X.509 certificates and attribute certificatesoffers a lot of benefits.’’

Ø Information coded on PACs is primarily relatedto the subject’s role attributes or, perhaps to, groups.

In role attribute certificates, besides role identifiers,the qualifier information coded in extension fields,can provide additional fine-grained control over ac-cess to information resources.

9. Conclusions

In this study, we have described the generation,management, and use of role attribute certificates. Arole attribute certificate is a kind of X.509 attributecertificate with the subject’s role-assignment infor-mation provided in the form of target attributes. Inthis work, we have explained the generation proce-dure and its use in an assumed RBAC access controlenvironment. The X.509 standard does not describethe procedure that a user can follow to get his

ww xattribute certificate from the attribute authority 6 :xp. 49 . Our work supplements these standards even

though a role is only a kind of attribute.In this study, we have considered access control

from an organizational viewpoint. We have proposedrole attribute certificates based on the principle thataccess control should perform authorization valida-tion in addition to identity authentication. With roleattribute certificates and public-key certificates, iden-tity authentication and authorization validation canbe effectively streamlined. This raises the authentica-tion function using X.509 certificates to the level ofauthorization management.

The most significant benefit of conveying em-ployee’s role attributes using a role attribute certifi-cate is that duty sessions can be performed on eachserver without the need to connect again to authenti-cation servers and to authorization servers. Thus, therequired communication effort is reduced. Applica-tions in an open networking environment can benefitfrom role attribute certificates because no pre-reg-istration or storage of information about potentialusers in application servers is required.

Further research can focus on inter-domain accesscontrol problems. In this scenario, an enterprise isitself a security domain, and different enterprisesmay cooperate with each other by sharing theirinformation resources. Some cross-certification prob-lems may need to be solved if role attribute certifi-cates are used for authorization validation while


employee certificates are certified by the enterpriseto which they belong.

Acknowledgements

The authors would like to thank the NationalScience Council of the Republic of China for finan-cially supporting this research under contract No.NSC 87-2416-H-009-015-N8.

References

w x1 J. Barkley, Comparing Simple Role Based Access ControlModels and Access Control Lists, National Institute of Stan-dards and Technology, 1997, August.

w x2 M. Branchaud, A Survey of Public-Key Infrastructures, Mas-ter Thesis, Department of Computer Science, McGill Univer-sity, Montreal, March 1997.

w x Ž .3 W.E. Burr, Public Key Infrastructure PKI Technical Speci-Ž .fications Version 3 : Part C — Concepts of Operations,

NIST TWG-97-59, Working Draft, June 1998.w x4 D. Ferraiolo, J. Cugini, D.R. Kuhn, Role based access con-

trol: features and motivations, in: Proc. of Annual ComputerSecurity Applications Conference, IEEE Computer SocietyPress, 1995.

w x5 Y.-K. Hsu, S.P. Seymour, An intranet security frameworkbased on short-lived certificates, IEEE Internet ComputingŽ .1998 73–79.

w x Ž .6 ITU-T Recommendation X.509 ISOrIEC 9594-8 , Informa-tion Technology — Open Systems Interconnection — TheDirectory: Authentication Framework, June 1997.

w x Ž .7 ITU-T Recommendation X.812 ISOrIEC 10181-3 , Infor-mation Technology — Open Systems Interconnection —Security Frameworks for Open Systems: Access Control

Ž .Framework, 1995 E .w x8 C. King, Building a corporate public key infrastructure,

Ž . Ž .Comput. Secur. J. 8 2 1997 13–24.w x9 C. Neuman, Proxy-based authorization and accounting, in:

Proc. of the 13th International Conference on DistributedComputing Systems, Pittsburgh, 1993, May.

w x10 T.A. Parker, A Secure European System for Applications inŽ .A Multi-vendor Environment The SESAME Project , tech-

nical report at http:rrwww.engarde.comr;mcnrsunrisersesame.html, Associated Services Division, ICL, March 1992.

w x11 R.S. Sandhu, E.J. Coyne, H.L. Feinstein, C.E. Youman,Role-based access control: a multi-dimensional view, in:Proc. of 10th Annual Computer Security Applications Con-

Ž .ference, Orlando, FL, 1994, pp. 54–62, December .w x12 R.S. Sandhu, E.J. Coyne, H.L. Feinstein, C.E. Youman,

Ž .Role-based access control models, IEEE Comput. 199638–47.

w x13 Y. Sameshima, P. Kirstein, Authorization with security at-tributes and privilege delegation access control beyond the

Ž .ACL, Comput. Commun. 20 1997 376–384.w x14 R.S. Sandhu, P. Samarati, Access control: principles and

Ž . Ž .practice, IEEE Commun. Mag. 32 9 1994 40–48.w x15 Z. Tari, S.-W. Chan, A role-based access control for intranet

Ž .security, IEEE Internet Computing 1997 24–34.w x16 M. Vandenwauver, R. Govaerts, J. Vandewalle, How role

based access control is implemented in SESAME, in: Proc.of Sixth Workshop on Enabling Technologies: infrastructurefor collaborative enterprises: WET-ICE’97, MIT, Cambridge,

Ž .MA,1997, pp. 293–298, June .w x17 S. Wilson, Certificates and trust in electronic commerce, Inf.

Ž . Ž .Manage. Comput. Secur. 5 5 1997 175–178.

Jing-Jang Hwang began his academiccareer in 1976 as an instructor at Na-

Ž .tional Chiao Tung University NCTUin Taiwan, Republic of China. He isnow a professor of the Institute of Infor-mation Management at the same univer-sity. Given leave of absence for 3 years,he received his PhD degree from theUniversity of Florida in 1987. In addi-tion to teaching, he has designed severalcomputerized information systems,which include the administrative and thelibrary systems of NCTU itself, the

business system of a securities brokerage firm, and the officeautomation system of the judicial courts in Taiwan. Since 1990,he has also been involved in research on subjects of cryptography,information security, and electronic commerce, and has con-tributed research articles, in the English language as well as in theChinese language, to various magazines and journals.

Kou-Chen Wu received his BS degreein Computer Science and InformationEngineering in 1993 and the MBA andPhD degrees in 1995 and 1999, respec-tively, with major in Information Man-agement from National Chiao Tung Uni-versity in Taiwan, Republic of China.He is now an assistant researcher of theChunghwa Telecom. His research inter-ests include electronic commerce, infor-mation security, and cryptography.

Duen-Ren Liu received his BS and MSdegrees in computer science and infor-mation engineering from the NationalTaiwan University, Taiwan, in 1985 and1987, respectively, and the PhD degreein computer science from the Universityof Minnesota, in 1995. He is currentlyan associate professor of the Institute ofInformation Management, NationalChiao Tung University, Taiwan. His re-search interests include databases, elec-tronic commerce, information security,workflow systems, and Internet applica-

tions. Dr. Liu is an associate member of the IEEE, and a memberof the ACM.

access control with role attribute certificates

Documents