TrustBAC - Integrating Trust Relationships into the RBACModel for Access Control in Open Systems

Sudip ChakrabortyComputer Science Department

Colorado State UniversityFort Collins, CO 80523, USA

sudip@cs.colostate.edu

Indrajit RayComputer Science Department

Colorado State UniversityFort Collins, CO 80523, USA

indrajit@cs.colostate.edu

ABSTRACTConventional access control models like role based accesscontrol are suitable for regulating access to resources byknown users. However, these models have often found tobe inadequate for open and decentralized multi-centric sys-tems where the user population is dynamic and the identityof all users are not known in advance. For such systems, cre-dential based access control has been proposed. Credentialbased systems achieve access control by implementing a bi-nary notion of trust. If a user is trusted by virtue of success-ful evaluation of its credentials it is allowed access, otherwisenot. However, such credential based models have also beenfound to be lacking because of certain inherent drawbackswith the notion of credentials. In this work, we propose atrust based access control model called TrustBAC. It ex-tends the conventional role based access control model withthe notion of trust levels. Users are assigned to trust levelsinstead of roles based on a number of factors like user creden-tials, user behavior history, user recommendation etc. Trustlevels are assigned to roles which are assigned to permissionsas in role based access control. The TrustBAC model thusincorporates the advantages of both the role based accesscontrol model and credential based access control models.

Categories and Subject DescriptorsD.4.6 [Operating Systems]: Security and Protection—Access controls; H.1 [Models and Principles]: Miscella-neous; K.6.5 [Management of Computing and Infor-mation Systems]: Security and Protection

General TermsManagement, Security, Theory

KeywordsAccess control, Trust, RBAC

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SACMAT’06, June 7–9, 2006, Lake Tahoe, California, USA.Copyright 2006 ACM 1-59593-354-9/06/0006 ...$5.00.

1. INTRODUCTIONProper access control to resources is one of the major con-

cerns for any organization. Different models of access con-trol have been proposed over the years, for example, discre-tionary and mandatory access control models, Clark-Wilsonmodel, Task based models and Role Based Access Controlmodel. Among these, role based access control (RBAC) [15]is gradually emerging as the standard for access control. Themain advantage of RBAC over other access control modelsis the ease of security administration. In the RBAC modelaccess permissions are not assigned directly to the users butto abstractions known as “roles”. Roles correspond to dif-ferent job descriptions within an organization. Users areassigned to different roles and, thus, indirectly receive therelevant permissions. Thus, with RBAC, security is man-aged at a level corresponding to an organization’s humanresource structure.

Notwithstanding the success of the RBAC model, resear-chers have often found the model to be inadequate for openand decentralized multi-centric systems where the user pop-ulation is dynamic and the identity of all users are not knownin advance. Examples of such systems are service providersoperating over open systems like the Internet. It is almostimpossible to know beforehand all the users that will re-quest services in these systems. Assigning appropriate rolesto these users thus becomes an irrational and ad-hoc ex-ercise. To overcome the shortcomings of RBAC for suchsystems, researchers have proposed credential-based accesscontrol models [8, 7, 20]. Credentials implement a notion ofbinary trust. Here the user has to produce a predeterminedset of credentials (for example, credit card numbers or proofof membership to certain groups etc.) to gain specific ac-cess privileges. The credential provides information aboutthe rights, qualifications, responsibilities and other charac-teristics attributable to its bearer by one or more trustedauthorities. In addition, it provides trust information aboutthe authorities themselves. Researchers have also integratedcredential based access control with role-based access con-trol to facilitate security administration [22, 10, 21, 23].

Although credential based models solve the problem ofaccess control in open systems to a great extent, it still hasa number of shortcomings. A credential, strictly speaking,does not bind a user to its purported behavior or actions. Itdoes not guarantee that its bearer really satisfies the claimsin the credential. It does not convey any information aboutthe behavior of the bearer between the time the credentialwas issued and its use. A credential does not reveal whetherit was obtained via devious means. In real life some or all

49

such information may play crucial parts in access controldecisions. Additionally, credential based access control doesnot keep track of the user’s behavior history. Access per-mission is given on the basis of the credential presented fora particular session. Either the user’s credentials are ac-cepted and required privileges are allowed, or the creden-tials are rejected and the user does not get the access rights.Thus, good behavior by the user cannot be rewarded withenhanced privileges nor bad behavior be punished.

The above observations motivate us to revisit the problemof access control in decentralized and multi-centric open sys-tems. We believe credential based access control is a step inthe right direction. However, we would like to enhance thebinary trust paradigm in these models with a much richermulti-level trust model. In this new trust model, trust lev-els in the users can be determined not only by using thecredentials presented by the user but also from the resultsof past interactions with the user, from recommendationsabout the user and/or knowledge about other characteris-tics of the user. A user is mapped to different trust levelsbased on these information. Trust levels (and not users,unlike in conventional RBAC) are then mapped to roles ofRBAC. Thus our access control model is an enhanced RBAC(TrustBAC). Changes in the trust level of user changes theroles that the user has in the system and thus the user’sprivileges. The system can define as many trust levels as itwants and can assign each level to a specific set of resourcestied with a specific set of access privileges. The system justneeds to monitor the trust level of the user and the regula-tion of access is automatically achieved.

The rest of the paper is organized as follows. Section2 gives an overview of some of the related works on accesscontrol. There is a plethora of works in access control mech-anisms. Here we present some of the works that are relatedto role-based access control model. We also present worksthat address authorization issues in open environments, likethe Internet. In section 3 we formally present the core Trust-BAC model. We define the various components of the modeland the inter-relationships among the different components.In the TrustBAC model, trust relationship between the userand service provider is evaluated based on a vector model oftrust that we had proposed earlier [25]. We present the rele-vant portions of the trust model in section 4 and discuss themodifications to the basic model for adoption in TrustBAC.Next, in section 5, we discuss how the trust model worksin TrustBAC to perform access control. Finally section 6concludes the paper.

2. RELATED WORKRole-based Access Control (RBAC) was first introduced

by Ferraiolo and Kuhn in [14] to address the limitations ofdiscretionary access control model (DAC). Sandhu et. al [26]introduce four reference models to provide systematic ap-proach to understand RBAC model. Their framework sep-arates administration of RBAC from its use for controllingaccess. They also categorize the implementation of RBAC indifferent systems. Finally, after a series of modifications, theNIST standard for RBAC is proposed in [15]. The standardspecifies RBAC reference model which defines the scope offeatures that comprise the standard and provides terminolo-gies to support specification. The standard also specifiessystem and administrative functional specification which de-fines functional requirements for administrative operations

and system level functionalities. We have followed the ap-proach of the standard to formalize our TrustBAC model.

A main feature of the TrustBAC model is the use of userbehavior history is determining access privileges. Similarconcept of using execution history in access control can befound in literature. In [13] the authors present a history-based access control mechanism which is suitable for con-trolling access from mobile code. The scheme maintains aselective history of access requests made by individual pro-gram and use this history to measure the degree of safenessof a request. Another history based access control for codesis presented in [1]. In this scheme the access privileges of acode is determined in runtime by examining the attributesof the pieces of code that have run before. The pieces ofcode that have run includes the codes on stack as well asthe codes that have been called and returned. Also, oursis not the only work which uses the concept of trust in ac-cess control. Sandhu et. al in a recent paper [27] presenta trusted computing architecture to enforce access controlpolicies in peer-to-peer environment.

In [28], Thomas introduces the notion of TeaM-based Ac-cess Control (TMAC) as an approach to applying role-basedaccess control in collaborative environments. The “team” isan abstract container that encapsulates a set of users withspecific roles. A team is formed with the objective of accom-plishing a specific task. One advantage of TMAC model isit allows role-based permissions across object types as wellas fine-grained, identity-based control on individual usersin certain roles and to individual object instances. Geor-giadis et. al [16] extend TMAC model by integrating itwith RBAC and using it for general contextual informa-tion like time of access, location from which access is re-quested, location of the object for which access is requestedetc. Somewhat similar idea is presented in the YGuard ac-cess control model [29]. YGuard employs a set-based accesscontrol list where a group of subjects is authorized to accesssets of objects. That is, for those objects, every member ofthe group has same access privileges. Another similar ap-proach is coalition-based access control (CBAC) model [11]where a coalition (group of members) shares data with theirpartners while ensuring that their resources are safe frominappropriate access. They define the protection state of asystem, which provides the semantics of CBAC-based ac-cess policies. Researches are still continuing on issues andapplications of RBAC model. Some recent works includes[30] which presents a multilayered, distributed and location-dependent approach to RBAC; Park and Hwang [24] presenta scheme in P2P environment where RBAC mechanisms aredynamically supported based on each peer’s current context;in GEO-RBAC [4], Bertino et. al extend the RBAC modelto deal with spatial and location-based information.

Digital library is one of the major application areas of ac-cess control in open environments. There are quite a fewwork on authorization issues in digital library domain. Inone of the early work on access control in digital libraries,H.M. Gladney proposes a scheme called DACM (DocumentAccess Control Methods) in [18]. The basic idea is biasedtowards discretionary access control with some extensionsto handle mandatory access control. Winslett et. al [31]propose a mechanism to assure security and privacy for dig-ital library transactions. This is basically a credential-basedsystem where both client and server can specify their ownpolicies regarding credential disclosure and security. Client

50

uses a personal security assistant (PSA) module and theserver uses server security assistant (SSA) to manage cre-dentials and credential acceptance policies. In [2], Adamet. al propose a content-based authorization model for dig-ital library environments. Authorization is specified basedon positive and negative qualifications and characteristicsof the user. Credentials are associated with each user andrepresent qualifications and characteristics of the user.

There are a number of works that specifically address ac-cess control on the Internet. Bonatti and Samarati [9] pro-pose a uniform formal framework to regulate service accessand information disclosure on the Internet. The regulationis based on credentials. The framework includes mechanismto treat information which are not in the form of a certifi-cate and is needed for required access. It has comprisesa language for expressing access and release policies. Theframework also has a policy filtering mechanism which helpsthe entities involved in the communication to exchange theirrequirements in a concise and privacy preserving way. In [3]Bauer et. al describe the design, implementation, and per-formance of a system to control access on web. The systemis based on proof-carrying authorization (PCA). The accesscontrol model provides locating and using pieces of the se-curity policy that have been distributed across hosts andkeeping the policies hidden from unauthorized clients. Italso provides iterative authorization by which a server canrequire a browser to prove a series of challenges. In [17] theauthors address the problems of access control in large opensystems where the authenticated identity of an entity doesnot provide any information regarding the likely behaviorof that entity. Their scheme, called cryptographic accesscontrol, is based on cryptography to guarantee confidential-ity and integrity of objects stored in potentially untrustedservers in the system.

In [6], the authors present X-RBAC, an XML-based RBACpolicy specification framework to deal with access controlissues in dynamic XML-based web services. They extendX-RBAC to a trust-enhanced version in [5] where the roleassignment is based on trust. The authors define ‘trust’ as“the level of confidence associated with a user based on cer-tain certified attributes”. Unlike our model, this trust levelis not quantitatively measured. Instead, the authors use thetrust management approach of trusted third parties (e.g.,public key certification authority) and use the certificatesprovided by the third party to assign roles to the users. Theauthors argue that traditional access control schemes follow-ing identity or capability-based approach for authorizationdo not scale well to the distributed web services architecture.To overcome this limitation they describe a mechanism toconfigure X-GTRBAC to provide context-aware trust-basedaccess control in Web services. X-GTRBAC is a frameworkbased on Generalized Temporal Role Based Access Control– GTRBAC [19] It provides a generalized mechanism to ex-press a wide range of temporal constraints including periodicas well as duration constraints on roles, user-role assign-ments, and role-permission assignments. The X-GTRBACextends GTRBAC with XML to allow policy enforcementin heterogeneous and distributed environment.

In a current survey [12], the present state and futuretrends in the access control are discussed. The survey showsthat the new trend in access control are part of future com-munication infrastructure supporting mobile computing.

3. TRUSTBAC MODELThe TrustBAC model is defined in terms of a set of ele-

ments and relations among those elements. The elements areof the following types: user, user properties, session instance,session type, session, session history, trust level, role, ob-ject, action, permissions and constraint. The correspondingsets are USERS, USER PROPERTIES, SESSION INSTAN-CES, SESSION TYPES, SESSIONS, SESSION HISTORY,TRUST LEVELS, ROLES, OBJECTS, ACTIONS, PERMI-SSIONS and CONSTRAINTS. The TrustBAC model is il-lustrated in figure 1(we use one-directional arrows to rep-resent one-to-many relationships, two directional arrows todenote many-to-many relationships and plain lines to denoteone-to-one relationships). We define the different elementsas follows.

user A user ∈ USERS is defined as a human being. Thenotion of user can be extended to include systems, orintelligent agents, but for simplicity we choose to limita user to a human entity.

user properties Each user u has certain set of propertiesPu, called user properties. The set USER PROPERTI-ES =

Su∈USERS Pu. A user can manifest any subset

P of Pu (i.e., P ∈ 2Pu) at a particular session.

session instance A session instance ∈ SESSION INSTAN-CES is a ‘login’ instance of an user. A user can in-stantiate multiple login thereby initiating multiple ses-sion instances at the same time. A session instance isuniquely identified by a system generated id.

session-type A session instance is identified with a typewhich is determined by the set of properties mani-fested in that session instance by the user invokingthat session instance. For a session instance s invokedby a user u with P (P ⊆ Pu) properties, has the ses-sion type P . Formally, the set SESSION TYPES =2USER PROPERTIES.

session A session ∈ SESSIONS is identified by a session ins-tance with a session type. A session with session insta-nce s of type P is denoted by the symbol sP . Formally,SESSIONS = SESSION INSTANCES×SESSI-ON TY PES.

session history A session history ∈ SESSION HISTORYis a set of information regarding the user’s behaviorand trust level in a previous use of a session of thattype.

trust level A trust level is a set of real number between -1and +1. A user, at some instant of time with a particu-lar session has a trust level. The set TRUST LEVELSis the set of possible subsets of [-1, 1]. That is, TRUSTLEVELS = {S | S ⊆ [−1, 1]. Thus TRUST LEVELSbecomes an infinite set where each member S can beeither discrete or continuous.

role The concept of role is same as in the RBAC model. Arole ∈ ROLES is a job function with some associatedsemantics regarding the responsibilities conferred to auser assigned to the role.

object An object ∈ OBJECTS is a data resource as well asa system resource. It can be thought of as a containerthat contains information.

51

USERS TRUST_LEVELS ROLES

OBJECTS ACTIONS

UTA RTA

RD

PA

PERMISSIONS

SESSION_HISTORY

SESSION_TYPES

TLD

SESSION_INSTANCES

SESSIONS

CONSTRAINTS

STA

Figure 1: TrustBAC model

action An action ∈ ACTIONS is an executable image of aprogram. ‘read’, ‘write’, ‘execute’ are examples of atypical action.

permission A permission ∈ PERMISSIONS is an autho-rization to perform certain task within the system. Itis defined as a subset of OBJECTS × ACTIONS i.e.,PERMISSIONS = 2(OBJECTS×ACTIONS). There-fore, a permission = {(o, a) | o ∈ OBJECTS, a ∈ACTIONS}. Permissions are assigned to a role. Thetype of a permission depends on the nature of the sys-tem. The model does not dictate anything about thetype.

constraint We borrow the concept of constraint from RBACmodel. Therefore, a constraint ∈ CONSTRAINTSis defined as a predicate which applied to a relationbetween two TrustBAC elements returns a value of“acceptable” or “not-acceptable”. Constraints can beviewed as conditions imposed on the relationships andassignments.

Association between any two of the above elements arespecified by mathematical relations. TrustBAC has the foll-wing relations.

1. sua : USERS × SESSION INSTANCES × SESSION T-YPES → SESSIONS defines the user-session assign-ment relation. sua(u, s, P ) = sP for u ∈ USERS, s ∈SESSION INSTANCES, P ∈ SESSION TYPES, andsP ∈ SESSIONS shows that a single session sP of typeP is associated with a single user u with certain proper-ties P . A user can invoke multiple sessions of differenttypes simultaneously.

2. UTA ⊆ USERS × TRUST LEVELS defines the user-trust level assignment relation. It is a many-to-manyrelation where a user can have multiple trust levels.Since a user can invoke many sessions at a time, shecan have different trust levels, one for each invokedsession. A single trust level can be assigned to manyusers. The restriction on a member (u, L) ∈ UTA is Lmust be a singleton member of TRUST LEVELS i.e.,L = {l}, l ∈ [−1, 1].

3. STA ⊆ SESSIONS × TRUST LEVELS defines thesession-trust level assignment. It is a one-to-many re-lation where a session can have only one trust value.That is, the trust level L corresponding to that sessionis a singleton member of TRUST LEVELS. But manysessions can have the same trust level.

4. RTA ⊆ ROLES × TRUST LEVELS defines the role-trust level assignment relation. It is also a many-to-many relationship where a trust level can be associatedwith many roles and same role can be performed withdifferent trust levels.

5. The function ush: USERS × SESSIONS TYPES →SESSION HISTORY defines a three-way relation be-tween a user, a session type and the trust history ofthe user in an earlier use of a session of that type.ush(u, P ) = uh

P , where u ∈ USERS and P ∈ SES-SION TYPES. A session history uh

P is associated witha single user u and any session sP of type P . A usercan have many session histories as a user can invokemany sessions of different types.

6. PA ⊆ PERMISSIONS × ROLES is a many-to-manypermission to role assignment relation. An element in

52

PA is of type (p, r) where p ∈ PERMISSIONS and r ∈ROLES.

7. The function Assigned Roles : TRUST LEV ELS →2ROLES specifies the mapping of a trust level L(⊆[−1, 1]) onto a set of roles. Formally, Assigned Roles(L)= {r ∈ ROLES | (r, L) ∈ RTA}. It implies, for anyl ∈ L, Assigned Roles({l}) = Assigned Roles(L).

8. The function Assigned Permission : ROLES →2PERMISSIONS specifies the mapping of a role r onto aset of permissions. Formally, Assigned Permission(r)= {p ∈ PERMISSIONS | (p, r) ∈ PA}. This func-tion is same as assigned permissions function of RBACmodel.

The constraints are applied on the above assignment func-tions depending on the access control policies of the sys-tem. Constraints on Assigned Roles are similar to the con-straints on user-role assignment in RBAC model. It spec-ifies which roles are ‘permitted’ to be assigned to a cer-tain trust level. Constraints on Assigned Permissions de-termines the assignment of permissions to a specific role.RBAC model suggests different constraints like mutually ex-clusive role, prerequisite roles, cardinality constraints, staticseparation of duty, dynamic separation of duty etc. But weprefer not to specify any particular constraint on these func-tions. Rather we leave it as general to give finer control indefining access control policies depending on the require-ments of a system.

We also introduce a concept of role dominance amongroles in our model. Role dominance is similar to the con-cept of role hierarchies in RBAC model. A role dominancerelation, denoted by RD, defines a dominance relation be-tween two roles. The dominance is described in terms ofpermissions. We define role dominance as,

Definition 1. Role dominance RD ⊆ ROLES × ROLESis a partial order on ROLES where the partial order is calleda Dominance relation, denoted by �. For any (r1, r2) ∈ RD,we say r2 ‘dominates’ r1 only if all permissions assigned tor1 are also permissions of r2. Formally, (r1, r2) ∈ RD ⇒r1 � r2 and r1 � r2 ⇒ Assigned Permissions(r1) ⊆Assigned Permission(r2).

The above definition implies that any user u having a roler2 can have all the privileges of a user with role r1.

The relation RD induces a similar relation called trust lev-el dominance among trust levels in our model. When-ever there is a role dominance between two roles, there is atrust level dominance between the corresponding trust levels.Trust level dominance, denoted by TLD is defined as follows:

Definition 2. Trust level dominance, TLD ⊆ TRUST LE-V ELS × TRUST LEV ELS is a partial order relation onTRUST LEVELS and is denoted by ≤′. For any (L1, L2) ∈TLD, we say L2 ‘dominates’ L1 only if L1 ⊆ L2. If L2 is asingleton set {l2}, then dominance is defined as, sup{L1} ≤l2 that is, l2 is greater than or equal to the maximum ele-ment of L1. If both L1 = {l1} and L2 = {l2} are singletonsthen L1 ≤′ L2 ⇒ l1 ≤ l2 (the ≤ is the usual ‘less equal to’relation of number theory).

The relation TLD is induced by RD. That is, for any (r1, r2) ∈RD,∃(L1, L2) ∈ TLD such that r1 ∈ Assigned Roles(L1)and r2 ∈ Assigned Roles(L2). That is, the trust degree of

a user with role r2 is greater than that of a user with roler1.

4. MODEL FOR EVALUATING TRUSTRELATIONSHIPS

We adopt the vector model of trust that we had intro-duced earlier [25] for purpose of evaluating trust values ofusers. In this discussion we include the changes we havemade. The interested reader is referred to [25] for the coremodel.

Definition 3. Trust is defined to be the firm belief in thecompetence of an entity to act dependably and securelywithin a specific context.

Definition 4. Distrust is defined as the firm belief in theincompetence of an entity to act dependably and securelywithin a specified context.

Although we define trust and distrust separately in our model,we allow the possibility of a neutral position where there isneither trust nor distrust.

We specify trust in the form of a trust relationship be-tween two entities – the truster – an entity that trusts thetarget entity – and the trustee – the target entity that istrusted. This trust is always related to a particular context.An entity A needs not trust another entity B completely.A only needs to calculate the trust associated with B insome context pertinent to a situation. The specific con-text will depend on the nature of application and can bedefined accordingly. Based on our current model, trust isevaluated under one context c only. The simple trust rela-tionship (A

c−→ B)t is a vector with three components – ex-perience, knowledge, and recommendation. It is representedby (A

c−→ B)t = [AEcB,A Kc

B ,ψ RcB ], where AEc

B representsthe magnitude of A’s experience about B in context c, AKc

B

represents A’s knowledge and ψRcB represents the cumula-

tive effect of all B’s recommendations to A from differentsources.

To compute a trust relationship we assume that each ofthese three factors is expressed in terms of a numeric valuein the range [−1, 1] ∪ {⊥}. A negative value for the com-ponent is used to indicate the trust-negative type for thecomponent, whereas a positive value for the component isused to indicate the trust-positive type of the component. A0 (zero) value for the component indicates trust-neutral. Toindicate a lack of value due to insufficient information forany component we use the special symbol ⊥.

4.1 Computing the experience componentWe model experience in terms of the number of events en-

countered by a truster A regarding a trustee B in the contextc within a specified period of time [t0, tn]. An event can betrust-positive, trust-negative or, trust-neutral depending onwhether it contributes towards a trust-positive experience, atrust-negative experience or, a trust-neutral experience. In-tuitively, events far back in time does not count as stronglyas very recent events for computing trust values. Hence weintroduce the concept of experience policy which specifies alength of time interval subdivided into non-overlapping in-tervals. It is defined as follows.

Definition 5. An experience policy specifies a totally or-dered set of non-overlapping time intervals together with a

53

set of non-negative weights corresponding to each elementin the set of time intervals.

Recent intervals in the experience policy are given moreweight than those far back. The whole time period [t0, tn]is divided in such intervals and the truster A keeps a log ofevents occurring in these intervals.

If eik denote the kth event in the ith interval, then wedenote the value associated with eik as vik. This value isassigned according to relative importance of the event eik.Then, vik ∈ [−10, 0) if eik ∈ Q, vik ∈ (0, 10] if eik ∈ P andvik = 0 if eik ∈ N where, P = set of all trust-positive events,Q = set of all trust-negative events and N = set of all trust-neutral events. Here we modify our original definition of vika little. In [25] we did not distinguish between two trust-positive event or two-trust negative events. For all trust-positive events, we had vik = +1 and for all trust-negativeevents vik = −1. For this paper we choose to assign differentweights to differenet events. This allows the truster to definerelative importance of events.

The incidents Ij , corresponding to the jth time intervalis the normalized sum of the values of all the events, trust-positive, trust-negative, or neutral for the time interval. Thenormalization is done in such a way that Ij ∈ [−1, 1]. If nj isthe number of events that occurred in the jth time interval,then

Ij =

8<:⊥ , if � ek ∈ [tj−1, tj ] for any k

Pnjk=1 v

jk

Pnjk=1 |vj

k| , otherwise

The experience of A with regards to B for a particular con-text c is given by

AEcB =

nXi=1

wiIi (1)

where, wi is a non-negative weight assigned to ith interval.

4.2 Computing the knowledge componentThe knowledge component has two parts - direct knowl-

edge and indirect knowledge (or, reputation). The truster Aassigns two values to these two parts. Her knowledge policyregarding B in context c determines the weights to expressrelative importance between these two. Sum of the prod-uct of values and weights for the parts gives us a value forknowledge.

The knowledge of A with regards to B for a particularcontext c is given by

AKcB =

8>>><>>>:

d, if r =⊥r, if d =⊥wd · d + wr · r, if d �=⊥, r �=⊥⊥, if d = r =⊥

where d, r ∈ [−1, 1]∪{⊥} and wd + wr = 1. d and r are thevalues to direct and indirect knowledge respectively and wdand wr are the corresponding non-negative weights.

4.3 Computing the recommendationcomponent

Recommendation is evaluated on the basis of a recom-mendation value returned by a recommender to A about B.Truster A uses the “level of trust” he has on the recom-mender in the context “to provide a recommendation” as

a weight to the value returned. This weight multiplied bythe former value gives the actual recommendation score fortrustee B in context c.

The recommendation of A with regards to B for a partic-ular context c is given by

ΨRcB =

Pnj=1(v(A

rec−→ j)Nt ) · VjPnj=1(v(A

rec−→ j)Nt )(2)

where Ψ is a group of n recommenders, v(Arec−→ j)Nt ) =

trust-value of jth recommender and Vj = jth recommender’srecommendation value about the trustee B.

4.4 Trust vectorWe next observe that given the same set of values for the

factors that influence trust, two trusters may come up withtwo different trust values for the same trustee. We believethat there are two main reasons for this. First, during evalu-ation of a trust value, a truster may assign different weightsto the different factors that influence trust. The weightswill depend on the trust evaluation policy of the truster. Soif two different trusters assign two different sets of weights,then the resulting trust value will be different. The sec-ond reason is applicable only when the truster is a humanbeing and is completely subjective in nature – one personmay be more trusting than another. We believe that thislatter concept is extremely difficult to model. At this stagewe choose to disregard this feature in our model and assumethat all trusters are trusting to the same extent. We capturethe first factor using the concept of a normalization policy.The normalization policy is a vector of same dimension asof (A

c−→ B)t; the components are weights that are deter-mined by the corresponding trust evaluation policy of thetruster and assigned to experience, knowledge, and recom-mendation components of (A

c−→ B)t. The normalizationpolicy together with the experience policy and the knowl-edge policy form the truster’s trust evaluation policy.

We use the notation (Ac−→ B)Nt , called normalized trust

relationship to specify a trust relationship. It specifies A’snormalized trust on B at a given time t for a particularcontext c. This relationship is obtained from the simpletrust relationship – (A

c−→ B)t – after combining the former

with the normalizing policy. It is given by (Ac−→ B)Nt =

W � (Ac−→ B)t.

The � operator represents the normalization operator.Let (A

c−→ B)t = [AEcB,A Kc

B,ψ RcB] be a trust vector such

that AEcB , AKc

B , ψRcB ∈ [−1, 1] ∪ {⊥}. Let also W =

[WE , WK , WR] be the corresponding trust policy vectorsuch that WE + WK + WR = 1 and WE , WK , WR ∈ [0, 1].

The � operator generates the normalized trust relation-ship as

(Ac−→ B)Nt = W � (A

c−→ B)t

= [WE , WK , WR] � [AEcB , AKc

B, ψRcB ]

= [WE · AEcB , WK · AEc

B, WR · ψRcB]

= [ ˆAEc

B, ˆAKc

B , ˆψRc

B]

We next introduce a concept called the value of a trustrelationship. This is denoted by the expression v(A

c−→B)Nt and is a number in [−1, 1] ∪ {⊥} that is associatedwith the normalized trust relationship. The special symbol⊥ is used to denote the value when there is not enough

54

information to decide about trust, distrust, or neutrality.This value now represents the trustee’s trust degree.

Definition 6. The value of a normalized trust relation-ship (A

c−→ B)Nt = [ ˆAEc

B, ˆAKc

B, ˆΨRc

B ] is a number in

the range [−1, 1] ∪ {⊥} and is defined as v(Ac−→ B)Nt =

ˆAEc

B + ˆAKc

B + ˆΨRc

B .

The value for a normalized trust relationship allows us torevise the terms trust and distrust as follows:

v(Ac−→ B)Nt =

8>>>>><>>>>>:

[−1, 0) ⇒ it is distrust.

0 ⇒ it is neutral (i.e., neither trust

nor distrust).

(0, 1] ⇒ it is trust.

⊥ ⇒ it is undefined.

Finally, we investigate the dynamic nature of trust – howtrust (or distrust) changes over time. We make a couple ofobservations. First, trust depends on trust itself; that is atrust relationship established at some point of time in thepast influences the computation of trust at the current time.If an agent is positively trusted to begin with then negativefactors are often overlooked (that is given less weightage)when trust is re-evaluated in the agent. Second, trust decayswith time. This is owing to the effect of forgetfulness of thehuman mind. The second idea is captured by the equation

v( �Ttn) = v( �Tti)e−(v( �Tti

)Δt)2k

(3)

where, v( �Tti), be the value of a trust relationship, �Tti , at

time ti and v( �Ttn) be the decayed value of the same attime tn. We have developed a method to obtain a vec-tor of same dimension as of (A

c−→ B)Nt from this value

v( �Ttn). The effect of time is captured by the parameter kwhich is determined by the truster A’s dynamic policy re-garding the trustee B in context c. The current normalizedvector together with this time-affected vector are combinedaccording to their relative importance. Relative importanceis determined by truster’s history weight policy which spec-ifies two values α and β in [0, 1] (where, α + β = 1) asweights to current vector and the vector obtained from pre-vious trust value. The new vector thus obtained gives theactual normalized trust vector at time t for the trust rela-tionship between truster A and trustee B in context c. Thisis represented by the following equation

(Ac−→ B)Ntn =

8>>>>>>>><>>>>>>>>:

[ ˆAEc

B , ˆAKc

B , ˆΨRc

B ], if tn = 0

[v(T̂ )3

, v(T̂ )3

, v(T̂ )3

], if tn �= 0 and ˆAEc

B =ˆ

AKcB = ˆ

ΨRcB =⊥

α · [ ˆAEc

B, ˆAKc

B, ˆΨRc

B ] + β · [v(T̂ )3

, v(T̂ )3

, v(T̂ )3

],

if tn �= 0 and at least one

of ˆAEc

B, ˆAKc

B, ˆΨRc

B �=⊥

where [v(T̂ )3

, v(T̂ )3

, v(T̂ )3

] is the time-effected vector and v(T̂ ) =

v( �Ttn).

5. ACCESS CONTROL USING TRUSTBACBasic purpose of an access control mechanism is to pro-

tect system resources by restricting the user’s activities onthem. A user’s authorization to perform certain tasks onspecific resources is specified by the access control policy of

the system. When using TrustBAC for access control, a userinvokes a session instance of a particular type at an instantof time. During this session the user has a trust level whichallows her to use the roles associated with that trust level.That is, a user can be a member of a role. Also a singlerole can be exercised by many users. For each of these roles,the user has a set of permissions. Therefore, the user is re-stricted to perform a set operations on a particular set ofresources as specified by the set of permissions obtained asa member of those roles.

A first time user u registers with the system and logsin which instantiates a session instance s of the user. De-pending on the set of disclosed properties P , the systeminvokes the function sua with arguments u, s, and P tostart a session sP . The system initiates a trust relationship

(SY SP−→ u)Nt with the user in that session. The under-

lying context of this trust relationship is identified by thesession type P . This relationship does not change, but getsupdated for any other session of same type P invoked by thesame user u. If the user invokes another session instance oftype P ′ at time t, then the system creates another trust

relationship (SY SP ′−→ u)Nt . The value of the trust re-

lationship (SY SP−→ u)Nt is evaluated for the session sP .

Let v(SY SP−→ u)Nt = l, l ∈ [−1, 1]. The system in-

vokes the function Assigned Roles to determine the rolesthat the user u can execute. Let Assigned Roles({l}) ={r1, r2, . . . , rn}. u can choose to execute more than oneof these n roles. With each ri, u has a set of pjs where∀j, (pj , ri) ∈ PA. Therefore, in a session sP , the user u hasthe set of permissions given by,

Si Assigned Permissions(ri)

=S

1≤i≤n{pji | (pj , ri) ∈ PA}. Hence, the user u is re-stricted to perform actions A on a set of objects O where∃ a pji ∈

S1≤i≤n{pji | (pj , ri) ∈ PA}, such that, for any

(o, a) ∈ O × A, (o, a) ∈ pji. The user executes these ac-tions on the allowed objects and each activity during thatsession sP is stored as the session history uh

P for that ses-sion. Whenever the trust level is re-evaluated (within sP or,at the start of next instance s′ of a session of type P ), theevents in uh

P are evaluated. The evaluated trust level, sayl′ overwrites l in uh

P . The subsequent events also overwritethe previous event log.

We assume that for a registered user u in a session sP ,

the trust relationship (SY SP−→ u) is managed by a diligent

system-administrator who is outside the scope of this accesscontrol framework. We denote this system-admin by thesymbol SY S. We also assume that the system has two pre-defined policies – an access control policy Asys and a trustevaluation policy Tsys which are not independent. Asys de-fines the functions Assigned Roles and Assigned Permissi-ons together with the ‘constraints’ on them. The compo-nents are evaluated as

Computing knowledge The user u initiates the session sP

by disclosing a set of properties P , which includes in-formation (e.g., name, address, affiliation, etc.) as wellas some credentials. Credentials are in the form oftypical digital certificates. The system assign a valuewithin [−1, 1] as weights to the information and thecredentials. The assignment is done as specified byTsys and SY SKP

u is computed according to the equa-tion 4.2. The next instance of a session of type P ,the values assign to members of P may change due

55

to change in values in P . For example, the user dis-close the same type of certificate, but with a differentcertifying authority.

Computing experience As mentioned in section 4.1, ex-perience is computed from the events occurred duringsome intervals. Our model does not dictate about thelength of an interval. It depends on implementation– the system may choose to identify a whole sessionas an interval. Independent of the length of an in-terval, any action performed by the user is identifiedas an ‘event’. This record is kept in session history

uhP till the next instant of trust evaluation. For-

mally, let l be the trust level of u in a session sP . LetAssigned Roles(l) = {r1, r2, . . . , rn} of which u acti-vate r1, r2, r3. These are the active roles of u in sessionsP . The events are the set of actions A where for anya ∈ A, ∃ p ∈

S1≤i≤3 Assigned Permissions(ri). The

weight to the result of a particular action is assignedaccording to Tsys and the experience SY SEP

u is com-puted as specified by equations 1.

Computing recommendation The system may take role-specific and role-independent input from other usersabout u in a session. These information constituteu’s recommendation and the component ΨRP

u is calcu-lated using equation in 2. Ψ is the set of other userswho provide recommendation for u to SY S. However,we choose not to specify how these information arecollected.

After computing the components, the system calculates the

normalized trust by combining (SY SP−→ u)t and the nor-

malization policy of Tsys. Then the previous trust level is

fetched from uhP and final (SY S

P−→ u)Nt is calculated using

the equation 4.4. The corresponding value v(SY SP−→ u)Nt

is calculated as specified in the section 4.4. This value de-notes the current trust level of u in a session of type P andgets stored in corresponding session history uh

P .Note, TrustBAC does not verify the credentials disclosed

by the user. The TrustBAC module includes a trust evalu-ation module which computes and stores all relevant trustinformation including session history. It interacts with twopolicy specifier modules which stores Asys and Tsys. Au-thenticity and veracity of credentials are checked by a suit-able module outside the framework. It passes the neces-sary information to trust evaluation module. A compliancechecker and access controller module can be implemented toenforce the access privileges according to the trust decisions.It interacts with the access specifier and the trust evalua-tion module to enforce the proper access privileges. Thesemodules are outside TrustBAC framework and a part of theapplication which work in conjunction with TrustBAC.

5.1 ExampleLet us consider an example to show how the TrustBAC

framework works. For this purpose we assume that a digitallibrary system DL uses TrustBAC to control access privi-leges of its users for the resource present in that DL. TheDL has an access control policy ADL and a trust evaluationpolicy TDL. Let basic user and privilege user be two roles inthe ROLES set of the digital library. We assume ADL spec-ifies the following: Assigned Roles([0.05, 0.4]) = basicuserand Assigned Roles([0.35, 0.6]) = privilegeuser. Let a user

u log in to the system and manifest a set of credentials c(for simplicity we assume that user properties are expressedin terms of credentials). The system initiates a session sc

and the trust relationship (DLc−→ u)Nt is considered. The

credentials are verified and evaluated and the correspondingvalue is stored in DLKc

u. The session history uhc is consulted

and the trust is evaluated as v(DLc−→ u)Nt = 0.45. There-

fore, according to Assigned Roles the user at this stage isallowed to act as a privilege user as well as a basic user. Letthe user select the role of privilege user. Let the privilegeusers of DL be allowed to write comment about the articlespresent in the database as well as can upload digital copies ofarticles that are not present in the database. Let the systemconsider abusive/irrelevant comments as negative events andupload of a corrupted or inauthentic file as negative event.Let u during the session sc write several bad comments andupload a few inauthentic files. Each of these activities getreported in the session history uh

c. To handle recommen-dation we assume that DL is a part of a digital library con-sortium where the member DLs are linked to one another.During the session the DL system sends messages requestingfor recommendation from other members of the consortiumabout u. Let TB evaluate trust periodically within a ses-sion. Let at some evaluation point v(DL

c−→ u)Nt = 0.345.This shows that u is no longer ‘trustworthy’ to the systemas a privilege user. The system automatically withold therole of privilege user for u. During the remaining time inthis session u can no longer act as a privilege user. So ifthere is a section of articles in the DL which is only avail-able to privilege users then u can not access those articlesanymore. However, u can continue to act as a basic user.Otherwise she may logout. The next time u logs in withproperties c, u can only perform the role of a basic user.Good actions and good recommendations can increase thetrust level for u and when it reaches 0.35, u is again ableto act as privilege user. Alternatively, u can produce someextra credential (something like a special permission fromthe digital library authority) in the new session to raise hertrust level. However, the set of extra credential alone maynot be sufficient to raise the trust level. u may still needto behave well. How the trust level decreases for bad be-havior or increases with extra set of credentials depends onTDL. u can deliberately perform malicious actions as a priv-ilege user to get personal benefit without caring about hertrust level. For example she may want to decrease the rat-ing of a article written by someone she hates by putting badcomments about it. When she is restricted to perform as abasic user only then she starts behaving well to increase hertrust level to act again as a privilege user and repeats thecycle. To prevent this type building trust and then milk-ing the system can be prevented by “slow-to-increase’ and‘fast-to-decrease’ policy. The TDL can be so configured thatevery bad action is heavily penalized to lower the trust levelrapidly. Every good action adds only a little amount to thetrust level. So it will either need extra credentials and setof good recommendation or consistent good behavior over aseries of sessions.

6. CONCLUSIONIn this work, we introduce the TrustBAC model for ac-

cess control in open systems. The model extends the RBACmodel by introducing the notion of trust levels. Insteadof users being assigned to roles as in traditional RBAC,

56

users are assigned to trust levels. The user to trust levelassignment is determined by three factors – user’s past be-havior, knowledge about the user (for example, credentialspresented by the user) and recommendation provided byothers about the user. The system may choose one or allof these factors in deciding on the trust level. Trust lev-els are assigned to roles according to organizational policies.Roles are assigned to permissions as in the traditional RBACmodel.

The TrustBAC model being an extension of the RBACmodel has all the latter’s advantages. In addition, it bor-rows from credential based access control models in the sensethat TrustBAC relies on evaluation of user’s trustworthinessfor access control. The model does not preclude use of cre-dentials for such evaluation of trustworthiness. Thus themodel is well suited for open systems like the Internet.

A lot of work remains to be done. To begin with, we planto incorporate recent extensions to the basic RBAC model togive the TrustBAC model much richer semantics. Next weplan to develop a policy language for expressing access con-trol policies in the TrustBAC model. We plan to culminateour efforts by developing a permission management infras-tructure built around this model much in the same manneras the PERMIS project (http://sec.isi.salford.ac.uk/permis/)is doing for traditional RBAC.

AcknowledgmentThis work was partially supported by the U.S. Air ForceResearch Laboratory (AFRL) and the Federal Aviation Ad-ministration (FAA) under contract F30602-03-1-0101. Theviews presented here are solely that of the authors and donot necessarily represent those of the AFRL or the FAA.The authors would like to thank Mr. Robert Vaeth of theAFRL and Mr. Ernest Lucier of the FAA for their valuablecomments and their support for this work.

7. REFERENCES[1] M. Abadi and C. Fournet. History-based Access

Control for Mobile Code. In Proceedings of the 10thAnnual Network and Distributed System SecuritySymposium, pages 107–121, San Diego, California,USA, February 2003.

[2] N. R. Adam, V. Atluri, E. Bertino, and E. Ferrari. AContent-Based Authorization Model for DigitalLibraries. IEEE Transactions on Knowledge and DataEngineering, 14(2):296–315, March 2002.

[3] L. Bauer, M. A. Schneider, and E. W. Felten. AGeneral and Flexible Access-Control System for theWeb. In Proceedings of the 11th USENIX SecuritySymposium, San Francisco, California, USA, August2002.

[4] E. Bertino, B. Catania, and M. L. Damiani.GEO-RBAC: A Spatially Aware RBAC. InProceedings of the 10th ACM Symposium on AccessControl Models and Technologies (SACMAT’05),pages 29–37, Stockholm, Sweeden, June 2005.

[5] R. Bhatti, E. Bertino, and A. Ghafoor. A Trust-basedContext-Aware Access Control Model forWeb-Services. In Proceedings of the IEEEInternational Conference on Web Services (ICWS’04),pages 184–191, San Diego, California, USA, June 2004.

[6] R. Bhatti, J. Joshi, E. Bertino, and A. Ghafoor.Access Control in Dynamic XM-based Web-Serviceswith X-RBAC. In Proceedings of the 1st InternationalConference on Web Services, Las Vegas, Nevada,USA, June 2003.

[7] M. Blaze, J. Feigenbaum, and J. Ioannidis. TheKeyNote Trust Management System Version 2.Internet Society, Network Working Group. RFC 2704,1999.

[8] M. Blaze, J. Feigenbaum, and J. Lacy. DecentralizedTrust Management. In Proceedings of 17th IEEESymposium on Security and Privacy, pages 164–173,Oakland, California, USA, May 1996.

[9] P. Bonatti and P. Samarati. Regulating Service Accessand Information Release on the Web. In Proceedingsof the 7th ACM COnference on Computer andCommunication Security, pages 134–143, Athens,Greece, November 2000.

[10] D. Chadwick, A. Otenko, and E. Ball. Role-BasedAccess Control with X.509 Attribute Certificates.IEEE Internet Computing, 7(2):62–69, March/April2003.

[11] E. Cohen, R. K. Thomas, W. Winsborough, andD. Shands. Models for Coalition-based Access Control(CBAC). In Proceedings of the 7th ACM Symposiumon Access Control Models and Technologies(SACMAT’02), pages 97–106, Monterey, California,USA, June 2002.

[12] E. Damiani, S. Vimercati, and P. Samarati. NewParadigm for Access Control in Open Environments.In Proceedings of the 5th IEEE Symposium on SignalProcessing and Information Technology (ISSPIT’05),Athens, Greece, December 2005.

[13] G. Edjlali, A. Acharya, and V. Chaudhary.History-based Access Control for Mobile Code. InProceedings of the 5th ACM Conference on Computerand Communication Security (CCS’98), pages 38–48,San Francisco, California, USA, November 1998.

[14] D. Ferraiolo and R. Kuhn. Role-Based AccessControls. In Proceedings of the 15th NIST-NCSCNational Computer Security Conference, pages554–563, Bultimore, Maryland, USA, October 1992.

[15] D. Ferraiolo, R. Sandhu, S. Gavrila, R. Kuhn, andR. Chandramouli. Proposed NIST Standard forRole-Based Access Control. ACM Transactions onInformation and Systems Security, 4(3):224–274,August 2001.

[16] C. K. Georgiadis, I. Mavridis, G. Pangalos, and R. K.Thomas. Flexible Team-based Access Control UsingContexts. In Proceedings of the Sixth ACMSymposium on Access Control Models andTechnologies (SACMAT’01), pages 21–27, Chantily,Virginia, USA, May 2001.

[17] A. Harrington and C. Jensen. Cryptographic AccessControl in a Distributed File System. In Proceedingsof the 8th ACM Symposium on Access Control Modelsand Technologies (SACMAT’03), pages 158–165,Como, Italy, June 2003.

[18] H.M.Gladney. Access Control for Large Collections.ACM Transactions on Information Systems,15(2):154–194, April 1997.

57

[19] J. Joshi, E. Bertino, U. Latif, and A. Ghafoor. AGeneralized Temporal Role-Based Access ControlModel. IEEE Transactions on Knowledge and DataEngineering, 17(1):4–23, January 2005.

[20] N. Li and J. Mitchell. Datalog with Constraints: AFoundation for Trust-management Languages. InProceedings of the 5th International Symposium onPractical Aspects of Declarative Languages, NewOrleans, Louisiana, January 2003.

[21] N. Li and J. Mitchell. RT: A Role-based TrustManagement Framework. In Proceedings of the 3rdDARPA Information Survivability Conference andExposition, Washington D.C., April 2003.

[22] N. Li, J. Mitchell, and W. Winsborough. Design of aRole-Based Trust-Management Framework. InProceedings of the 2002 IEEE Symposium on Securityand Privacy, pages 114–130, Oakland, California, May2002.

[23] N. Li, W. Winsborough, and J. Mitchell. BeyondProof-of-Compliance: Safety and Availability Analysisin Trust Management. In Proceedings of the 2003IEEE Symposium on Security and Privacy, Oakland,California, May 2003.

[24] J. S. Park and J. Hwang. Role-based Access Controlfor Collaborative Enterprise In Peer-to-PeerComputing Environments. In Proceedings of the 8thACM Symposium on Access Control Models andTechnologies (SACMAT’03), pages 93–99, Como,Italy, June 2003.

[25] I. Ray and S. Chakraborty. A Vector Model of Trustfor Developing Trustworthy Systems. In Proceedings ofthe 9th European Symposium of Research in ComputerSecurity (ESORICS 2004), volume 3193 of LectureNotes in Computer Science, pages 260–275, SophiaAntipolis, France, September 2004.

[26] R. Sandhu, E. Coyne, H. Feinstein, and C. Youman.Role-Based Access Control Models. IEEE Computer,29(2):38–47, February 1996.

[27] R. Sandhu and X. Zhang. Peer-to-Peer Access ControlArchitecture Using Trusted Computing Technology. InProceedings of the 10th ACM Symposium on AccessControl Models and Technologies (SACMAT’05),pages 147–158, Stockholm, Sweeden, June 2005.

[28] R. K. Thomas. Team-based Access Control (TMAC):A Primitive for Applying Role-based Access Controlsin Collaborative Environments. In Proceedings of theSecond ACM Workshop on Role-based Access Control(RBAC’97), pages 13–19, Fairfax, Virginia, USA,November 1997.

[29] T. van den Akker, Q. O. Snell, and M. J. Clement.The YGuard Access Control Model: Set-based AccessControl. In Proceedings of the 6th ACM Symposiumon Access Control Models and Technologies(SACMAT’01), pages 75–84, Chantily, Virginia, USA,May 2001.

[30] H. F. Wedde and M. Lischka. Role-Based AccessControl in Ambient and Remote Space. In Proceedingsof the 9th ACM Symposium on Access Control Modelsand Technologies (SACMAT’04), pages 21–30,Yorktown Heights, New York, USA, June 2004.

[31] M. Winslett, N. Ching, V. Jones, and I. Slepchin.Assuring security and privacy for digital librarytransactions on the Web: client and server securitypolicies. In Proceedings of the IEEE internationalforum on Research and Technology Advances inDigital Libraries, pages 140–151, Washington, DC,USA, May 1997.

58