A flexible delegation processor for web-based information systems

www.elsevier.com/locate/csi

Computer Standards & Interf

A flexible delegation processor for web-based information systems

Eric Jui-Lin Lua,*, Yi-Hui Chenb

aDepartment of Computer Science and Information Engineering, National Changhua University of Education,

1 Jin De Rd., Paisha Village, Changhua 50007, Taiwan, R.O.C.bDepartment of Computer Science and Information Engineering, National Chung Cheng University,

160 San-Hsing, Min-Hsiung, Chia-Yi 621, Taiwan, R.O.C.

Received 30 January 2004; received in revised form 22 April 2004; accepted 21 August 2004

Available online 17 September 2004

Abstract

Web-based information systems (WISs) have been widely used by enterprises to accomplish business tasks through the

Internet. For contemporary WISs, it is important that when a user logs into a WIS, the user should be able to see his or her own

view of the system. To do so, it is imperative that a flexible authorization and delegation model should be developed for WISs.

In particular, the delegation model should support fine-grained delegation and controlled propagation on targets. In this paper,

we attempt to develop a flexible delegation model for WISs. The model is called Extensible Markup Language (XML)-based

delegation and revocation (XDR) model which supports fine-grained delegation and controlled propagation on resources.

Furthermore, the proposed model supports various types of delegation and revocation, such as single-step delegation, multistep

delegation, multiple delegation, partial delegation, separation of duties (SOD), and cascading revocation. Finally, a prototype

was designed and implemented to demonstrate the feasibility of the proposed model.

D 2004 Elsevier B.V. All rights reserved.

Keywords: XML; Granular access control; WIS; Delegation

1. Introduction

Due to the rapid growth of electronic commerce,

web-based information systems (WISs) have become

one of the most prevalent systems on the Internet [22].

WISs are information systems that consist of inter-

0920-5489/$ - see front matter D 2004 Elsevier B.V. All rights reserved.

doi:10.1016/j.csi.2004.08.005

* Corresponding author. Department of Information Manage-

ment, Chaoyang University of Technology, 168 Gifeng E. Rd.,

Wufeng, Taichung County, 413, Taiwan ROC. Tel.: +886 4233

2300 04285; fax: +886 4237 42337.

E-mail address: [email protected] (E.J.-L. Lu).

connected web pages that enable users to accomplish

business tasks interactively. Each web page is

composed of a set of form components, such as

labels, text fields, and buttons. For contemporary

WISs, it is very important that when a user logs into a

WIS, the user should be able to see his or her own

view of the system [15]. A user’s view contains

resources (either web pages or form components) that

are originally authorized to the user as well as

delegated from other users. As a result, the access

control system designed for WISs should support

granular access control to resources not only at the

aces 27 (2005) 241–256

E.J.-L. Lu, Y.-H. Chen / Computer Standards & Interfaces 27 (2005) 241–256242

level of web pages but also at the level of form

components. Additionally, it is desirable that the

access control system supports a fine-grained dele-

gation model that allows a user to delegate resources

to a delegatee so that the delegatee can act on behalf

of the user when the user is absent from his or her

work.

The structure of WISs is generally hierarchical. An

example of a WIS hierarchy is shown in Fig. 1. To

ease the management of delegation in WISs, it is

important that the fine-grained delegation model

supports both delegation of roles or users and

controlled propagation on resources. The controlled

propagation on resources is used to control what

propagation option an authorization can be applied to

the parent or child resources of a specific resource.

For example, as shown in Fig. 1, when Bob delegates

Node1 to Alice and enables its propagation option,

Alice can then access not only Node1 but also all of

its descendent nodes such as Node5.

Based on the concept of role-based access control

(RBAC), many delegation models were proposed in

the past [2,3,21,24–26]. The delegation mechanisms

Fig. 1. An example of

developed in these models are concentrated on

effectiveness and efficiency on the management of

delegation of roles. None of them considers the

controlled delegation on resources. Additionally, like

all traditional access control models, these delegation

models can only delegate a whole file (not part of the

file) to delegatees. Therefore, these models are not

suited for WISs.

Due to its rich structure, Extensible Markup

Language (XML) has been widely adopted to define

authorization policies. Several well-known research

projects that use XML to describe authorization

policies include the Author-X system [4–6], the

FASTER project [9–11], the X-Menu processor [14],

and the Semantic Access Control (SAC) model

[12,13,23]. However, they do not support delegation

at all. Based on the role-based access control (RBAC)

model, the PERMIS system [7,8] uses XML as the

policy specification language. Unfortunately, it is not

well suited for WISs inasmuch as the controlled

propagation on resources is not supported in its

current version. Navarro et al. [16] applied the

concept of constrained delegation to XML to decen-

a WIS hierarchy.

E.J.-L. Lu, Y.-H. Chen / Computer Standards & Interfaces 27 (2005) 241–256 243

tralize the management of authorizations. Similarly,

the controlled propagation on resources is not

designed into their model.

In this paper, we develop a fine-grained delegation

model that supports the controlled propagation on

resources. Furthermore, the proposed model supports

single-step delegation, multistep delegation, multiple

delegation, partial delegation, separation of duties

(SOD), and cascading revocation, which will be

defined in the next section. Like many other research

projects, we use XML to describe authorization and

delegation policies. To demonstrate the feasibility of

the model, a delegation processor called XML-based

delegation and revocation (XDR) was developed.

Furthermore, a simple web-based information system

was developed in a laboratory to work with the XDR.

The rest of the paper is organized as follows. First,

we illustrate the types of delegation and review

current delegation models in Section 2. Then, we

discuss the design issues of the XDR model in Section

3. We analyze and summarize the benefits of the

proposed XDR model in Section 4. The implementa-

tion details are discussed in Section 5. Finally, we

draw our conclusions and future works in Section 6.

2. Related works

In general, delegation allows a user to assign

another user to act on his or her behalf when he or she

is absent from his or her work. Furthermore,

delegation provides the capability of decentralizing

the management of authorizations in a system. There

are several types of delegation and revocation [2,26]:

(1) Temporary and permanent delegation: When a

person is on a business trip or is absent from his

or her work temporarily, he or she can authorize

another person or a group of people to act on his

or her behalf. This type of delegation is called

temporary delegation. If a user delegates his or

her privileges to another user and can no longer

take the privileges back, this type of delegation

is called permanent delegation.

(2) Monotonic and nonmonotonic delegation: In

monotonic delegation, a delegator does not lose

his or her privileges and can revoke the

delegation whenever he or she wishes. During

the delegation period, the delegator can redele-

gate the privileges to someone else. On the

contrary, a delegator loses his or her delegated

privileges for the duration of delegation in

nonmonotonic delegation.

(3) Total and partial delegation: When a user

delegates all of his or her permissions to his or

her delegatee, it is called total delegation. As for

partial delegation, it means that only a subset of

his or her permissions are delegated to his or her

delegatee.

(4) Self-acted and agent-acted delegation: In self-

acted delegation, a delegator conducts the

delegation by himself or herself. It is called

agent-acted delegation if the delegator nominates

a third party to administer the delegation on his

or her behalf.

(5) Single-step, multistep, and multiple delegations:

Single-step delegation means that the depth of

delegation chain is one. The delegated permis-

sions cannot be further delegated in single-step

delegation. Single-step delegation can be treated

as a special case of multistep delegation. In

multistep delegation, the depth of delegation

chain is greater than one, and the delegated

permissions can be further delegated multiple

times. Note that multistep delegation is different

from multiple delegation in that multiple dele-

gation allows a delegator to delegate his or her

permissions to more than one person at the same

time.

(6) Unilateral and bilateral agreement: In unilateral

agreement, the delegator can choose her deleg-

atees. Once chosen, the delegatee has to accept

this responsibility. As for bilateral agreement, it

means that a delegation will become valid only

when both the delegator and the delegatee agree

with the delegation.

(7) Cascading and noncascading revocation: In

multistep delegation of length three, for exam-

ple, if the delegation between the second person

and the third person are revoked when the first

person revokes the delegation he or she dele-

gated earlier, this type of revocation is called

cascading revocation. In noncascading revoca-

tion, the delegation between the second person

and the third person will not be revoked even

when the first person revokes the delegation.


(8) Grant-dependent and grant-independent delega-

tion: If only the delegator is allowed to revoke

the delegated privileges from the delegatees, this

type of delegation is called grant-dependent

delegation. On the contrary, if it is allowed that

any original user who has the privileges can

revoke the delegation, it is then called grant-

independent delegation.

In traditional access control models, the access

control policy, called authorization, specifies which

user (or subject) can access an object under certain

access modes. Because there is a direct link between a

subject and every object which the subject is allowed

to access, the administration cost is high when the

user’s privileges are modified frequently. The core

concept of role-based access control (RBAC) model is

roles which have organizational responsibilities. In

RBAC models, because roles are associated with

subjects and then objects are associated with the roles,

the strong links between subjects and objects can be

effectively separated, and thus, the administration cost

of authorization can be significantly decreased.

The ARBAC97 model proposed by Sandhu et al.

[21] is believed to be the most mature model for role-

based administration and has been widely adopted in

many operating systems [18–21] and database man-

agement systems [17]. Although it defines rules for

the administration of roles and introduces the concept

of delegations and revocations, it does not support

delegation such as multistep, multiple, and partial

delegations.

The RBDM0 model [2,3] is the first proposed

model that supports user-to-user delegations and total

delegations. In user-to-user delegations, a user of a

role is allowed to authorize another user to that role or

any of its junior roles. The RDM2000 model proposed

by Zhang et al. [24] is based on the RBDM0 model. It

supports single-step, partial, and multistep delega-

tions. The partial delegation they proposed is based on

roles, and their corresponding role hierarchy and

permission-to-role assignments are managed by

administrators. In other words, the partial delegation

defined in the RDM2000 model permits that a user

who is authorized to delegate a role r can also

delegate a role rV that is junior to r. The RDM2000

model was also implemented to demonstrate its

feasibility [25]. However, the RDM2000 model and

its prototype are not feasible in many applications that

require fine-grained controls. Furthermore, inasmuch

as permission-to-role assignments are managed by

administrators, the maintenance of permission-to-role

assignments will become extremely difficult as WISs

become larger and more complex. Thus, the model is

not suitable for WISs.

In 2003, Zhang et al. [26] proposed a PBDM

model that not only supports both role-to-role and

user-to-user delegations but also allows a user to

create a temporal role, assign permissions to the

temporal role, and then delegate another user to the

temporal role. Although the PBDM model is by far

the most complete model, the controlled propagation

on resources is not supported.

With the widespread adoption of XML documents,

both the Author-X system [4–6] and the FASTER

project [9–11] were proposed to control access to

XML documents when they are coauthored by many

and even by geographically separated authors. The X-

Menu system [14], proposed by Lu and Chen, is the

first access control system designed for web-based

information systems. Unlike the previous XML-based

access control systems, which assume that there is a

centralized server, Lopez et al. [12,13,23] proposed a

distributed access control model, called Semantic

Access Control (SAC) model, that allows the execu-

tion of authorization policies in multiple and untrusted

servers. Although all these systems use XML to

define authorization policies, they do not support

delegation at all.

Using XML and X.509 attribute certificates, the

PERMIS project [7,8] developed a role-based Priv-

ilege Management Infrastructure (PMI) that can be

used in various applications. Although the PERMIS

system had been implemented and installed in three

cities of Europe, the authorization language devel-

oped in the project only supports delegation of roles.

Aiming at decentralizing the management of author-

izations so that the authority to create a permission

and the permission itself can be clearly differ-

entiated, Navarro et al. [16] proposed a new

approach for access control and digital right manage-

ment by using constrained delegation. By applying

this approach, both Secure Assertion Markup Lan-

guage (SAML) and Extensible Access Control

Markup Language (XACML), which are XML-based

languages developed at OASIS, are extended so that


delegation becomes possible. However, the con-

trolled propagation on resources is not supported.

In an attempt to provide a flexible delegation model

for WISs, we developed an XML-based delegation

and revocation (XDR) model for WISs.

3. The design of the XDR model

The idea of the proposed XDR model is that a

delegator can delegate all or part of his or her

privileges to his or her delegatees. Several things

need to be noted. Firstly, the number of delegatees can

be one or more. Secondly, the granularity of the

delegated privileges can be as small as form compo-

nents such as a text field or button. Thirdly, all or part

of the delegated privileges can be further delegated to

other users. Lastly, the XDR model should support the

controlled propagation on resources.

To fulfill the above requirements, the proposed

model consists of the user information, the author-

ization rules, the WIS hierarchy, the delegated author-

ization rules, and the separation of duties (SOD) rules.

The user information includes users’ information such

as usernames and passwords. The authorization rules

specify which user is authorized to view or update

which documents, elements, or attributes. The WIS

hierarchy is the structure of a WIS. The delegated

authorization rules define which user has been

delegated by which delegator to view or update which

Fig. 2. A conceptual delega

documents, elements, or attributes. The separation of

duties (SOD) rules define the permissions that cannot

be authorized or delegated to the same user.

It is assumed that the communication channel

between the client and the web server is secure. After

a user logs in, the XDR processor uses the config-

uration files for the WIS hierarchy, authorization rules

(the original permissions are assigned by the admin-

istrator), and delegated authorization rules (the dele-

gated permission are delegated from the delegator) to

generate a delegation view for the user. Inasmuch as

both the authorization rules and delegated author-

ization rules are referenced, the user can delegate his

or her permissions, including original and delegated

permissions, to his or her delegatees. Additionally,

because the WIS hierarchy is checked, the XDR

processor allows the user to select a node in the WIS

hierarchy and enable its propagation option that

permits the delegation to be applied to the node and

its child nodes. Before the new delegated author-

ization rules for the delegatees is written back into the

configuration file for delegated authorization rules,

the SOD rules will be checked to ensure that no

conflict occurs.

As shown in Fig. 2, the access control processor is

composed of an X-Menu processor and an XDR

processor. The X-Menu processor is extended from

the X-Menu system [14] that we developed earlier.

The major difference between the two versions is that

the current version of the X-Menu processor generates

tion model for WISs.


user’s views based on both the authorization rules and

the delegated authorization rules. Only two config-

uration files, the delegated authorization rules and the

SOD rules, are newly designed for the XDR model.

The specification of the other three configuration files

is identical to the previous version of the X-Menu

processor. The five configuration files are described as

follows.

3.1. WIS hierarchy

In general, each WIS has a hierarchical structure.

In the WIS hierarchical structure, there are two types

of nodes: nonleaf and leaf nodes. A nonleaf node can

Fig. 3. An example

be seen as a menu or a set of menus. A leaf node is a

web page with form components so that users can

input or update business data.

The WIS hierarchy is described in XML. Fig. 1

gives an example of a WIS hierarchical structure, and

its corresponding XML file is shown in Fig. 3. If an

element is of type GROUP, it can include other

subelements. For example, an element of type

GROUP can contain an element of type LABEL and

several elements of type CHECKBOX (which allows

users to check multiple boxes at a time), or an element

of type LABEL and several elements of type RADIO

(which allows users to select one and only one radio

button at a time).

of Menu.xml.

Fig. 4. An example of user information.


3.2. User information

User information is used to verify users’ identities.

The design of the XDR model adopts credential-based

security policies which are based on user’s properties.

The credential properties included in the user infor-

mation are id,username, group, department,

and title. The id is the unique identifier of a user,

and the username is the user’s account name. The

properties group and department represent the

group and department, respectively, that a user

belongs to. The title indicates the position that a

user holds in his or her organization. An example

given in Fig. 4 shows the information for the users

badministratorQ, bBobQ, and bTomQ.

Fig. 5. An example of a

3.3. Authorization rules

Authorization rules specify who can access which

object under which mode. Therefore, an authorization

rule consists of three major parts, namely, subject,

object, and mode. Examples of authorization rules are

shown in Fig. 5.

Authorization rules are composed of six attributes.

The details of the attributes are described as follows:

(1) cred-expr: The cred-expr expresents the

subject of an authorization rule. In the XDR

model, credential-based security policies are

used to specify what user properties can be

applied to the authorization rules. In addition to

uthorization rules.

Fig. 6. An example of a delegation.


username, user properties, such as id,

department, group, and title, can also

be applied to authorization rules. For example, if

the value of the cred-expr is b//Person[group=bAdministratorsQ]Q, the specified sub-

jects are all users who belong to the group

bAdministratorsQ.(2) target and path: Both target and path

jointly identify the object of an authorization

rule. The target specifies the URL of the target

document, and the path identifies the path of a

node or an element in the target document.

The values of path and the above cred-

expr are expressed in XPath. XPath, one of

the W3C recommendations, is a path language

that can be used to identify parts of an XML

document. Through XPath expressions, an

authorization can be applied to a whole docu-

ment, elements (with or without subelements),

or even attributes.

(3) type and priv: Both type and priv jointly

specify the mode of an authorization rule.

Access to an object (or a set of objects) can be

granted or denied by using the type attribute.

The priv attribute indicates the privileges that

the authorized subject has been given for an

object. The acceptable values for the priv

attribute are VIEW and UPDATE. The UPDATE

attribute indicates that the subject is authorized

to enter a new value for (or update) a specified

object, while the VIEW attribute only allows the

subject to view the value of the specified object.

The VIEW or UPDATE value can be specified on

the leaf node elements. For nonleaf nodes, the

VIEW or UPDATE attribute is ignored. In

addition, the authorization rules for the lower

level nodes take precedence over the author-

ization rules for the higher level nodes in the

WIS hierarchy.

(4) prop: The prop specifies the propagation

option for the authorization rule. As shown in

Fig. 1, the Personnel DeptYPersonal

DataYAddYAdd.html is a navigation path.

Due to the hierarchy of WISs, it makes no sense

to authorize a user to be able to view

Add.html without allowing the user to view

Personnel Dept, Personal Data, and

Add. Thus, the value of the prop attribute is

bCASCADEQ to indicate that whenever the

access to a node is granted, the authorization

will be automatically applied recursively to all

its parent nodes. With this design, the controlled

propagation on resources is supported in both

authorization and delegation.

3.4. Delegated authorization rules

When a delegator delegates his or her permissions

to others, the delegation chain and the permissions

must be recorded in the delegated authorization rules.

A delegation chain is an ordered list of user-to-user

permission assignments generated through delega-

tions. It always starts from an original user who

delegates all or part of his or her original permissions

to his or her delegatees. The definition of a delegation

chain in the proposed model is different from the

RDM2000 model defined by Zhang et al. [25]. For

example, for the delegations, as shown in Fig. 6, only

one delegation chain is needed in our model.

However, in the RDM2000 model, seven delegation

chains are required: JoeYBob, JoeYBobYTom,

JoeYBobYTomYAlice, JoeYBobYTomYEric,

JoeYBobYEric, JoeYBobYEricYBill, and

JoeYBobYAmy.

The delegated authorization rules are encoded in

XML, and its schema is shown in Fig. 7(a). To keep

the schema as simple as possible, we choose DTD to

describe the schema. In Fig. 7(a), the policy_-

base element is the root element, and it consists of

Fig. 7. (a) The schema for the delegated authorization rules and (b) an example.


two parts including one proxylist_spec element

and at least one policy_spec element. The

proxylist_spec element is a complex element,

and each delegation chain is described by a list

element. For example, if Bob authorizes Tom to act

on his behalf, the delegation chain is recorded in

lines 3 to 7 in Fig. 7(b).

The list_no attribute of the list and

policy_spec elements is used to establish the

relationship between the permissions for the

delegatee and its associate delegation chain. The

value of the list_no attribute is unique in order

to indicate that each delegation chain is unique in

the system, and it is generated by using the OID

generation algorithm [1]. The list element is

composed of at least one listname element, and

the listname element itself may contain list-

name elements. Each listname element has a

subject attribute to specify the credential-based

information of the user. A simple example is

shown in Fig. 7(b). Bob delegates his permissions

to Tom. The delegation chain is created in the

proxylist_spec element. The identifier of the

delegation chain is DL_000001. The credential-

based information of Bob and Tom is expressed in

the subject attribute of the listname ele-

ments. Because Bob is the delegator, the list-

name element for Bob is the parent element of

the listname element for Tom. The policy_-

spec element specifies the permissions for a

delegatee and is similar to the authorization rules

mentioned earlier. Note that inasmuch as the

propagation option prop is also defined in the

delegated authorization rules, the controlled prop-

agation on resources is supported in the XDR

model.

3.5. SOD rules

For security reasons, a user cannot be given a

permission that is mutually exclusive to another

permission that the user has. For instance, an

account manager cannot be authorized to participate

in issuing checks. This constrain is called separa-

tion of duties (SOD). Thus, the SOD rules prevent

a user from holding conflicting authorizations.

When a delegator wants to delegate his or her

permissions to his or her delegatee, the system will

check the SOD rules first. If there are no

conflictions, the delegation will be successfully

completed.

Each SOD rule specifies a user who cannot own

specific permissions under a certain mode. Fig. 8(a)

shows the schema for the SOD rules. The SOD_-

base element is the root element and consists of at

least one policy_spec element to describe the

constraints. An example of an SOD rule is shown in

Fig. 8(b). The example SOD rule indicates that no

one can assign bM_0000_000019Q and all of its child

nodes to Bob.

3.6. Disallowed delegation

In the proposed XDR model, a user cannot

delegate any permission pi to a delegatee if piaP,

where P is the set of (both original and delegated)

Fig. 8. (a) The schema for the SOD rules and (b) an example.


permissions that the delegatee has. The following

examples illustrate disallowed delegations. As shown

in Fig. 9(a), there exists the delegation chain

BobYTomYAliceYEric. For example, if the dele-

gated permission is pi, Eric cannot delegate pi to

either Bob, Tom, or Alice if they already have it.

Similarly, Joe cannot delegate pi to Alice if she

already has pi, as pictured in Fig. 9(b).

If the mentioned delegations are supported, it

makes cascading revocation extremely difficult, if

impossible, to implement. An example is shown in

Fig. 9(a). Alice has the permission pi which is

authorized by Tom. She then delegates pi to Eric

and, in turn, Eric delegates pi to Tom. If Alice

wishes to revoke pi from Eric, should pi be revoked

from Tom?

3.7. Examples

In this section, we use examples to demonstrate

that the XDR model supports multistep delegation,

multiple delegation, partial delegations with fine-

Fig. 9. Examples of disallowed delegation.

grained control, and cascading revocation. The

example for single-step delegation is so simple that

we intensionally omit it for brevity.

3.7.1. Multistep delegation

In the following discussions, a permission p is

denoted as a tuple of the form (objecti, modei, typei).

For an example in multistep delegation, Tom

delegates the permission p=(//Menu[@ID=dM_

0000_000007T], dUPDATET, dGRANTT) delegated

from Bob to Alice. Therefore, one delegation chain

numbered as dDL_000001T is created, which is

shown in lines 3 to 8 in Fig. 10. Inasmuch as the

delegation chain is BobYTomYAlice, the list-

name element for Alice is the child element of the

listname element for Tom, while Tom is the child

element of Bob. In addition, the permission p

delegated from Bob to Tom and from Tom to Alice

is encoded in lines 11 to 13 and lines 14 to 16,

respectively.

3.7.2. Multiple delegation

For an example multiple delegation where Bob

delegates a subset of his original permissions to Tom

and Eric at the same time, there are two delegation

chains. One is from Bob to Tom and numbered as

dDL_000001T. The other is from Bob to Eric and

numbered as dDL_000002T. It is noted that the

permissions delegated to Tom and Eric can be

different, as shown in Fig. 11.

3.7.3. Partial delegation with fine-grained control

and the controlled propagation on resources

A user can delegate all or part of his or her

permissions to other users. Because authorizations

are written in XML in the XDR model, granularity

can be as small as a form component such as a

text field or button on a web page. This is called

Fig. 10. An example of multistep delegation.


partial delegation with fine-grained control. For

example, as shown in Fig. 12, Tom authorizes a

permission p1=(//Menu[@ID=dM_0000_000007T],dUPDATET, dGRANTT) delegated from Bob to

Alice. Because of the WIS hierarchy, a user who

has the permission p1 with the propagation option

dCASCADET will automatically have the permis-

sion p 2=(//Element[@ID=dE_0000_000132T],dUPDATET, dGRANTT). Therefore, Tom can

authorize p2 which is part of p1 to Eric. The

delegation from Tom to Alice is called total

Fig. 11. An example of m

delegation, while the delegation from Tom to Eric

is called partial delegation.

3.7.4. Cascading revocation

Revocation refers to the process by which a

delegator can withdraw the permissions that he or

she delegated earlier. Cascading revocation allows a

user to directly revoke delegated permissions from his

or her delegatees and indirectly revoke a set of

subsequent propagated delegated permissions along

the delegation chain. For an example discussed earlier,

ultiple delegation.

Fig. 12. An example of partial delegation with fine-grained control and controlled propagation on resources.


when Bob revokes the delegation from Tom, the

permissions delegated from Tom to Alice and Eric

will also be revoked.

4. Analysis of the XDR model

We have proposed a delegation and revocation

model called XDR for WISs. In addition, a prototype

was developed. The features of the proposed model

are summarized as follows:

(1) Permanent and temporary delegation: The

proposed model supports both permanent and

temporary delegations because a user can revoke

a delegation as he or she wishes. If a delegation

is never revoked, the delegation is permanent.

(2) Monotonic delegation: The proposed model

supports monotonic delegation because a user

delegates his or her permissions to his or her

delegatee, he or she does not loose his or her

privileges, and he or she can redelegate it to

someone else.

(3) Self-acted delegation: Because the XDR model

allows a user to delegate his or her own

permissions to his or her delegatee by himself

or herself, the proposed model supports self-

acting delegation. We believe this is an impor-

tant feature for WISs. In most role-based access

control models, delegations are managed by

administrators. For large and complex WISs,

the maintenance of delegations by administrators

will become extremely difficult.

(4) Unilateral agreement: In the XDR model, a

delegator can decide whether or not a delegation

will take place. In other words, the delegatee has

to accept the responsibility that the delegator

assigns to him or her. Thus, unilateral agreement

is supported.

(5) Grant-dependent delegation: Because only the

delegator can revoke the delegations that he or

she delegated, the proposed model supports

grant-dependent delegation.

(6) The proposed model supports single-step, multi-

step, multiple, partial, and total delegations,

which were discussed earlier. Furthermore, the

support of controlled propagation on resources,

cascading revocation, and separation of duties is

also included in the XDR model.

(7) Fine-grained control: Although Zhang et al.

[24–26] designed and implemented delegation

models, the delegated object must be a whole

file or document. These models cannot delegate

part of a file or document, such as an employee’s

salary in a web page, as discussed in the

previous section. The XDR model is extended

from the X-Menu model and uses XML to define

authorization and delegation policies. Thus, one


can easily delegate a whole document, elements,

and attributes to other users. Granularity can be

as small as a form component, such as a text

field or button on a web page.

(8) Platform independence: In as much as all confi-

guration files are encoded in XML, and inas-

much as the system was developed using Java,

the proposed system is platform-independent.

(9) Easy revocation: For the delegation shown in

Fig. 6, only one delegation chain is needed in

the XDR model. However, by using the

RDM2000 model [24,25], there will be seven

delegation chains: JoeYBob, JoeYBobYTom,

JoeYBobYTomYAlice, JoeYBobYTom

YEric, JoeYBobYEric, JoeYBobYEric

YBill, and JoeYBobYAmy. Thus, assuming

that the required information are encoded in

XML for both the XDR and RDM2000 models,

the benefits of the XDR model in revocation is

summarized as follows:

! The size of the delegated authorization

rules in the RDM2000 model is larger than

our model. Even worse, the size of the

delegated authorization rules in the

RDM2000 model will grow exponentially

as the number and complexity of multistep

delegations increase.

! Our model is more efficient than the

RDM2000 model in terms of revocation.

For example, if Bob wishes to revoke all

delegations assigned to Tom, Alice, and Eric,

Fig. 13. (a) Bob’s and (b) Eric’s original and (

as shown in Fig. 6 as dashed lines, only one

delegation chain has to be searched and

processed. However, in the RDM2000

model, three individual delegation chains

(JoeYBobYTom, JoeYBobYTomYAlice,

and JoeYBobYTomYEric) have to be

searched and processed.

(10) The existing XML-based access control mod-

els, such as the Author-X system, the FASTER

project, the SAC model, and the X-Menu

processor, provide viable mechanisms for

various granularity level controls on XML

documents. Unfortunately, none of them sup-

ports delegations. Although the PERMIS infra-

structure and the XML-based constrained

delegation support delegation of roles, the

controlled propagation on resources is not

supported. The proposed XDR model provides

a flexible delegation mechanism for WISs.

5. Implementation

A prototype was developed to verify the feasibility

of the model we proposed. For portability, we chose

Java to develop the prototype. Because the user

information, authorization rules, WIS hierarchy,

SOD rules, and delegated authorization rules are all

encoded in XML, and because we need to transform

the XML documents into menus (in XML) and view

(in HTML or WML), we used XSLT for the

c) delegated views on the example WIS.


transformations. Apache’s Xalan was used for pro-

cessing XML and XSLT files. In the prototype, users

are allowed to delegate their permissions to other

users. Furthermore, a simple web-based information

system was developed to be used with the XDR

processor.

Suppose that Bob is a manager of a company

and he is authorized to access all functions of the

example WIS. This results in the view shown in

Fig. 13(a) after he logs in. Eric is a staff member in

the personnel department of the company and,

except for salary data, is allowed to enter other

data for new employees. Eric also has the privileges

to update and query all the employees’ data except

for the salary data. Because the salary data of an

employee is sensitive data, it can only be updated

by a privileged user such as Bob. Fig. 14(b) shows

the view that is generated based on Eric’s privilege

after he logs in. Because Eric is not authorized to

use any function designed for the accounting,

manufacturing, and administration department, there

are no accounting department, manufacturing

department, and administration department buttons,

as shown in Fig. 13(b).

When Bob asks for a leave, Bob delegates the

permissions for the accounting department and for

updating employees’ salary data to Eric. After the

delegation is successful, Eric has the accounting

department function, as shown in Fig. 13(c). Addi-

tionally, Eric has the permission to update the salary

data.

Fig. 14. (a) Eric’s original and (b) delegat

As shown in Fig. 14(b), the view shows Eric’s new

privileges after he logs in.

6. Conclusions

WISs have become mainstream systems on the

Internet. However, the development of authorization

and delegation for WISs is still in its infancy stage.

Although there exist many delegation models, they

are not suitable for WISs. In this paper, we proposed a

delegation and revocation model for WISs. A proto-

type was designed and implemented.

The proposed model provides partial delegation

with fine-grained control to let a user, before being

absent from his or her work, delegate her full or

partial permissions to his or her delegatee. In addition,

it also supports single-step delegation, multistep

delegation, multiple delegation, controlled propaga-

tion on resources, cascading revocation, and separa-

tion of permissions.

In the current design of the proposed model, the

delegation specification is based on user’s properties

and therefore can be further extended to incorporate

the concept of roles to provide a better control

mechanism for WISs in the future. Furthermore, in

our model, we assume that there is only one WIS for a

web server. In the future, we plan to extend the

proposed control model to multiple WISs in one web

server or distribute it over different web servers

managed in a federated manner.

ed views when updating user’s data.


Acknowledgements

This research was partially supported by the

National Science Council, Taiwan, under contract

no. NSC92-2213-E-324-032.

References

[1] Scott W. Ambler, Mapping Objects to Relational

Databases, Ronin International, http://www.AmbySoft.

com/mappingObjects.pdf, 2000.

[2] Ezedin Barka, Ravi Sandhu, Framework for role-based

delegation models, Proceeding of 16th Annual Computer

Security Application Conference (ACSAC 2000), 2000

December, pp. 168–176.

[3] Ezedin Barka, Ravi Sandhu, A role-based delegation model

and some extensions, Proceeding of 23rd National Information

Systems Security Conference, 2000 December.

[4] Elisa Bertino, Barbara Carminati, Elena Ferrari, XML security,

Technical report 2, Information Security Technical Report,

2001.

[5] Elisa Bertino, Silvana Castano, Specifying and enforcing

access control policies for XML document sources, World

Wide Web Journal 3 (3) (2000) 1–25.

[6] Elisa Bertino, Silvana Castano, Elena Ferrar, Securing XML

documents with Author-X, IEEE Internet Computing 5 (3)

(2001) 21–31.

[7] David W. Chadwick, Alexander Otenko, The PERMIS X.509

role based privilege management infrastructure, Proceedings

of the 7th ACM Symposium on Access Control Models and

Technologies, 2002 June, pp. 135–140.

[8] David W. Chadwick, Alexander Otenko, The PERMIS X.509

role based privilege management infrastructure, Future Gen-

eration Computer Systems 936 (2002 December) 1–13.

[9] Ernesto Damiani, Sabrina De Capitani di Vimercati, Stefano

Paraboschi, Pierangela Samarati, Design and implementation

of an access control processor for XML documents, Journal of

Computer and Telecommunications Networking 33 (1–6)

(2000 June) 59–75.


Paraboschi, Pierangela Samarati, Controlling access to XML

documents, IEEE Internet Computing 5 (6) (2001) 18–28.


Paraboschi, Pierangela Samarati, A fine-grained access control

system for XML documents, ACM Transactions on Informa-

tion and System Security 5 (2) (2002 May) 169–202.

[12] Javier Lopez, Antonio Mana, Juan J. Ortega, Jose M. Troya,

Mariemma I. Yague, Integrating PMI services in CORBA

applications, Computer Standards and Interfaces 25 (4) (2003

August) 391–409.

[13] Javier Lopez, Antonio Mana, Mariemma I. Yague, XML-

based distributed access control system, Third International

Conference on E-Commerce and Web Technologies

(ECWeb’02), 2002 September, pp. 203–213.

[14] Eric Jui-Lin Lu, Rai-Fu Chen, Design and implementation of a

fine-grained Menu control processor for Web-based informa-

tion systems, Future Generation Computer Systems 19 (7)

(2003 September) 1105–1119.

[15] Hermann Maurer, Modern WISs, Communications of the

ACM 41 (7) (1998 July) 114–115.

[16] Guillermo Navarro, Babak Sadighi Firozabadi, Erik Rissa-

nen, Joan Borrell, Constrained delegation in XML-based

access control and digital rights management standards,

CNIS03, Special Session on Architectures and Languages

for Digital Rights Management and Access Control, 2003

December.

[17] Chandramouli Ramaswamy, Ravi Sandhu, Role-based access

control features in commercial database management systems,

Proceeding of the 21st NIST-NCSC National Conference on

Information Systems Security, 1998 October, pp. 503–511.

[18] Ravi Sandhu, Gail-Hoon Ahn, Decentralized group hierarchies

in UNIX: an experiment and lessons learned, Proceedings of

the 21st NISTNCSC National Conference on Information

Systems Security, 1998 October.

[19] Ravi Sandhu, Gail-Hoon Ahn, Group hierarchies with

decentralized user assignment in Windows NT, Proceedings

of the International Association of Science and Technology

Development Conference on Software Engineering, 1998

October.

[20] Ravi Sandhu, Venkata Bhamidipati, An oracle implementation

of the PRA97 model for permission-role assignment, Proceed-

ings of the 3rd ACM Workshop on Role-Based Access

Control, 1998 October, pp. 13–21.

[21] Ravi Sandhu, Venkata Bhamidipati, Qamar Munawer, The

ARBAC97 model for role-based administration of roles, ACM

Transactions on Information and System Security 2 (1) (1999

February) 105–135.

[22] Kenji Takahashi, Eugene Liang, Analysis and design of Web-

based information systems, Proceedings of the 6th International

World Wide Web Conference, 1997 April, pp. 419–426.

[23] Mariemma I. Yague, Antonio Mana, Javier Lopez, Jose M.

Troya, Applying the semantic web layers to access control,

Proceeding of 14th International Workshop on Database and

Expert Systems Application, 2003 September, pp. 622–626.

[24] Longhua Zhang, Gail-Joon Ahn, Bei-Tseng Chu, A rule-based

framework for role based delegation, Proceedings of the Sixth

ACM Symposium on Access Control Models and Technolo-

gies (SACMAT 2001), 2001 May.

[25] Longhua Zhang, Gail-Joon Ahn, Bei-Tseng Chu, A rule-based

framework for role-based delegation and revocation, ACM

Transactions on Information and System Security 6 (3) (2003

August) 404–441.

[26] Xinwen Zhang, Sejong Oh, Ravi Sandhu, PBDM: a flexible

delegation model in RBAC, Proceedings of the Eighth ACM

Symposium on Access Control Models and Technologies,

2003 June, pp. 149–157.

http://www.AmbySoft.com/mappingObjects.pdf


Eric Jui-Lin Lu received his B.S. degree in

Transportation Engineering and Manage-

ment from National Chiao Tung University,

Taiwan, ROC, in 1982; M.S. degree in

Computer Information Systems from San

Francisco State University, CA, USA, in

1990; and Ph.D. degree in Computer

Science from University of Missouri-Rolla,

MO, USA, in 1996. During 1997–2004, he

was a professor of the Department of

Information Management and had served

as Director of Computer Center and Head of Graduate Institute of

Networking and Communication Engineering at Chaoyang Univer-

sity of Technology, Taiwan, ROC. He is currently a professor of the

department of Computer Science and Information Engineering at

National Changhua University of Education, Taiwan, ROC. His

current research interests include electronic commerce, distributed

processing, and security.

Yi-Hui Chen is currently a Ph.D. student at

the Department of Computer Science and

Information Engineering of National Chung

Chen University. She received the B.M. and

M.S.I.M. degrees in Information Manage-

ment in 1997 and 2004 respectively from

Chaoyang University of Technology, Tai-

chung, Taiwan. Her research interests

include XML, Access Control, Delegation,

and Distributed System.

Documents

A flexible delegation processor for web-based information systems