Access

Rights

Administration

in

Role-Based

Security

Systems

Matunda

Nyanchama

Sylvia

Osborn

The

Department

of

Computer

Science

The

University

of

Western

Ontario

London

Ontario

Canada

FAX

-LRB-519-RRB- 661-3515

email:fmatunda,sylviag@csd.uwo.ca

Abstract

This

paper

examines

the

concept

of

role-based

protection

and

in

particular

role

organization

From

basic

role

relationships

a

model

for

role

organization

is

developed

The

role

graph

model

its

operator

semantics

based

on

graph

theory

and

algorithms

for

role

administration

are

proposed

The

role

graph

model

in

our

view

presents

a

very

generalized

form

of

role

organization

for

access

rights

administration

It

is

shown

how

the

model

simulates

other

organizational

structures

such

as

hierarchies

-LSB-

-RSB-

and

privilege

graphs

-LSB-

-RSB-

Introduction

Role-based

protection

is

a

flexible

means

of

administering

large

numbers

of

system

privileges

especially

for

large

databases

A

privilege

is

a

unit

of

access

to

system

information

A

role

is

a

named

collection

of

such

privileges

-LSB-

-RSB-

User

authorization

to

a

role

grants

the

user

access

to

the

privileges

defined

in

the

role

The

advantage

of

role-based

protection

is

that

it

eases

the

administration

of

privileges

because

of

the

flexibility

with

which

roles

may

be

configured

and

reconfigured

-LSB-

-RSB-

System

security

is

served

further

when

the

role

configuration

process

is

based

on

the

principle

of

least

privilege

in

which

a

role

is

equipped

only

with

sufficient

privileges

to

facilitate

the

intended

duty

requirements

-LSB-

-RSB-

In

an

organization

with

a

large

number

of

diverse

duty

requirements

the

number

of

roles

can

proliferate

as

new

roles

are

defined

to

meet

specific

duty

requirements

Some

roles

can

have

overlapping

functions

-LRB-

hence

overlapping

privileges

-RRB-

while

others

need

not

overlap

The

need

to

have

some

formal

manner

of

tracking

the

distribution

and

administration

of

privileges

is

important

to

ensure

proper

exercise

of

both

responsibility

and

system

security

It

is

important

to

have

a

means

of

formally

expressing

role

relationships

-LCB-

one

which

reflects

the

manner

of

distribution

of

privileges

in

a

system

This

paper

examines

what

we

consider

basic

relationships

that

can

exist

among

roles

in

an

organization

and

their

application

in

modeling

role

organization

Using

these

basic

relationships

as

the

foundation

a

model

for

role

organization

is

proposed

It

is

possible

for

the

privilege

sets

of

two

roles

to

completely

overlap

-LRB-

one

is

a

subset

of

the

other

-RRB-

partially

overlap

-LRB-

have

a

common

subset

-RRB-

or

have

a

common

superset

These

relationships

along

with

the

concepts

of

maximum

and

minimum

privilege

sets

form

the

basis

of

the

role

graph

model

To

demonstrate

the

expressive

power

of

this

model

we

illustrate

how

it

simulates

organizational

structures

such

as

hierarchies

-LSB-

-RSB-

and

privilege

graphs

-LSB-

-RSB-

Appear

in

Database

Security

VIII

Status

Prospects

August

In

the

next

section

we

discuss

the

concepts

of

privileges

roles

and

the

advantages

of

role-based

protection

We

formally

define

the

term

role

as

used

in

this

paper

and

motivate

the

need

for

formal

role

organization

In

section

we

discuss

the

basic

relationships

that

can

exist

among

roles

and

introduce

operators

to

model

these

relationships

We

regard

these

relationships

as

forming

the

basis

of

role

organization

modeling

Section

formally

presents

the

role

graph

model

and

gives

algorithms

for

role

administration

Section

discusses

model

simulation

of

other

role

organizational

structures

Section

contains

the

summary

and

conclusions

Introduction

to

Roles

Basic

Definitions

The

idea

of

a

role

arises

out

of

the

need

to

provide

duty

functionality

which

is

then

authorized

as

a

single

unit

A

role

can

be

seen

as

a

job

office

set

of

actions

of

a

role-holder

a

collection

of

responsibilities

and

functions

or

a

collection

of

privileges

pertaining

to

some

duty

requirements

-LSB-

-RSB-

A

role

exists

as

an

entity

separate

from

the

role

holder

or

role

administrator

It

should

be

equipped

with

sufficient

functionality

to

enable

an

authorized

user

to

achieve

the

duty

requirements

associated

with

the

role

Hence

a

clerical

role

will

be

given

sufficient

access

rights

to

enable

an

authorized

user

or

user

group

to

perform

clerical

duties

Baldwin

-LSB-

-RSB-

terms

these

Named

Protection

Domains

-LRB-

NPDs

-RRB-

Such

a

role

specification

captures

the

responsibilities

rights

and

obligations

associated

with

what

Dobson

and

McDermid

-LSB-

-RSB-

term

a

functional

role

The

other

important

component

of

role

definition

is

its

structural

-LSB-

-RSB-

aspect

which

captures

a

role

's

relationship

with

other

roles

For

purposes

of

this

paper

we

shall

use

the

term

role

to

refer

to

the

functional

aspect

while

the

structural

aspect

of

role

relationships

will

be

captured

by

the

structure

defining

their

relationships

-LCB-

in

our

case

a

role

graph

model

A

role

is

defined

in

terms

of

privileges

A

privilege

on

the

other

hand

is

defined

in

terms

of

access

modes

and

can

be

viewed

as

a

unit

of

access

rights

administration

Definition

Privilege

A

privilege

is

a

pair

-LRB-

x

m

-RRB-

where

x

refers

to

an

object

and

m

is

a

non-empty

set

of

access

modes

for

x.

The

object

referred

to

by

x

can

be

a

protected

data

item

an

object-oriented

-LRB-

O-O

-RRB-

class

definition

or

extent

a

complex

object

a

resource

-LRB-

e.g.

printer

-RRB-

etc.

x

can

be

any

name

or

identifier

which

uniquely

specifies

the

associated

object

m

the

set

of

access

modes

is

composed

of

valid

modes

of

access

to

x.

Its

specification

and

administration

can

be

subjected

to

a

range

of

security

policies

In

systems

with

simple

access

modes

such

as

reads

writes

executes

etc.

m

is

a

subset

of

these

access

modes

In

complex

systems

these

access

modes

can

be

composed

of

a

series

of

or

nested

applications

of

reads

writes

and

executes

Where

x

is

an

object

in

an

O-O

environment

m

would

be

the

execute

mode

of

one

or

more

methods

In

transactional

systems

m

would

be

a

list

of

transactions

that

facilitate

access

to

x

The

exact

nature

of

x

and

m

is

a

matter

of

the

application

environment

and

the

associated

security

policy

-LSB-

-RSB-

Since

privileges

are

intended

for

security

administration

the

security

policy

must

specify

how

they

are

administered

In

our

case

the

initialization

and

modification

of

a

privilege

must

be

authorized

Definition

Role

A

role

is

a

named

set

of

privileges

It

is

a

pair

-LRB-

rname

rpset

-RRB-

where

rname

is

the

role

name

and

rpset

is

the

privilege

set

A

role

's

name

rname

uniquely

identifies

a

role

in

a

system

We

use

dot

notation

to

refer

to

a

role

's

name

and

privilege

set

Thus

for

a

given

role

r

r.rname

and

r.rpset

refer

to

the

name

of

the

role

and

its

privilege

set

respectively

Let

PV

denote

the

universal

set

of

privileges

in

a

given

system

and

R

the

universal

set

of

roles

We

also

define

a

function

R

PV

which

enumerates

the

privileges

of

a

given

role

so

that

for

every

r

R

-LRB-

r

-RRB-

pvng

r

rpset

Strengths

of

Role-Based

Protection

Role-based

protection

offers

flexibility

in

system

privilege

administration

-LSB-

-RSB-

User

access

rights

can

be

varied

either

by

explicit

authorization

-LRB-

or

revocation

of

authorization

-RRB-

of

a

user

to

a

role

or

by

indirectly

varying

the

role

privilege

set

Further

advantage

is

gained

if

users

are

organized

into

groups

such

that

authorizations

are

given

to

groups

as

opposed

to

individuals

Given

that

system

privileges

can

be

very

fine-grained

roles

offer

a

means

of

managing

them

incrementally

Considering

the

manner

in

which

privileges

can

be

assigned/revoked

to/from

a

given

role

this

method

approaches

a

continuum

in

system

privilege

administration

-LSB-

-RSB-

A

related

advantage

is

that

role-based

protection

can

be

used

to

enforce

the

principle

of

least

privilege

where

a

role

is

defined

to

have

only

the

necessary

functionality

required

for

the

associated

duties

-LSB-

-RSB-

This

approach

offers

a

simplification

of

the

complexity

of

system

privilege

management

With

a

suitable

organizational

framework

capturing

role

relationships

it

is

possible

to

analyze

the

implications

of

given

authorizations

Moreover

such

a

formal

framework

lends

itself

to

the

development

of

analytical

tools

It

is

also

possible

that

management

tools

for

access

rights

administration

can

be

used

in

role

management

Given

that

role-based

protection

is

designed

with

a

given

application

in

mind

this

method

provides

a

chance

for

incorporation

of

application

level

security

constraints

and

semantics

-LSB-

-RSB-

An

associated

advantage

is

that

roles

allow

for

multidirectional

information

flow

policies

-LSB-

-RSB-

unlike

such

models

as

Denning

's

lattice

model

-LSB-

-RSB-

and

Bell

and

LaPadula

's

-LSB-

-RSB-

multilevel

model

As

well

unlike

these

traditional

models

which

specify

what

information

flows

should

not

take

place

role-based

protection

affirms

which

information

flows

can

take

place

-LSB-

-RSB-

Roles

Access

Rights

Administration

Roles

act

as

gateways

to

system

information

The

privilege

set

of

a

given

role

determines

what

information

is

available

via

the

role

One

advantage

of

role-based

protection

mentioned

in

the

previous

section

is

that

access

to

system

information

is

accomplished

at

two

levels

via

explicit

authorization

to

a

role

or

via

inclusion

of

some

privilege

in

a

role

We

term

the

former

user-role

authorization

while

the

latter

is

termed

role-privilege

authorization

-LRB-

see

figure

-RRB-

A

third

form

of

authorization

is

role-role

authorization

-LSB-

-RSB-

in

which

one

role

is

authorized

another

's

privileges

We

address

each

of

these

in

turn

In

user-role

authorization

a

user/group

is

authorized

access

to

system

privileges

available

via

the

role

Such

authorization

must

be

specified

in

a

role

's

access

control

list

For

each

role

such

an

access

control

list

contains

the

user

identifier

for

each

user

authorized

to

the

role

Let

UID

be

the

set

of

all

user

identifiers

and

GID

the

set

of

all

group

identifiers

ID

UID

-LSB-

GID

Definition

Access

Control

List

A

role

access

control

list

-LRB-

racl

-RRB-

is

of

the

form

-LSB-

idn

-RSB-

where

idi

ID

User-Role

Authorization

Role-Role

Authorization

Role-Privilege

Authorization

Roles

Resources

Users/Groups

Figure

Three

Kinds

of

Authorizations

In

a

secure

system

all

roles

must

have

access

control

lists

i.e.

R

r.racl

-LSB-

idi

-RSB-

A

role

with

an

associated

access

control

list

is

called

a

secure

role

Definition

Secure

Role

A

secure

role

is

a

named

collection

of

privileges

along

with

its

access

control

list

It

is

a

triple

-LRB-

rname

rpset

racl

-RRB-

where

rname

is

the

role

name

rpset

is

its

privilege

set

and

racl

is

its

access

control

list

Role-privilege

authorization

involves

role

configuration

in

which

a

privilege

is

added

to

the

role

's

privilege

set

Role-role

authorization

-LSB-

-RSB-

forms

the

third

kind

of

authorization

If

a

role

A

is

authorized

to

access

a

role

B

it

means

that

all

of

B

's

access

rights

are

available

via

role

A

In

other

words

B

's

privileges

are

a

proper

subset

of

the

privileges

of

A.

Role-role

authorization

is

an

aspect

of

role

structure

Example

Suppose

we

have

two

roles

clerk

and

supervisor

in

which

the

supervisor

role

has

a

role

authorization

to

the

clerk

role

This

means

that

the

clerk

's

access

rights

are

available

to

the

supervisor

A

user

authorized

to

the

supervisor

role

can

perform

whatever

a

user

authorized

to

the

clerk

role

can

do

We

can

view

the

privilege

relationships

between

the

two

roles

as

-LRB-

clerk

-RRB-

-LRB-

supervisor

-RRB-

This

paper

examines

role-role

authorizations

which

define

role

relationships

These

have

implications

on

role

organization

and

access

rights

administration

Role-role

authorizations

can

be

complex

To

capture

the

role-relationships

completely

and

be

able

to

carry

out

an

analysis

of

the

implications

of

privilege

assignment

and

distribution

in

a

system

can

be

very

complex

without

some

formal

organizational

structure

Complexity

of

analysis

of

system

privilege

distribution

is

one

short-coming

of

role-based

protection

-LSB-

-RSB-

Baldwin

's

approach

to

access

rights

administration

uses

privilege

graphs

-LRB-

PG

-RRB-

which

capture

functionality

structure

and

authorizations

A

PG

-LRB-

figure

-RRB-

is

an

acyclic

graph

with

three

types

of

nodes

functionality

role

and

user/group

A

path

from

a

given

user

node

to

a

functionality

node

means

that

the

user

is

authorized

to

execute

the

functionality

The

of

duty

-LSB-

-RSB-

on

the

other

hand

ensures

that

the

supervisor

does

not

perform

both

roles

Functionality

Users/Groups

Roles

Accounts

Supervisor

Accounts

Clerk

Receipts

Supervisor

Receipts

Clerk

Clerk

Orders

Cl

erk

Enter

Accounts

Compile

Orders

Make

Receipts

Figure

Baldwin

's

Privilege

Graph

access

rights

available

to

such

a

user

are

all

the

privileges

specified

in

roles

on

any

such

path

Ting

et

al.

's

-LSB-

-RSB-

approach

utilizes

hierarchical

ordering

of

roles

in

which

for

any

given

roles

in

a

path

those

lower

in

the

hierarchy

have

lower

functionality

than

those

high

in

the

hierarchy

In

general

the

path

captures

a

subsetting

relationship

between

the

roles

such

that

for

a

given

directed

edge

hvi

vji

-LRB-

vj

-RRB-

-LRB-

vi

-RRB-

Both

of

these

structures

have

what

we

term

the

acyclicity

property

Definition

Acyclicity

Property

A

role

organization

structure

is

said

to

have

the

acyclicity

property

if

in

a

graph

of

the

role

relationships

with

the

roles

as

nodes

we

have

a

directed

edge

hri

rji

whenever

-LRB-

ri

-RRB-

-LRB-

rj

-RRB-

and

the

graph

is

acyclic

Property

Role

Organization

Structure

Acyclicity

A

role

organization

must

preserve

the

acyclicity

property

in

order

to

offer

differentiated

access

to

system

information

via

role-based

protection

techniques

Modeling

Role

Organization

A

role

is

a

collection

of

privileges

which

facilitates

the

execution

of

some

functionality

for

an

authorized

user

Roles

in

a

system

can

have

different

kinds

of

relationships

among

them

based

on

their

associated

functionalities

and

organizational

constraints

Thus

it

is

important

to

develop

some

formal

organizational

framework

which

expresses

desirable

properties

for

an

enterprise

whose

security

is

being

enforced

and

in

the

process

captures

the

relationships

among

roles

Such

a

framework

will

facilitate

the

analysis

of

privilege

distribution

and

sharing

In

this

section

we

discuss

and

model

basic

role

relationships

which

form

the

basis

of

a

role

organization

framework

We

start

with

relationships

between

two

roles

and

introduce

the

concepts

of

the

minimum

and

maximum

privilege

sets

in

a

role-based

system

and

their

relationship

with

other

roles

Finally

we

combine

these

concepts

to

yield

a

framework

for

role

organization

A

B

R

P

Q

Z

Z

X

X

Y

Y

B

A

P

Q

Z

Y

X

R

-LRB-

b

-RRB-

-LRB-

c

-RRB-

-LRB-

a

-RRB-

Partial

Privileges

Common

Privileges

Augmented

Privileges

Figure

Three

Kinds

of

Basic

Role

Relationships

Basic

Role

Relationships

We

identify

three

kinds

of

basic

relationships

junior-senior

common

junior

and

common

senior

The

junior-senior

relationship

expressed

as

junior!senior

captures

the

fact

that

the

senior

role

's

privileges

include

those

of

the

junior

one

A

role

is

a

common

junior

of

two

other

roles

if

it

shares

some

privileges

with

both

of

these

senior

roles

A

role

which

encompasses

all

of

the

privileges

of

two

junior

roles

is

called

a

common

senior

to

these

roles

Figure

shows

these

three

possibilities

with

Venn

diagrams

over

the

associated

privileges

In

all

cases

there

is

privilege

and

functionality

sharing

between

two

roles

Partial

Privileges

With

partial

privilege

sharing

privileges

defined

in

one

role

are

a

complete

subset

of

privileges

in

another

role

This

implies

shared

functionality

via

the

shared

privileges

For

instance

the

clerk

and

supervisor

roles

in

example

share

the

functionality

associated

with

the

clerk

role

i.e.

a

user

authorized

to

the

supervisor

role

can

execute

the

functionalities

associated

with

both

roles

-LRB-

figure

-RRB-

We

model

such

direct

functionality

and

privilege

sharing

using

the

is-junior

relationship

denoted

by

In

our

example

clerk!supervisor

In

general

given

two

roles

ri

rj

R

with

ri

rj

we

have

the

following

interpretation

ri

and

rj

are

junior

-LRB-

subservient

-RRB-

and

senior

-LRB-

superior

-RRB-

roles

respectively

Moreover

ri

's

privileges

and

functionality

are

available

to

rj

Hence

-LRB-

ri

-RRB-

-LRB-

rj

-RRB-

We

say

ri

's

privileges

are

indirectly

available

to

rj

Definition

is-junior

relationship

-LRB-

-RRB-

An

is-junior

relationship

exists

between

two

roles

ri

and

rj

denoted

ri

rj

if

and

only

if

-LRB-

ri

-RRB-

-LRB-

rj

-RRB-

The

is-junior

relationship

can

be

seen

as

a

role-role

authorization

in

which

the

superior

role

is

authorized

to

the

privileges

of

the

junior

role

If

we

consider

relative

authority

as

a

measure

of

the

privileges

associated

with

a

role

then

the

is-junior

relationship

can

be

seen

as

specifying

which

of

the

two

roles

has

a

higher

authority

than

the

other

In

our

case

the

junior

role

exercises

less

authority

than

the

superior

one

Moreover

the

is-junior

relationship

can

be

seen

as

specifying

the

flow

of

authority

in

which

the

senior

role

exercises

more

authority

than

the

junior

one

Further

for

this

authority

to

be

meaningful

this

relationship

must

be

acyclic

it

must

preserve

property

Common

Privileges

Another

form

of

relationship

between

two

roles

is

where

there

is

privilege

sharing

in

which

roles

have

a

non-empty

intersection

of

their

privilege

sets

but

with

neither

of

the

sets

being

a

subset

nor

a

superset

of

the

other

Such

a

relationship

can

be

used

to

express

an

overlap

of

responsibility

-LRB-

figure

-RRB-

If

there

exists

a

role

defined

whose

privilege

set

is

some

or

all

of

this

intersection

then

we

say

such

a

role

is

a

common-junior

of

the

other

two

roles

We

denote

the

commonjunior

relationship

by

In

general

ri

rj

is

not

unique

Suppose

we

have

roles

A

B

and

C

related

as

C

A

B.

Suppose

the

privilege

sets

associated

with

A

and

B

are

-LRB-

A

-RRB-

g

and

-LRB-

B

-RRB-

g

respectively

-LRB-

C

-RRB-

must

be

a

common

subset

of

both

-LRB-

A

-RRB-

and

-LRB-

B

-RRB-

i.e.

-LRB-

C

-RRB-

-LRB-

-LRB-

A

-RRB-

-LRB-

B

-RRB-

-RRB-

In

general

given

three

roles

ri

rj

rk

R

and

rk

ri

rj

we

have

the

following

interpretation

both

ri

and

rj

are

senior

-LRB-

superior

-RRB-

roles

to

rk

Moreover

rk

's

privileges

and

functionality

are

indirectly

available

to

both

ri

and

rj

Hence

-LRB-

rk

-RRB-

-LRB-

ri

-RRB-

and

-LRB-

rk

-RRB-

-LRB-

rj

-RRB-

Definition

common-junior

relationship

-LRB-

-RRB-

Given

roles

ri

and

rj

ri

rj

is

all

rk

such

that

-LRB-

rk

-RRB-

-LRB-

-LRB-

ri

-RRB-

-LRB-

rj

-RRB-

-RRB-

Privilege

Augmentation

Another

important

consideration

is

privilege

augmentation

In

analyzing

privilege

distribution

it

may

be

necessary

to

find

a

role

that

embodies

the

functionality

and

privileges

of

two

given

roles

Such

a

role

's

privileges

will

be

a

superset

of

both

given

roles

-LRB-

figure

-RRB-

The

relationship

in

such

a

case

is

termed

common-senior

and

is

denoted

by

In

general

ri

rj

is

not

unique

Suppose

we

have

roles

X

Y

and

Z

related

as

Z

X?Y

Let

-LRB-

X

-RRB-

g

and

-LRB-

Y

-RRB-

g.

For

Z

's

privileges

to

be

a

common

superset

of

those

of

X

and

Y

we

must

have

-LRB-

-LRB-

X

-RRB-

-LSB-

-LRB-

Y

-RRB-

-RRB-

-LRB-

Z

-RRB-

i.e.

g

-LRB-

Z

-RRB-

Given

three

roles

ri

rj

rk

R

and

rk

ri

rj

we

have

the

following

interpretation

both

ri

and

rj

are

junior

-LRB-

subservient

-RRB-

roles

to

rk

Moreover

both

ri

's

and

rj

's

privileges

and

functionalities

are

indirectly

available

to

rk

Hence

-LRB-

ri

-RRB-

-LRB-

rk

-RRB-

and

-LRB-

rj

-RRB-

-LRB-

rk

-RRB-

Definition

common-senior

relationship

-LRB-

-RRB-

Given

roles

ri

and

rj

ri

rj

is

all

rk

such

that

-LRB-

-LRB-

ri

-RRB-

-LSB-

-LRB-

rj

-RRB-

-RRB-

-LRB-

rk

-RRB-

The

foregoing

relationships

can

be

extended

to

cater

for

more

than

two

roles

Partial

Privilege

Sharing

From

the

definition

of

the

is-junior

relationship

if

-LRB-

ri

rj

-RRB-

and

-LRB-

rj

rk

-RRB-

then

it

must

also

be

true

that

ri

rk

since

-LRB-

-LRB-

ri

-RRB-

-LRB-

rj

-RRB-

-RRB-

-LRB-

-LRB-

rj

-RRB-

-LRB-

rk

-RRB-

-RRB-

-RRB-

-LRB-

-LRB-

ri

-RRB-

-LRB-

rk

-RRB-

-RRB-

This

then

captures

the

transitive

property

of

the

is-junior

relationship

In

general

if

we

have

a

role

relationship

of

the

form

ri

ri

ri

n

n

it

follows

that

-LRB-

ri

-RRB-

-LRB-

ri

-RRB-

-LRB-

ri

n

-RRB-

This

captures

the

monotonic

increasing

property

of

the

privilege

function

for

roles

related

via

the

is-junior

relationship

Property

The

privilege

function

increases

monotonically

with

respect

to

the

isjunior

-LRB-

-RRB-

relationship

We

denote

ri

ri

ri

n

rj

by

ri

rj

for

n

and

ri

rj

for

n

This

leads

to

the

concept

of

a

path

Definition

Role

Path

A

role

path

p

between

two

roles

ri

and

rj

is

of

the

form

ri

rj

A

trivial

path

exists

between

a

role

and

itself

Other

properties

of

the

is-junior

relationship

include

reflexivity

and

antisymmetry

Given

roles

ri

and

rj

we

have

ri

ri

-LRB-

reflexivity

-RRB-

since

-LRB-

ri

-RRB-

-LRB-

ri

-RRB-

As

well

-LRB-

-LRB-

ri

rj

-RRB-

-LRB-

rj

ri

-RRB-

-RRB-

-RRB-

ri

rj

This

follows

from

the

observation

that

-LRB-

ri

rj

-RRB-

-RRB-

-LRB-

ri

-RRB-

-LRB-

rj

-RRB-

and

-LRB-

rj

ri

-RRB-

-RRB-

-LRB-

rj

-RRB-

-LRB-

ri

-RRB-

With

-LRB-

ri

-RRB-

-LRB-

rj

-RRB-

and

-LRB-

rj

-RRB-

-LRB-

ri

-RRB-

and

by

the

acyclicity

property

it

follows

that

-LRB-

ri

-RRB-

-LRB-

rj

-RRB-

which

implies

ri

rj

This

is

the

basis

of

the

following

property

Property

Role

Privilege

Set

Uniqueness

A

Role

's

privilege

set

must

be

unique

Common

Privileges

From

the

common-junior

-LRB-

-RRB-

relationship

above

observe

that

the

common

subset

of

two

roles

need

not

be

an

immediate

junior

role

of

both

roles

in

question

The

following

lemma

expresses

the

relationship

between

the

is-junior

and

the

common-junior

operators

and

respectively

Lemma

If

rk

ri

rj

then

rk

ri

and

rk

rj

The

common-junior

operator

-LRB-

-RRB-

is

commutative

associative

and

reflexive

i.e.

ri

rj

rj

ri

ri

-LRB-

rj

rk

-RRB-

-LRB-

ri

rj

-RRB-

rk

and

ri

ri

is

defined

and

includes

ri

Privilege

Augmentation

As

with

the

common-junior

relationship

the

common-senior

relationship

need

not

involve

immediate

superiors

of

the

role

under

consideration

The

following

lemma

captures

the

relationship

between

the

two

operators

and

Lemma

If

rk

ri

rj

then

ri

rk

and

rj

rk

The

operation

is

commutative

associative

and

reflexive

i.e.

ri

rj

rj

ri

ri

-LRB-

rj

rk

-RRB-

-LRB-

ri

rj

-RRB-

rk

and

ri

ri

is

defined

and

includes

ri

The

Concepts

of

Minimum

and

Maximum

Privilege

Sets

It

is

possible

that

an

organization

provides

a

minimum

set

of

privileges

available

to

every

user

Such

a

basic

privilege

set

for

instance

can

be

things

like

the

ability/permission

to

log

onto

a

computer

system

the

privilege

to

get

into

certain

areas

of

an

organization

's

premises

etc.

In

general

this

minimum

privilege

set

represents

the

very

minimum

that

any

valid

user

can

be

authorized

to

Since

users

are

authorized

to

specific

roles

it

is

possible

to

organize

such

a

basic

set

of

privileges

into

a

role

such

that

they

are

available

via

explicit

authorization

or

via

role

relationships

with

other

roles

We

denote

the

role

with

the

basic

privilege

set

MinRole

In

general

depending

on

a

particular

organization

MinRole

's

privilege

set

can

be

empty

-LRB-

MinRole

-RRB-

-LRB-

Minimum

mandatory

privilege

set

if

defined

otherwise

For

all

r

R

MinRole

r

holds

Property

Minimum

Privilege

Property

MinRole

is

always

defined

With

the

introduction

of

MinRole

there

is

always

at

least

one

common-junior

for

all

roles

namely

MinRole

As

with

MinRole

we

envisage

MaxRole

some

system

chief

executive

role

which

embodies

the

collection

of

all

privileges

in

a

given

system

Theoretically

a

user

authorized

to

MaxRole

can

execute

any

functionality

using

the

associated

privileges

in

whatever

role

they

are

specified

Unlike

-LRB-

MinRole

-RRB-

which

can

be

empty

-LRB-

MaxRole

-RRB-

can

never

be

empty

if

the

system

is

intended

to

accomplish

anything

at

all

-LRB-

MaxRole

-RRB-

-LSB-

-LRB-

r

-RRB-

For

all

r

R

r

MaxRole

holds

Property

Maximum

Privilege

Property

MaxRole

is

always

defined

With

the

introduction

of

MaxRole

there

is

always

at

least

one

common-senior

for

two

roles

namely

MaxRole

The

is-junior

common-junior

and

common-senior

relationships

introduced

in

the

previous

section

capture

all

manner

of

relationships

that

can

be

used

to

associate

two

or

more

roles

when

there

is

need

for

analysis

of

their

interaction

MinRole

and

MaxRole

express

the

concepts

of

minimum

mandatory

and

maximum

privilege

sets

respectively

in

a

system

Combining

these

yields

representations

such

as

those

in

figure

For

the

purposes

of

security

and

the

need

for

dispersion

of

powers

MaxRole

may

not

be

authorized

to

any

one

individual

in

an

organization

In

an

ideal

situation

MaxRole

conceptually

corresponds

with

the

role

of

a

Chief

Executive

in

an

organization

It

is

unlikely

that

an

administrative

or

a

security

policy

would

advocate

such

singular

exercise

of

powers

Moreover

there

is

a

very

realistic

risk

that

allowing

exercise

of

privileges

of

MaxRole

can

compromise

the

system

However

such

problems

need

not

arise

if

we

make

the

exception

that

no

single

user

can

exercise

the

privileges

of

MaxRole

This

will

make

MaxRole

a

nonexecutable

role

Other

policies

may

choose

a

collective

execution

of

the

role

e.g.

by

a

number

of

votes

of

authorized

users

Whatever

the

case

authorization

to

MaxRole

with

be

a

matter

of

a

specific

security

policy

MaxRole

in

our

modeling

is

useful

for

purposes

of

completeness

It

ensures

that

every

two

roles

in

the

system

have

a

common-senior

just

as

MinRole

ensures

that

every

two

roles

have

a

common-junior

-LRB-

a

-RRB-

-LRB-

b

-RRB-

-LRB-

e

-RRB-

-LRB-

f

-RRB-

-LRB-

g

-RRB-

-LRB-

d

-RRB-

-LRB-

c

-RRB-

A

A

B

A

B

A

B

C

D

E

A

B

C

D

E

A

B

C

D

E

A

B

C

D

E

MinRoleMinRole

MinRole

MaxRole

MaxRole

MinRole

MaxRoleMaxRole

MinRole

MinRole

MaxRole

MaxRole

MinRole

MaxRole

Figure

Different

Forms

of

Role

Organization

A

Role

Graph

Model

for

Role

Organization

The

basic

role

relationships

discussed

in

section

point

to

an

acyclic

role

graph

organization

for

roles

In

this

section

we

develop

the

modeling

further

using

graph

theory

We

present

a

role

graph

model

for

role

organization

and

develop

algorithms

for

the

management

of

roles

and

their

relationships

The

Model

Informally

To

minimize

the

task

of

enumerating

the

privileges

of

each

role

we

organize

them

using

the

concepts

introduced

in

section

which

incorporate

acyclicity

of

the

role

graph

structure

and

the

monotonicity

of

role

privileges

for

any

path

Such

a

structure

along

with

rules

for

role

ordering

and

determining

the

privileges

associated

with

a

role

facilitate

a

simple

yet

elegant

organization

of

roles

to

reflect

the

attached

to

each

role

Role

ordering

and

role

inter-relationships

in

turn

offer

a

means

of

distributing

privileges

among

the

roles

The

idea

is

that

we

explicitly

assign

a

privilege

at

the

lowest

point

in

the

role

graph

where

it

is

desirable

Since

our

formulation

specifies

that

high

order

roles

can

execute

the

privileges

of

the

lower

order

ones

with

a

connecting

path

we

can

make

the

least

number

of

explicit

privilege

assignments

that

would

facilitate

the

desired

distribution

From

the

ordering

we

define

authority

paths

that

are

linear

-LRB-

total

-RRB-

orders

of

roles

according

to

increasing

authority

connected

by

the

is-junior

-LRB-

-RRB-

relationship

which

can

be

seen

to

be

specifying

the

flow

of

authority

In

essence

the

ordering

asserts

the

fact

that

higher

authority

roles

have

access

to

more

privileges

than

lower

ordered

ones

in

any

given

path

The

effective

privileges

associated

with

a

role

result

from

those

privileges

directly

associated

with

the

role

and

those

indirectly

associated

with

it

The

former

are

those

privileges

explicitly

specified

in

the

role

while

the

latter

are

those

privileges

specified

in

lower

order

roles

connected

by

a

path

to

the

role

The

Role

Graph

Model

Formally

This

section

presents

the

formal

organization

of

roles

into

a

role

graph

RG

-LRB-

R

-RRB-

as

shown

in

figure

The

nodes

of

the

graph

correspond

to

the

roles

given

and

include

MaxRole

and

use

of

this

term

will

become

clear

as

we

advance

Supervisor

MinRole

Chief

Executive

MaxRole

Senior

Manager

Manager

Clerk

Ordinary

Employee

Figure

Example

of

Role

Graph

MinRole

R

rn

MaxRole

MinRoleg

The

edges

are

defined

by

the

is-junior

relationship

Note

that

by

the

definition

of

privileges

for

MaxRole

and

MinRole

and

the

definition

of

is-junior

there

is

an

edge

from

MinRole

to

every

ri

and

an

edge

from

every

ri

to

MaxRole

The

common-junior

and

common-senior

relationships

-LRB-

and

-RRB-

still

have

the

same

meaning

as

previously

Note

that

if

a

system

administrator

is

specifying

roles

it

is

possible

that

the

privileges

are

specified

in

a

highly

redundant

fashion

In

other

words

rather

than

specifying

the

minimum

set

of

direct

privileges

for

a

role

some

indirect

privileges

might

be

given

as

being

direct

privileges

The

function

-LRB-

r

-RRB-

returns

the

set

of

all

direct

and

indirect

privileges

of

a

role

which

we

also

call

the

effective

privileges

The

version

of

the

graph

which

we

will

present

to

the

role

administrator

should

neither

have

redundant

privilege

specifications

nor

redundant

is-junior

relationships

-LRB-

i.e.

redundant

graph

edges

-RRB-

in

order

to

highlight

the

true

nature

of

the

role

relationships

We

will

further

explain

this

reduced

form

of

the

graph

shortly

Paths

in

the

role

graph

not

involving

MaxRole

and

MinRole

are

of

more

interest

to

us

Consequently

we

shall

use

the

following

role

graph

path

definition

in

the

subsequent

sections

Definition

Role

Graph

Path

A

role

graph

path

p

is

of

the

form

ri

ri

ri

n

rj

n

such

that

ri

MinRole

rj

MaxRole

The

quadruple

-LRB-

R

-RRB-

which

includes

MaxRole

and

MinRole

specifies

an

authority

structure

for

roles

For

any

role

graph

path

of

the

form

ri

rn

n

we

have

an

authority

relation

of

the

form

rn

with

the

authority

embodied

in

the

roles

on

a

path

totally

ordered

In

general

given

any

two

roles

or

they

are

incomparable

Where

there

is

a

path

-LRB-

call

it

an

authority

flow

path

-RRB-

the

roles

in

the

path

form

a

total

order

Definition

Path

Role

Set

The

role

set

of

a

given

path

denoted

by

-LRB-

p

-RRB-

is

the

set

of

all

roles

that

compose

the

path

We

say

that

a

given

role

participates

in

a

path

if

it

belongs

to

the

path

's

role

set

-LCB-

-RCB-

F

G

H

-LCB-

-RCB-

-LCB-

-RCB-

-LCB-

-RCB-

D

-LCB-

-RCB-

C

-LCB-

-RCB-

-LCB-

-RCB-

B

-LCB-

-RCB-

A

E

I

-LCB-

-RCB-

-LCB-

-RCB-

MinRole

MaxRole

Figure

Role

Graph

with

Privileges

Privilege

Distribution

Table

For

Figure

Role

Name

Direct

-LRB-

D

-RRB-

Indirect

-LRB-

I

-RRB-

Effective

-LRB-

D

-LSB-

I

-RRB-

A

f

g

B

f

g

C

f

g

D

f

g

E

g

g

F

g

G

g

g

H

g

g

g

I

g

g

g

Table

Table

of

Privileges

We

extend

the

function

to

paths

as

follows

for

a

path

p

-LRB-

-LRB-

p

-RRB-

-RRB-

S

-LRB-

ri

-RRB-

Definition

Path

Independence

Let

pi

and

pj

be

two

paths

in

a

role

graph

We

say

pi

is

independent

of

pj

if

-LRB-

-LRB-

pi

-RRB-

-RRB-

-LRB-

-LRB-

pj

-RRB-

-RRB-

-LRB-

MinRole

-RRB-

In

other

words

the

two

role

sets

are

related

only

via

MaxRole

and

MinRole

Such

independence

can

be

exploited

to

prohibit

privilege

sharing

by

ensuring

that

the

privilege

sets

of

two

independent

paths

are

disjoint

Example

Consider

figure

where

we

have

distinct

privileges

numbered

with

privileges

directly

assigned

to

roles

A

F

and

assigned

roles

G

H

I

respectively

We

have

a

role

graph

specification

as

follows

A

E

B

E

C

F

D

G

E

fH

Ig

fF

Gg

I

MaxRole

H

I

and

MinRole

A

B

C

D

with

-LRB-

MinRole

-RRB-

From

this

we

can

compute

the

privileges

of

various

roles

and

obtain

the

privileges

distribution

as

in

table

Moreover

we

have

the

following

relationships

relating

to

the

operators

The

common-junior

operator

defines

a

common

subset

of

privileges

for

any

two

roles

Consider

E

H

I

and

note

that

-LRB-

H

I

-RRB-

-LRB-

E

-RRB-

-LRB-

H

-RRB-

-LRB-

I

-RRB-

The

common-senior

operator

defines

the

union

of

privileges

of

two

roles

and

as

such

is

a

common

superset

for

any

two

roles

Consider

I

F

G

and

note

that

-LRB-

F

G

-RRB-

-LRB-

F

-RRB-

-LSB-

-LRB-

G

-RRB-

-LRB-

I

-RRB-

The

is-junior

operator

defines

a

proper

subset

relationship

between

two

roles

e.g.

E!H

Note

that

-LRB-

E

-RRB-

ae

This

is

true

for

all

roles

related

via

the

is-junior

relationship

Paths

A!E!H

and

C

F

are

independent

paths

since

their

roles

sets

fA

E

Hg

and

fC

Fg

are

mutually

exclusive

and

the

two

paths

are

related

via

only

via

MaxRole

and

MinRole

The

role

graph

in

figure

shows

only

direct

-LRB-

non-redundant

-RRB-

privileges

for

each

node

and

has

no

redundant

edges

Specifying

a

role

's

direct

privileges

and

its

is-junior

relationships

with

other

roles

completely

specify

its

effective

privileges

Definition

Direct

Privileges

Let

Direct

-LRB-

r

-RRB-

denote

the

direct

privileges

of

a

role

i.e.

Direct

-LRB-

r

-RRB-

-LRB-

r

-RRB-

such

that

for

all

ri

r

-LRB-

ri

-RRB-

Direct

-LRB-

r

-RRB-

For

the

purpose

of

the

algorithms

below

assume

that

for

each

role

in

a

role

graph

we

keep

Direct

-LRB-

r

-RRB-

and

is-junior

relationships

By

the

definition

of

is-junior

the

edge

set

in

the

role

graph

will

in

fact

be

highly

redundant

What

we

want

to

present

to

the

role

administrator

and

maintain

is

the

transitive

reduction

of

the

graph

-LSB-

-RSB-

The

transitive

reduction

of

an

acyclic

graph

is

a

graph

in

which

there

are

no

edges

ri

rj

whenever

there

is

a

path

ri

rj

in

the

graph

Inputs

to

and

outputs

of

the

algorithms

assume

well-formed

graphs

Definition

Role

Graph

Well-Formedness

A

role

graph

is

well-formed

if

it

is

a

transitive

reduction

and

if

the

direct

privilege

set

associated

with

each

role

r

conforms

to

the

definition

of

Direct

-LRB-

r

-RRB-

By

the

original

definition

of

the

edge

set

-LRB-

based

in

turn

on

the

is-junior

relationship

which

depends

on

the

effective

privilege

sets

of

nodes

-RRB-

a

path

ri

rj

exists

in

the

well-formed

role

graph

whenever

-LRB-

ri

-RRB-

-LRB-

rj

-RRB-

The

following

terms

will

be

useful

in

the

algorithms

to

be

presented

below

Definition

Juniors

-LRB-

r

-RRB-

The

set

of

Junior

roles

for

a

given

role

r

is

all

ri

such

that

ri

r.

Definition

Seniors

-LRB-

r

-RRB-

The

set

of

Senior

roles

for

a

given

role

r

is

all

rj

such

that

r

rj

Constraint

Role

Graph

Privilege

Set

Invariant

Constraint

The

effective

privilege

set

of

every

role

in

a

role

graph

remains

invariant

unless

altered

by

the

system

security

officer

SSO

The

SSO

exercises

privileges

like

any

other

system

user

by

executing

in

an

authorized

security

administration

role

This

can

be

seen

as

the

security

information

administration

role

However

care

must

be

taken

to

ensure

there

is

no

conflict

of

interest

Hence

no

one

user

whether

SSO

or

not

should

be

able

to

administer

security

information

pertaining

to

one

's

access

rights

Role

Graph

Maintenance

Algorithms

We

are

now

ready

to

introduce

some

algorithms

to

assist

a

role

administrator

in

specifying

and

modifying

a

collection

of

roles

These

will

ultimately

be

incorporated

in

a

role

maintenance

tool

Our

goal

is

to

have

all

the

operations

map

a

well-formed

role

graph

to

another

well-formed

role

graph

We

assume

that

the

administrator

begins

with

a

graph

containing

only

MaxRole

and

MinRole

Any

direct

privileges

defined

for

MinRole

can

be

specified

at

this

time

The

role

graph

can

be

expanded

at

any

point

by

adding

new

roles

as

need

may

arise

while

retaining

the

role

graph

structure

This

strategy

offers

a

flexible

manner

of

introducing

new

privileges

into

the

role

graph

Such

privileges

can

be

incorporated

into

an

existing

role

graph

by

introduction

of

new

roles

or

by

increasing

the

privileges

of

existing

ones

New

roles

can

be

introduced

by

the

addition

of

completely

new

roles

or

by

partitioning

existing

roles

either

horizontally

or

vertically

We

also

consider

role

deletion

In

all

these

cases

we

can

have

an

increment

or

decrement

in

the

overall

privileges

associated

with

paths

in

which

the

affected

role

participates

Such

privileges

can

remain

invariant

be

reduced

or

be

increased

depending

on

the

operation

Given

the

space

constraints

here

we

address

the

cases

where

-LRB-

-RRB-

path

privileges

are

introduced

with

the

addition

of

a

new

role

-LRB-

-RRB-

path

privileges

may

or

may

not

remain

invariant

with

the

deletion

of

a

role

-LRB-

-RRB-

path

privileges

are

partitioned

with

the

horizontal

partition

of

a

role

and

-LRB-

-RRB-

privileges

remain

invariant

with

the

vertical

partition

of

a

role

Consequently

after

carrying

out

the

operations

on

the

graph

our

procedures

will

confine

themselves

with

the

immediate

neighbourhood

of

the

target

role

In

other

words

we

look

for

redundant

arcs

generated

due

to

the

operation

in

question

This

involves

the

immediate

senior

and

immediate

junior

role

sets

of

the

roles

affected

by

the

operations

Role

Addition

Deletion

By

role

addition

we

mean

the

creation

and

incorporation

of

a

totally

new

role

into

the

role

graph

Such

a

role

is

defined

-LRB-

name

and

privilege

set

-RRB-

before

being

integrated

into

the

role

graph

While

the

integration

process

must

preserve

the

role

definition

it

is

important

to

ensure

that

if

there

are

privileges

defined

in

the

new

role

that

exist

in

junior

roles

in

the

target

paths

they

must

be

removed

to

take

away

the

redundancy

To

introduce

such

a

role

requires

the

specification

of

the

target

paths

and

the

position

in

the

paths

This

involves

the

specification

of

the

target

superior

and

junior

role

-LRB-

s

-RRB-

for

the

role

to

be

added

-LRB-

see

figure

-RRB-

D

D

E

b

c

a

A

AB

B

C

CC

A

B

X

X

E

E

Target

Junior

and

Senior

Insert

Role

Eliminate

Redundant

Arcs

D

Figure

Role

Addition

The

role

to

be

inserted

is

added

to

the

node

set

of

the

graph

and

the

appropriate

edges

are

created

to

indicate

the

immediate

junior

and

superior

roles

It

is

possible

that

a

node

already

exists

with

the

same

effective

privilege

set

Once

this

possibility

has

been

eliminated

redundant

paths

are

removed

from

the

resulting

structure

Finally

privilege

resolution

is

done

to

remove

redundant

privileges

from

Direct

of

the

new

node

and

privileges

in

nodes

in

Seniors

of

the

the

new

node

made

redundant

by

this

insertion

Note

that

for

a

node

r

the

set

Seniors

-LRB-

r

-RRB-

can

be

enumerated

by

a

depth-first

search

in

the

role

graph

starting

at

node

r

-LSB-

-RSB-

Similarly

the

set

Juniors

-LRB-

r

-RRB-

can

be

computed

by

a

depth-first

search

of

the

graph

formed

by

reversing

the

edges

in

the

role

graph

again

starting

the

search

at

node

r

The

details

of

these

operations

will

not

be

given

here

Algorithm

in

figure

and

also

figure

illustrate

the

role

addition

process

The

flip

side

of

role

addition

is

role

deletion

which

involves

the

elimination

of

a

role

from

the

role

graph

This

process

requires

specifying

the

target

role

and

short-circuiting

it

by

making

the

target

's

immediate

subservient

role

-LRB-

s

-RRB-

the

immediate

subservient

role

-LRB-

s

-RRB-

of

the

target

's

immediate

superior

-LRB-

s

-RRB-

In

doing

so

the

privileges

associated

with

the

deleted

role

can

either

be

eliminated

or

distributed

Privilege

elimination

involves

overall

privilege

reduction

of

the

path

associated

with

the

role

so

deleted

Retaining

the

privileges

of

the

deleted

role

on

the

other

hand

requires

a

specification

of

how

these

privileges

will

be

distributed

among

the

existing

roles

It

is

reasonable

to

assume

that

such

role

deletion

would

not

affect

the

effective

privilege

sets

of

any

superior

roles

of

the

deleted

role

Hence

such

privileges

must

be

transferred

to

the

immediate

superiors

This

would

ensure

path

privilege

invariance

This

case

is

illustrated

pictorially

in

figure

See

the

associated

algorithm

of

figure

Example

Suppose

our

target

role

for

deletion

is

role

D

in

figure

with

the

constraint

that

all

existing

paths

must

keep

their

privilege

sets

invariant

For

this

purpose

we

choose

to

shift

the

privilege

set

of

the

target

role

to

its

superiors

To

achieve

this

first

transfer

the

privileges

from

role

D

to

both

F

and

G

which

are

both

superior

to

D

This

results

in

roles

roles

FX

and

GX

which

we

make

immediate

superiors

of

both

A

and

B

The

previous

edges

incident

to

role

D

i.e.

A

D

F

A

D

G

B

Algorithm

Role

Addition

-LRB-

rg

target

s.target.set

j.target.set

-RRB-

For

the

addition

of

a

given

role

into

a

role

graph

Input

rg

hR

i

-LRB-

the

role

graph

-RRB-

target

role

to

be

added

-LRB-

role

name

along

with

its

proposed

direct

privilege

set

-RRB-

s

target

set

-LRB-

immediate

superior

set

for

the

target

-RRB-

j

target

set

-LRB-

immediate

junior

set

for

the

target

-RRB-

Output

The

role

graph

with

target

added

and

overall

privileges

of

other

roles

left

intact

Var

r

rj

rs

roles

Begin

If

-LRB-

rs

rj

-RRB-

for

any

rs

s

target

set

rj

j

target

set

Then

abort

Must

not

violate

acyclicity

Else

Begin

-LRB-

target

-RRB-

-LRB-

-LSB-

target

set

-LRB-

r

-RRB-

-RRB-

-LSB-

Direct

-LRB-

target

-RRB-

Compute

the

effective

privileges

of

target

role

If

-LRB-

r

-RRB-

-LRB-

target

-RRB-

for

any

r

R

Then

target

r

Role

privilege

sets

must

be

unique

If

-LRB-

target

rj

-RRB-

for

any

rj

j

target

set

Then

abort

Must

not

violate

acyclicity

Else

Begin

a.

R

R

-LSB-

target

Add

target

to

system

roles

b.

For

all

rs

s

target

set

do

add

the

edge

target

rs

c.

For

all

rj

j

target

set

do

add

the

edge

rj

target

d

If

for

any

r

R

-LRB-

r

-RRB-

ae

-LRB-

target

-RRB-

and

NOT

-LRB-

r

target

-RRB-

Then

add

the

edge

r

target

Add

this

inferred

edge

e

If

for

any

r

R

-LRB-

target

-RRB-

ae

-LRB-

r

-RRB-

and

NOT

-LRB-

target

r

-RRB-

Then

add

the

edge

target

r

Add

this

inferred

edge

f.

Rem

Red

Arcs

-LRB-

rg

j.target.set

s.target.set

target

-RRB-

g.

Red

Priv

Res

-LRB-

rg

j.target.set

target

-RRB-

end

For

all

r

ri

rj

R

if

-LRB-

ri

-RRB-

-LRB-

rj

-RRB-

then

Remove

any

duplicate

roles

Begin

for

all

ri

r

do

add

the

edge

rj

r

for

all

r

ri

do

add

the

edge

r

rj

Delete

all

edges

ri

r

and

r

ri

Remove

ri

end

end

end

Role

Addition

Procedure

Rem

Red

Arcs

-LRB-

var

rg

role

graph

j.target.set

s.target.set

role

set

target

role

-RRB-

Removes

redundant

arcs

in

the

immediate

neighbourhood

of

target

role

Var

rk

rj

rs

roles

Begin

For

all

rj

j

target

set

do

Remove

direct

paths

where

there

is

another

path

if

-LRB-

rj

rk

target

-RRB-

then

Delete

the

edge

rj

target

delete

the

direct

edge

For

all

rs

s

target

set

do

if

-LRB-

target

rk

rs

-RRB-

then

Delete

the

edge

target

rs

delete

the

direct

edge

end

Red

Red

Arcs

Procedure

Red

Priv

Res

-LRB-

var

rg

role

graph

j.target.set

role

set

target

role

-RRB-

Var

pv

privilege

r

role

Begin

For

all

r

in

Seniors

-LRB-

r

-RRB-

do

remove

redundant

privileges

from

senior

roles

For

all

pv

Direct

-LRB-

target

-RRB-

do

if

pv

Direct

-LRB-

r

-RRB-

then

Direct

-LRB-

r

-RRB-

Direct

-LRB-

r

-RRB-

pv

For

all

r

in

j.target.set

do

remove

redundant

privileges

from

Direct

-LRB-

target

-RRB-

For

all

pv

-LRB-

r

-RRB-

do

if

pv

Direct

-LRB-

target

-RRB-

then

Direct

-LRB-

target

-RRB-

Direct

-LRB-

target

-RRB-

pv

end

Red

Priv

Res

Figure

Algorithm

for

Role

Addition

a

b

c

X

X

B

C

A

FX

GX

AA

B

CC

B

EE

FX

E

GX

F

G

D

Figure

Role

Deletion

D

F

and

B

D

G

are

replaced

by

A

FX

A

GX

B

FX

and

B

GX

respectively

The

next

move

is

to

do

away

with

redundant

alternative

paths

-LRB-

marked

X

in

the

figure

-RRB-

and

remove

them

We

notice

that

paths

A

C

FX

and

B

E

GX

contain

the

set

of

privileges

of

paths

A

FX

and

B

GX

respectively

This

results

in

a

new

role

graph

structure

as

shown

in

figure

Both

role

addition

and

deletion

correspond

to

real

life

situations

where

in

creating

a

new

portfolio

a

new

role

is

added

while

in

eliminating

some

office

a

role

will

be

deleted

Role

deletion

without

privilege

reduction

entails

elimination

of

some

office

in

an

organization

while

retaining

the

total

functionality

Privileges

of

the

deleted

role

would

be

distributed

to

other

roles

Role

Partition

A

role

can

be

partitioned

into

two

or

more

roles

in

our

role

graph

Essentially

the

basic

partition

operations

are

either

vertical

or

horizontal

and

can

of

course

be

combined

In

both

cases

it

must

be

specified

what

the

new

roles

and

their

corresponding

privileges

are

Where

the

order

of

seniority

is

required

as

in

the

case

of

vertical

partition

it

must

be

specified

as

well

In

vertical

role

partition

a

role

is

split

into

two

or

more

roles

and

an

ordering

is

imposed

on

them

with

the

is-junior

relationship

In

doing

vertical

partition

we

must

specify

the

target

role

the

new

roles

to

be

created

their

direct

privileges

and

their

ordering

-LRB-

according

to

partial

privilege

criterion

-RRB-

For

instance

a

role

X

is

not

only

partitioned

into

roles

Xn

but

also

these

roles

must

be

ordered

e.g.

Xn

-LRB-

see

figure

and

algorithm

of

figure

-RRB-

Privilege

distribution

among

the

new

roles

is

constrained

by

the

privileges

associated

with

the

role

being

partitioned

there

must

not

be

an

increment

or

decrement

of

privileges

i.e.

Direct

-LRB-

X

-RRB-

-LSB-

i

n

Direct

-LRB-

Xi

-RRB-

Consequently

the

privileges

associated

with

the

paths

in

which

the

role

appears

neither

Algorithm

Role

Deletion

-LRB-

rg

target

inv

-RRB-

Deletes

a

specified

role

retaining

or

discarding

its

privileges

depending

on

inv

Input

rg

hR

i

-LRB-

the

role

graph

structure

-RRB-

target

-LRB-

the

target

role

to

be

deleted

-RRB-

inv

Boolean

indicating

whether

or

not

to

retain

the

role

's

privileges

Output

The

role

graph

structure

with

target

deleted

Var

s.set

j.set

role

set

r

rj

rs

role

Begin

s.set

Superior

Set

-LRB-

target

-RRB-

Get

the

senior

set

j.set

Junior

Set

-LRB-

target

-RRB-

Get

the

junior

set

For

all

rs

s

set

do

Connect

Junior

and

Senior

Roles

For

all

rj

j

set

do

add

rj

rs

If

inv

then

do

For

all

rs

s

set

do

Transfer

Privileges

to

superiors

Direct

-LRB-

rs

-RRB-

Direct

-LRB-

rs

-RRB-

-LSB-

Direct

-LRB-

target

-RRB-

For

all

rs

s

set

do

Remove

all

redundant

arcs

For

all

rj

j

set

do

If

-LRB-

rj

rk

rs

-RRB-

then

delete

rj

rs

R

R

target

Take

out

target

from

system

roles

end

Role

Deletion

Function

Superior

Set

-LRB-

var

rg

role

graph

target

role

-RRB-

role

set

Var

Tempset

role

set

r

role

Begin

Tempset

For

all

r

with

target

r

do

Tempset

Tempset

-LSB-

r

Superior

Set

Tempset

end

Superior

Set

Function

Junior

Set

-LRB-

var

rg

role

graph

target

role

-RRB-

role

set

Var

Tempset

role

set

r

role

Begin

Tempset

For

all

r

with

r

target

do

Tempset

Tempset

-LSB-

r

Junior

Set

Tempset

end

Junior

Set

Figure

Algorithm

for

Role

Deletion

Xn

X

Jn

Jn

Sn

Sn

Sn

Xn

a

b

c

Figure

Vertical

Horizontal

Role

Partition

decrease

nor

increase

In

general

vertical

partition

leaves

the

privilege

set

associated

all

paths

unaffected

only

the

path

length

increases

Further

constraints

include

the

requirement

for

distinct

direct

privilege

sets

for

the

newly

created

roles

i.e.

for

any

Xi

Xj

Xng

Direct

-LRB-

Xi

-RRB-

Direct

-LRB-

Xj

-RRB-

Suppose

we

have

a

target

role

for

partition

-LRB-

call

it

X

-RRB-

with

a

relationship

Jng

X

Sng

which

is

partitioned

vertically

into

roles

Xng

such

that

Jng

Xng

Sng

It

follows

that

-LRB-

Xn

-LRB-

Sn

-RRB-

-RRB-

-LRB-

-LRB-

Jn

-RRB-

-RRB-

Horizontal

role

partition

on

the

other

hand

involves

partitioning

a

role

into

two

or

more

roles

with

of

them

being

subservient

-LRB-

superior

-RRB-

to

another

-LRB-

see

figure

and

algorithm

of

figure

-RRB-

Partition

as

used

here

merely

distributes

the

direct

privileges

of

the

target

role

among

newly

created

roles

that

replace

it

In

partitioning

a

role

there

should

be

no

effective

increment

or

decrement

of

privileges

In

other

words

as

with

vertical

partitioning

if

role

X

is

partitioned

into

roles

Xn

we

require

that

Direct

-LRB-

X

-RRB-

-LSB-

i

n

Direct

-LRB-

Xi

-RRB-

The

direct

privilege

sets

of

these

newly

created

roles

can

have

empty

or

non-empty

intersections

However

of

them

should

have

identical

privilege

sets

Note

that

unlike

vertical

partition

horizontal

partition

can

cause

a

variation

of

privileges

associated

with

a

path

when

the

target

role

is

the

senior-most

role

in

the

path

Suppose

we

have

a

target

role

for

partition

-LRB-

call

it

X

-RRB-

with

a

relationship

Jng

X

Sng

which

is

partitioned

horizontally

into

roles

Xng

such

that

Jng

Xng

Sng

It

follows

that

-LRB-

Jng

-LRB-

Xn

-RRB-

-RRB-

-LRB-

Sng

-LRB-

Xn

-RRB-

-RRB-

Updates

to

the

role

graph

include

the

reduction

and

addition

of

role

privileges

which

require

the

specification

of

the

target

role

and

privileges

to

be

removed/added

but

do

not

alter

the

basic

structure

and

relationships

in

the

role

graph

structure

These

may

be

addressed

within

the

context

of

role-privilege

authorization

Algorithm

Vertical

Partition

-LRB-

rg

target

f

-LRB-

-LRB-

xi

-RRB-

xi

rpseti

-RRB-

g

-RRB-

Partitions

a

given

role

vertically

Input

rg

hR

i

-LRB-

the

role

organization

structure

-RRB-

target

-LRB-

the

target

role

to

be

partitioned

-RRB-

f

-LRB-

-LRB-

xi

-RRB-

rpseti

-RRB-

g

-LRB-

the

new

role-direct

privilege

set

pairs

and

their

ordering

-RRB-

Output

The

role

graph

with

target

vertically

partitioned

into

f

-LRB-

-LRB-

xi

-RRB-

rpseti

-RRB-

g

and

integrated

into

the

role

graph

structure

Uses

Superior

Set

and

Junior

Set

of

algorithm

in

figure

Var

s.set

j.set

role

set

rj

rs

roles

Begin

If

Direct

-LRB-

target

-RRB-

S?Direct

-LRB-

xi

-RRB-

Then

abort

Must

keep

privilege

set

invariant

Else

Begin

R

R

-LSB-

fxig

Add

new

roles

to

system

s.set

Superior

Set

-LRB-

target

-RRB-

Generate

superior

set

j.set

Junior

Set

-LRB-

target

-RRB-

Generate

Junior

set

Add

edges

xn

xn

Create

a

Path

as

specified

For

all

xi

do

Direct

-LRB-

xi

-RRB-

rpseti

Assign

the

appropriate

privileges

For

all

rs

s

set

do

add

xn

rs

Join

the

Senior

end

For

all

rj

j

set

do

add

rj

Join

the

Junior

end

R

R

target

Delete

target

from

system

end

end

Vertical

Partition

Figure

Algorithm

for

Vertical

Partition

Algorithm

Horizontal

Partition

-LRB-

rg

target

f

-LRB-

xi

xi

rpseti

-RRB-

g

Partitions

a

given

role

horizontally

Input

rg

hR

i

-LRB-

the

role

organization

structure

-RRB-

target

-LRB-

the

target

role

to

be

partitioned

-RRB-

f

-LRB-

xi

rpseti

-RRB-

g

-LRB-

the

new

role-direct

privilege

pairs

to

replace

target

-RRB-

Output

The

role

structure

with

target

horizontally

partitioned

into

f

-LRB-

xi

-RRB-

g

and

integrated

into

rg

Uses

Superior

Set

and

Junior

Set

of

algorithm

in

figure

Var

s.set

j.set

role

set

r

rj

rs

roles

Begin

If

Direct

-LRB-

target

-RRB-

S?Direct

-LRB-

xi

-RRB-

Then

abort

Must

keep

privilege

set

invariant

Else

begin

R

R

-LSB-

fxig

Add

new

roles

to

system

Roles

s.set

Superior

Set

-LRB-

target

-RRB-

Generate

the

superior

set

j.set

Junior

Set

-LRB-

target

-RRB-

Generate

the

junior

set

For

all

xi

xng

do

assign

the

privilege

set

to

the

new

role

Direct

-LRB-

xi

-RRB-

rpseti

Assign

respective

privilege

sets

R

R

target

Delete

target

For

all

xi

xng

do

begin

For

all

rs

s

set

do

add

xi

rs

Link

New

Roles

to

seniors

For

all

rj

s

set

do

add

rj

xi

Link

New

Roles

to

juniors

end

For

all

r

ri

rj

R

if

-LRB-

ri

-RRB-

-LRB-

rj

-RRB-

then

Remove

any

duplicate

roles

Begin

for

all

ri

r

do

add

the

edge

rj

r

for

all

r

ri

do

add

the

edge

r

rj

Delete

all

edges

ri

r

and

r

ri

Remove

ri

end

end

end

Horizontal

Partition

Figure

Algorithm

for

Horizontal

Partition

The

Role

Graph

Role

Coupling

Considering

our

role

graph

model

proposed

in

section

we

term

the

extent

of

linkage

between

roles

a

coupling

which

is

related

to

the

extent

to

which

privileges

are

shared

among

roles

We

can

have

a

variety

of

cases

e.g.

where

each

role

is

independent

of

all

others

or

where

some

roles

are

coupled

and

hence

dependent

on

each

other

Definition

Coupling

Coupling

exists

between

two

roles

ri

and

rj

if

such

that

rk

ri

rj

and

rk

MinRole

We

call

rk

a

coupling

role

between

ri

and

rj

Definition

Role

Independence

Two

roles

ri

and

rj

are

independent

if

and

only

if

ri

rj

fMinRoleg

i.e.

their

only

coupling

is

the

role

common

to

all

roles

in

the

role

graph

In

other

words

their

only

greatest

lower

bound

is

MinRole

Independent

roles

have

no

coupling

between

them

Comparison

with

Hierarchies

Privilege

Graphs

Others

The

role

graph

model

presented

here

can

simulate

a

hierarchical

organization

We

can

convert

a

role

graph

into

a

tree

-LRB-

hierarchy

-RRB-

and

vice

versa

To

obtain

a

tree

from

a

given

role

graph

we

designate

MaxRole

as

the

root

of

the

hierarchy

and

do

a

recursive

bread-first

or

depth-first

traversal

for

every

node

with

a

relationship

with

MaxRole

A

given

path

terminates

when

MinRole

is

encountered

which

forms

the

leaves

of

all

paths

in

the

resulting

tree

-LRB-

hierarchy

-RRB-

This

tree

contains

all

paths

present

in

the

associated

role

graph

In

going

from

a

tree

to

a

role

graph

we

designate

the

root

of

the

tree

to

be

MaxRole

do

a

depth-first

traversal

of

the

tree

and

equating

nodes

whenever

equal

privileges

are

encountered

The

resulting

role

graph

can

then

be

augmented

with

MinRole

if

necessary

The

advantage

with

the

role

graph

is

its

compactness

i.e.

shared

nodes

lower

in

the

hierarchy

need

not

be

duplicated

This

is

a

major

advantage

in

that

it

reduces

the

extent

to

which

shared

privileges

are

scattered

among

roles

which

makes

the

task

of

tracking

their

use

easier

To

simulate

privilege

graphs

-LSB-

-RSB-

attach

to

every

role

an

associated

functionality

that

specifies

the

associated

duty

requirements/title/etc

With

the

role

's

access

control

list

-LRB-

racl

-RRB-

acting

as

the

user/group

node

-LRB-

figure

-RRB-

it

is

possible

to

determine

the

authorized

users

for

any

role

An

authorized

user

's

access

rights

are

determined

by

the

effective

privilege

set

-LRB-

r

-RRB-

of

the

associated

role

r

to

which

the

user

is

authorized

Further

remove

MaxRole

and

assign

its

explicit

privileges

to

roles

with

direct

partial

privilege

relationship

with

it

As

well

remove

MinRole

and

assign

its

privileges

to

those

roles

with

a

direct

partial

privilege

relationship

with

it

The

result

is

a

privilege

graph

Finally

although

this

model

is

based

on

subsets

with

an

acyclic

graph

it

is

different

from

the

Bell

and

LaPadula

Model

-LRB-

BLPM

-RRB-

Moreover

although

both

are

meant

for

security

application

they

have

different

approaches

to

realizing

protection

The

BLPM

relies

on

subsets

acyclicity

and

is

static

However

it

is

based

on

the

classification

of

information

as

opposed

to

the

execution

of

operations

as

is

the

case

in

our

model

The

BLPM

specifies

two

simple

operations

of

either

read

or

write

access

depending

on

object

classification

and

subject

clearance

This

approach

realizes

multilevel

security

In

our

model

privileges

represent

predefined

executions

designed

in

a

manner

intended

to

realize

certain

desired

functionality

in

a

system

These

operations

are

designed

from

considerations

of

desired

system

functionality

Once

defined

the

operations

are

distributed

among

roles

in

the

system

in

the

manner

that

suits

organizational

requirements

The

executions

can

be

simple

reads

and

writes

They

can

be

a

combination

of

simple

reads

and

writes

But

they

can

also

be

complex

executions

such

methods

in

object-oriented

programming

These

operations

need

not

merely

alter

or

return

the

information

relating

to

a

given

object

but

can

also

create

other

objects

and

invoke

other

operations

In

the

BLPM

once

classification

has

been

done

access

to

information

is

governed

by

the

simple

security

property

and

the

property

Its

specification

is

static

In

our

model

execution

of

privileges

can

cause

the

assignment

or

revocation

of

privileges

pertaining

to

some

role

In

that

respect

our

model

is

dynamic

Summary

Conclusions

It

is

important

to

have

a

means

for

role

organization

that

reduces

the

complexity

of

privilege

management

in

a

role-based

security

system

This

paper

has

presented

a

model

for

role

organization

derived

from

three

basic

role

relationships

viz

partial

shared

and

augmented

privileges

These

lead

to

a

role

graph

formulation

and

use

of

role

graph

theory

The

model

allows

for

the

assignment

of

privileges

in

a

particular

role

and

through

role

relationships

we

determine

the

extent

of

privilege

sharing

Given

the

acyclicity

property

the

role

graph

model

facilitates

role

partial

ordering

and

privilege

subsetting

among

roles

With

an

appropriate

assignment

of

privileges

to

roles

and

specification

of

role

relationships

the

role

graph

can

ease

the

task

of

access

rights

rights

administration

in

a

system

Our

model

has

the

expressive

power

of

both

hierarchies

-LSB-

-RSB-

and

privilege

graphs

-LSB-

-RSB-

The

issue

of

role

administration

was

addressed

and

algorithms

for

role

management

presented

These

include

algorithms

for

role

addition

deletion

and

split

-LRB-

partition

-RRB-

Central

to

role

management

is

the

concept

of

the

change

-LRB-

or

lack

of

change

-RRB-

of

path

privileges

because

path

privilege

changes

have

implications

for

roles

with

indirect

access

to

these

privileges

The

concept

of

paths

in

the

role

graph

is

important

in

that

specific

types

of

processing

can

be

associated

with

specific

paths

Since

there

is

privilege

sharing

among

roles

within

a

path

one

can

impose

constraints

about

the

order

of

role

participation

in

the

processing

as

well

as

separation

of

duty

requirements

Role

and

path

independence

are

important

for

cases

with

conflict

of

interest

Two

types

of

processing

that

conflict

can

be

associated

with

independent

paths

and

by

ensuring

that

no

user

is

authorized

for

roles

from

both

paths

we

can

impose

conflict

of

interest

restriction

to

processing

Currently

we

are

involved

in

the

implementation

of

a

role

management

tool

which

we

hope

will

give

further

insight

into

the

applications

of

the

role

graph

model

in

access

rights

administration

Acknowledgements

This

work

was

supported

in

part

by

a

grant

from

the

Natural

Science

Engineering

Research

Council

NSERC

of

Canada

We

also

thank

Jim

Mullin

for

his

useful

comments

on

an

earlier

draft

of

this

paper

The

anonymous

referees

raised

a

number

of

issues

that

have

been

useful

in

making

clear

some

of

our

ideas

Sheila

Lindsay

who

worked

on

an

implementation

of

the

role

graph

pointed

out

some

errors

in

the

algorithms

proposed

earlier

We

are

grateful

for

her

comments

References

-LSB-

-RSB-

A.

V.

Aho

M.

R.

Garey

and

J.

D.

Ullman

The

Transitive

Reduction

of

a

Directed

Graph

SIAM

Journal

of

Computing

-LRB-

-RRB-

-LCB-

June

-LSB-

-RSB-

R.

W.

Baldwin

Naming

Grouping

Privileges

to

Simplify

Security

Management

in

Large

Databases

In

Proc

IEEE

Symposium

on

Research

in

Security

and

Privacy

pages

-LCB-

IEEE

Computer

Society

Press

May

-LSB-

-RSB-

D.

E.

Bell

and

L.

J.

LaPadula

Secure

Computer

Systems

Unified

Exposition

Multics

Interpretation

Technical

Report

MTIS

MITRE

Corporation

July

-LSB-

-RSB-

T.

H.

Cormen

C.

E.

Leiserson

and

R.

L.

Rivest

Introduction

to

Algorithms

MIT

Presss

-LSB-

-RSB-

D.

D.

Clark

and

D.

R.

Wilson

A

Comparison

of

Commercial

and

Military

Security

Policies

In

Proc

IEEE

Symposium

on

Research

in

Security

and

Privacy

pages

-LCB-

IEEE

Computer

Society

Press

April

-LSB-

-RSB-

D.

E.

Denning

A

Lattice

Model

of

Secure

Information

Flow

Communications

of

the

ACM

-LRB-

-RRB-

-LCB-

May

-LSB-

-RSB-

J.

E.

Dobson

and

J.

A.

McDermid

Security

Models

and

Enterprise

Models

In

C.

E.

Landwehr

editor

Database

Security

II

Status

Prospects

pages

-LCB-

North-Holland

-LSB-

-RSB-

J.

Glasgow

G.

MacEwen

and

P.

Panangaden

A

Logic

for

Reasoning

About

Security

ACM

Transactions

on

Computer

Systems

-LRB-

-RRB-

-LCB-

August

-LSB-

-RSB-

E.

V.

Krishnamurthy

and

A.

McGuffin

On

the

Design

Administration

of

Secure

Database

Transactions

ACM

SIGSAC

Review

pages

-LCB-

Spring/Summer

-LSB-

-RSB-

L.

G.

Lawrence

The

Role

of

Roles

Computers

Security

-LRB-

-RRB-

-LCB-

Feb

-LSB-

-RSB-

Udi

Manber

Introduction

to

Algorithms

A

Creative

Approach

Addison-Wesley

-LSB-

-RSB-

M.

Nyanchama

and

S.

L.

Osborn

Role-Based

Security

Object

Oriented

Databases

Separation

of

Duty

ACM

SIGMOD

RECORD

-LRB-

-RRB-

-LCB-

Dec

-LSB-

-RSB-

M.

Nyanchama

and

S.

L.

Osborn

Role-Based

Security

Pros

Cons

Some

Research

Directions

ACM

SIGSAC

Review

-LRB-

-RRB-

-LCB-

June

-LSB-

-RSB-

M.

Nyanchama

and

S.

L.

Osborn

Information

Flow

Analysis

in

Role-Based

Security

Systems

All

about

nothing

Journal

of

Computing

Information

-LRB-

-RRB-

May

Special

Issue

Proc

of

the

International

Conference

on

Computing

and

Information

-LRB-

ICCI

-RRB-

Peterborough

Ontario

Canada

-LSB-

-RSB-

F.

Rabitti

E.

Bertino

D.

Woelk

and

W.

Kim

A

Model

of

Authorization

for

Next

Generation

Databases

Systems

ACM

TODS

-LRB-

-RRB-

-LCB-

March

-LSB-

-RSB-

F.

Rabitti

D.

Woelk

and

W.

Kim

A

Model

of

Authorization

for

Object

Oriented

and

Semantic

Databases

In

Proc

of

Int

l

Conference

on

Extending

Database

Technology

March

-LSB-

-RSB-

T.

C.

Ting

S.

A.

Demurjian

and

M.

Y.

Hu

Requirements

Capabilities

and

Functionalities

of

User-Role

Based

Security

for

an

Object-Oriented

Design

Model

In

C.

E.

Landwehr

and

S.

Jajodia

editors

Database

Security

V

Status

Prospects

pages

-LCB-

NorthHolland

-LSB-

-RSB-

D.

J.

Thomsen

Role-Based

Application

Design

and

Enforcement

In

S.

Jajodia

and

C.

E.

Landwehr

editors

Database

Security

IV

Status

and

Prospects

pages

-LCB-

North-Holland

access control
least privilege
privilege graph
role graph
roles