DYNAMIC CONTEXT-AWARE ACCESS CONTROL

Use of Resource Hierarchies to Deﬁne Fine-grained, Adaptable

Authorization Policies

Annett Laube and Laurent Gomez

SAP Research, SAP Labs France SA, 06250 Mougins, France

Keywords:

Access control, Context Awareness, Resource Hierarchy.

Abstract:

Complex access control rules often interfere with the business logic within applications. We show a solution

based on strict separation of application and security logic that allows dynamic policy enforcement based

on context-information as well as the adaptation of granularity outside the applications. The deﬁnition of

resource hierarchies driven by application needs and related authorization policies make the granularity for

the permissions ﬂexible and adaptable without touching the applications themselves. The explicit notation of

authorization policies and the enforcement independent from the application offer a new extensibility.

1 INTRODUCTION

Due to emerging Service Oriented Architecture

(SOA) data and applications formerly hidden are now

being exposed as services to the outside world. This

raises unique challenges of securing and governing

data exchange. Access control is not anymore based

on static role-based access control (RBAC) models.

Context-information is used to deﬁne more precise

and ﬁne-grained authorization policies.

As context-aware access control, we understand

the integration of context information into the deﬁ-

nition and enforcement of authorization policies. It

allows the transition to access control adapting to

the current situation. Dynamic authorization enforce-

ment makes authorization decisions based upon run-

time parameters rather than simply a role assignment.

Following the SOA principle services can be com-

posed to new composite services and applications are

constructed out of them. The services are forced

to provide a ﬂexible and conﬁgurable authorization

concept that can be changed according to the appli-

cation needs. Authorization policies deﬁned on ap-

plication level are broken down to the service level.

We propose the separation of business and authoriza-

tion logic to fulﬁll the requirements requested by the

loosely coupled SOA services.

The granularity used during the access control

should not only be deﬁned by the services. It should

be more independent and in relation to the using ap-

plication. We describe a solution that allows the def-

inition of the authorization policy granularity outside

the service itself. We show the use of resource hierar-

chies as part of the authorization policy.

In section 2, we deﬁne context-aware authoriza-

tion policies with and without resource hierarchies

formally. Section 3 contains two scenarios where the

policies are applied to real business scenarios. In sec-

tion 4, we show the architecture used to validate our

approach. Section 5 shows related approaches and

discusses our solution. At the end a further outlook

is given.

2 CONCEPT

In this section, we deﬁne our terminology and intro-

duce a deﬁnition of context-aware authorization poli-

cies. Further, we show the use of resource hierarchies

to adapt the granularity of the policies.

2.1 Context-aware Authorizations

Access control is the process of granting permissions

in accordance with an authorization policy. An au-

thorization policy states “who can do what to what”.

386

Laube A. and Gomez L. (2007).

DYNAMIC CONTEXT-AWARE ACCESS CONTROL - Use of Resource Hierarchies to Deﬁne Fine-grained, Adaptable Authorization Policies.

In Proceedings of the Second International Conference on Security and Cryptography, pages 386-393

DOI: 10.5220/0002122903860393

 SciTePress

The “who” is a subject, the ﬁrst “what” is an action,

and the other “what” is a resource. In a context-

aware authorization policy the context is taken into

account as additional constraint. The statement can be

extended as follows: “who can do what to what under

which circumstances”. The circumstances correspond

to the context of the application.

The subject S in an authorization policy is the ac-

tor that uses an application or system and requests the

access to a resource. Examples are users, as abstrac-

tion of real persons or technical processes.

A resource R is an object exposed by an appli-

cation or system. Resources can be data, services or

system components.

An action A is an operation on a resource. Ex-

amples are read, modify or delete. The operations are

dependent on the resource to be applied to. The ﬁnite

set of available actions on a resource R is deﬁned as:

= {A

}

Deﬁnition 1 As context information C we under-

stand any property related to an entity. An entity

might be the subject or any other participant in the

system as well as any object in the real world.

The context information can be the time or loca-

tion of the entity, but also more complex characteris-

tics like a role of the subject or the health condition of

a patient are possible. Complex context information

is the result of aggregation, computing or inference

based on atomic context information coming directly

from physical or logical sensors.

Every context-aware authorization policy has its own

formal context information set C

. The ordered set

contains all context information types that are used

during the policy evaluation:

= {C

}

In the policy enforcement process a runtime context

information set c is used:

= {c

}

is the current value of context information type C

The formal context information set C contains the

type of context information that is later used in the

context-aware authorization policy.

In the following

example, the context information set contains the role

of the subject, location, time and the current tempera-

ture of the location. The runtime context information

set c

contains the real values that are obtained from

Possible types of context-information, categories and

classiﬁcations are proposed in (Chen and Kotz, 2000;

Mikalsen and Kofod-Petersen, 2004).

the subject and its environment and that are ﬁnally

used in the access control enforcement process.

={role,location,time,temperature}

={‘worker‘, ‘room10‘,‘10h00‘,‘10C‘}

Deﬁnition 2 The context constraint T is the formal

expression of the circumstances in which the permis-

sion the subject wants to acquire is granted. The

context constraint is expressed as logical disjuncted

clauses. A clause consists of one or more proposi-

tions which are logical conjuncted.

Constraint =

Clause

Clause =

Proposition

A proposition is a boolean-valued function that can

be represented in Backus-Naur-Form:

Proposition ::= hCihOPihVALUEi where:

C ∈ C

;

OP is a operator in the set {>,≥,<,≤, 6=,=},

which can be extended to accommodate user-

deﬁned operators as well;

VALUE is a speciﬁc value of C.

Deﬁnition 3 A context-aware authorization policy is

deﬁned as a triple AP = (S,P,T) where:

S ... is the subject in this policy.

P ... is the target permission in this policy hA

,Ri,

where A

is an action of resource R.

T .. . is a context constraint for this policy.

Deﬁnition 4 We deﬁne the authorization request as

a triple AR = (S,P,c) where:

S . .. is a requestor who triggers the authori-

zation decision.

P . .. is the permission the requestor wants to

acquire, a pair hA

,Ri.

.. . is the runtime context information set.

The authorization request AR gets the decision

“Permit” only if there exists an applicable policy

AP = (S

′

,T), such that S = S

′

, P = P

′

, and T eval-

uates to true under c (that means, when all C

in the

constraint T are replaced with the runtime values of

, then the resulting boolean expression is true).

The enforcement function on the policy AP is de-

ﬁned as:

(AR) = f

(S,P, c

) = d where:

.. . enforcement function,

d .. . decision, with d ∈ { Permit, Deny,

Indeterminate, NotApplicable

}

We use the decision values deﬁned in XACML(OASIS,

2003) as result value set for the enforcement function.

DYNAMIC CONTEXT-AWARE ACCESS CONTROL - Use of Resource Hierarchies to Define Fine-grained, Adaptable

Authorization Policies

387

2.2 Context-aware Resource Filters

Deﬁnition 5 A resource hierarchy G

can be de-

scribed as directed acyclic graph (DAG) over a ﬁnite

set of nodes R

, built from a resource and all its direct

children and descendants at any depth.

= (R

,E)

R ... Set of nodes in the hierarchy:

= {r

},R ∈ R

The set of nodes contains the resource itself.

.. . Set of edges (order pairs of nodes):

⊂ R× R, E = {(r

)}

R .. . the considered resource R is the root node

(source) of G

: (R, r

) ∈ E

∧ (r

,R) /∈ E

The deﬁnition of the node set in the hierarchy and

the relations between the nodes are highly dependent

of the application and the authorization policy. There

are examples later in section 3.

With the deﬁnition of resource hierarchies we can

introduce a new kind of authorizations policies.

Deﬁnition 6 A context-aware authorization policy

with resource ﬁlters is deﬁned as a set of triples:

= {AP

} = {(S,P

)} where:

S .. . is the subject in this policy

.. . is the target permission, which is deﬁned

as pair hA

i, where A

is an action and

is a node of the resource hierarchy: r

∈ R.

.. . is a context constraint of resource node r

Despite the extension of the policy to the resource

node level, the authorization request stays unchanged

(Deﬁnition 4). Only the enforcement function is ex-

tended to the nodes of the resource hierarchy.

The authorization request AR = (S, P,c

) gets the

permission to the node r

only, if there exists an ap-

plicable policy AP

= (S

′

), such that S = S

′

P = hA

,Ri, P

′

= hA

i, r

∈ R

, and T

′

evaluates

to true under c

The new enforcement function is now deﬁned as:

′

(AR) = f

′

(S,P, c

) = {(r

,d)}

′

.. . enforcement function,

.. . node i of the resource hierarchy,

d .. . decision, with d ∈ { Permit, Deny, Indeter-

minate, NotApplicable }.

The use of a hierarchy deﬁnes a partial order over

the set of nodes that applies an additional constraint

to the authorization decision. It is not possible to

grant the permission to a node while the permission

to the father node is denied. This constraint can be

described formally as follows:

,Permit) ∈ f

′

(AR) while

′

evaluates to true under c

∧

= R (r

is the root node) ∨

6= R∧ (r

) ∈ E∧ (r

,Permit) ∈ f

′

(AR)))

After the formal deﬁnition we apply this theory in

the following to two application scenarios.

3 SCENARIOS

3.1 Beyond Rbac

Role-based access control (RBAC) (Sandhu et al.,

1996) associates permissions with roles to simplify

the permission management. Users are members of a

role. The role brings together a set of users on one

side and a set of permissions on the other side.

We want to show that our approach goes beyond

the widespread RBAC model. We deﬁne a role as

context information related to the subject as proposed

in (den Bergh and Coninx, 2005). That implies that

the role is part of the runtime context information set.

Figure 1: BusinessPartner object hierarchy.

As an example, we imagine a business application

that exposes a service to access an object Business-

Partner. This object maintains master data of natural

persons and companies like customers or suppliers.

Several concrete classes are derived from the ab-

stract class BusinessPartner, see Fig. 1. Each deriva-

tion adds speciﬁc attributes that are only relevant for

this type of object. For example, an employee has

a salary grade, a private bank account, a private and

a business address. A customer has marking data, a

shipping address and an invoice address.

The use of the object BusinessPartner as interface

for the application allows the identical manipulation

of the different classes in the hierarchy. The follow-

ing authorization rules shall be applied to the retrieve

method of the Employee object:

SECRYPT 2007 - International Conference on Security and Cryptography

388

1. Only a human resource accountant can access all

data of an employee.

2. An employee has access to the business address of

all employees and to his own private address and

bank account. He has no access to his salary.

3. A manager has access to the data of his/her em-

ployees, except for the sensible personal data, like

birthday, private address and bank account.

To formalize the authorization policy for the HR

accountant (Rule 1) no resource hierarchy is needed:

Accountant

= (S,hread, employeei,

(role = ‘accountant‘))

For the next rules, the deﬁnition of a resource hi-

erarchy for the employee object is necessary. The de-

sign of a resource hierarchy requires knowledge of the

application and understanding of the requirements of

the authorization rules. For convenience, the resource

hierarchy is graphically presented in Fig. 2. The node

set R

employee

is deﬁned by:

employee

= {e.employee,e.bus

address,

e.personal data, e.salary,e.general,

e.privat

address,e.birthday, e.name,

e.privat

bank, e.manager. ..}

personal_data salary general ...

private_address private_bank birthday name manager ...

employee

bus_address

-

Figure 2: Employee’s resource hierarchy.

The authorization rule for an employee (Rule 2) is

now a set of authorization policies on the employee’s

resource hierarchy:

Employee

={AP

,AP

}

= (S,hread, e.employeei, (role = ‘employee‘))

= (S,hread, e.bus

addressi,true)

= (S,hread, e.personal datai,(id(e) = id(S)))

= (S,hread, e.private addressi,true)

= (S,hread, e.private banki,true)

= (S,hread, e.generali,true)

= (S,hread, e.manageri,true)

= (S,hread, e.namei,true)

Because of the partial order in the hierarchy it is suf-

ﬁcient to apply context constraints only to the highest

level in the hierarchy. The role constraint is applied to

the root node (e.employee) in the hierarchy. The ac-

cess to the subnodes like e.bus

address and e.general

and their subnodes is only granted when the access to

the root node was permitted.

We assume that a manager has two roles: the man-

ager role and the employee role. Only one additional

authorization has to be deﬁned for the manager’s priv-

ilege (Rule 3):

Manager

= (S,hread, e.salaryi, (role = ‘manager‘∧

manager(e) = S))

The authorization rules stated above contain also one

implicit obligation. An accountant in his role as em-

ployee should not be able to access his own salary

grade. Therefore the authorization policy should be

enhanced as follows:

Accountant2

= (S,hread, employeei,

(role = ‘accountant‘∧ e.id 6= S.id))

RBAC roles would be powerful enough to differ-

entiate between a HR accountant and a normal em-

ployee. However, RBAC gives either permission to

a resource or denies it completely (all or nothing

paradigm). In order to implement the authorization

rules described above, it would be necessary to im-

plement a much more detailed and ﬁne-grained ser-

vice interface. In this case, there are two possibilities:

The ﬁrst is to implement an interface specialized for

each role, which creates a very high dependency to

the authorization policy. The second option is to have

many smaller services that allow to retrieve parts (sub

resources) of the BusinessPartner, like the name or

bank account. This would create a big impact on per-

formance. Instead of having only one service call to

get all data, a couple of calls are necessary.

The requirement, that a manager can access only

the data of his/her employees, cannot be enforced

with a simple role-based or group-based concept.

At least RBAC extensions, based on organizational

structure, like OR-BAC(Kalam et al., 2003), are nec-

essary. Our approach considers information about

the organization in a company as context-information

related to the subject. In addition, it is possible to

enforce restrictions related to the separation-of-duty

principle, like described in the policy AP

Accountant2

3.2 e-Health

The second scenario addresses mobile health care ap-

plications. It demonstrates the use of complex context

information during the access control to the medical

data in emergency situations.

A patient is monitored by several health sensors.

The physician needs access to the medical data of the

patient. The medical record consists of personal data

(name, birthday, address, ...), insurance data, medi-

cation history, treatments, sensor data and more.

DYNAMIC CONTEXT-AWARE ACCESS CONTROL - Use of Resource Hierarchies to Define Fine-grained, Adaptable

Authorization Policies

389

Contextual Information Authorization Decision

Family doctor Emergency House call Proximity Name, Birthd. Medication Treatments Sensor data

yes - - - Permit Permit Permit Permit

no yes - far Permit Deny Deny Deny

no yes - near Permit Permit Deny Permit

no no yes far Permit Deny Deny Deny

no no yes near Permit Permit Permit Permit

personal_data insurance medical_data ...

private_address private_bank birthday name medication treatments

patient

-

sensors

Figure 3: Patient’s resource hierarchy.

The object schema in Fig. 1 can easily be ex-

tended to cover the requirements of patients and med-

ical data. The resource hierarchy for the patient can

be deﬁned similar to the hierarchy for the employee

(Fig. 2). The graph is shown in Fig. 3. The node set

is described as:

patient

= {p.patient, p.personal

data, p.name,

p.private address, p.private bank,

p.birthday, p.insurance, p.medical

data,

p.medication, p.treatments, p.sensors,.. .}

Except the family doctors, a physician gets access

only when several conditions apply, see Table 3.1.

The resulting authorization policy that satisﬁes these

constraints can be deﬁned as follows:

Physician

={AP

,AP

}

=(S,hread, p.patienti, (role = ‘physician‘))

=(S,hread, p.personal

datai, ( familyDoctor(p,S) = true

∨ emergency(p) = true∨ houseCall(p, S) = true))

=(S,hread, p.namei,true)

=(S,hread, p.birthdayi,true)

=(S,hread, p.medical

datai, ( familyDoctor(p,S)

∨ ((emergency(p) = true∨ houseCall(p, S) = true)

∧ proximity(p, S) = ‘near‘)))

=(S,hread, p.medicationi,true)

=(S,hread, p.treatmentsi, (houseCall(p,S) = true))

=(S,hread, p.sensorsi,true)

The used context information set C can be noted as:

C = {role, familyDoctor(p,S),emergency(p),

housecall(p, S), proximity(p,S)}

The context information is often noted as functional

expression, which is evaluated during runtime. If a

property is stated without reference, it belongs auto-

matically to the subject, for example ’role’.

Let us make an example to demonstrate the eval-

uation of context constraints during runtime. The

physician Dr. Wells wants to read the medical record

of patient Bob. The physician role is assigned to the

doctor. He is a not member of the group of family

doctors assigned to Bob. Bob’s health status is crit-

ical. It is an emergency situation. Dr. Wells got no

house call assignment for Bob, but he is close to Bob.

The authorization request can then be stated as:

= (‘Dr.Wells‘,h‘read‘, ‘PatientBob‘i,

{‘physician‘, false,true, false,‘near‘})

The enforcement function based on the authoriza-

tion policy AP

Physician

will return the following result:

′

APPhysician

(AR

) = {(p.patient,Permit),

(p.personal

data,Permit), (p.private address, Deny),

(p.private

bank, Deny), (p.name,Permit),

(p.birthday,Permit), (p.insurance,Deny),

(p.medical

data,Permit), (p.medication, Permit),

(p.treatments, Deny), (p.sensors,Permit), . .. }

The result is graphically shown in Fig. 3: All gray

shaded nodes of the hierarchy are permitted.

This scenario shows the use of context informa-

tion together with the use of resource hierarchies.

The returned medical information is always adapted

to the need of the situation. The health application

is completely independent of the access control and

focuses on the functional aspect of retrieving the pa-

tients’ medical record. The deﬁnition of authorization

policies and the deﬁnition of resource hierarchies are

technically separated from the health application, but

still logically dependent on it.

This separation eases the adding of more players

in the health care chain, like specialists, pharmacists

or health insurance companies. The medical applica-

tion can be used to retrieve the relevant data for each

player dependent on the situation they are involved in.

4 ARCHITECTURE

Our approach has been validated in a prototype based

on the context-aware security framework (see Fig. 4)

developed in the MOSQUITO project (MOSQUITO,

SECRYPT 2007 - International Conference on Security and Cryptography

390

2006). The use of resource ﬁlters in the authorization

policies and during policy enforcement is an exten-

sion.

Message

Filters

SecureTicket

Service

WebService

WS-Security

Message

Filters

SOAP SOAP

Subject's

CIP

CoOL

WS-Trust

WS-Security

Client

Application

Authorization

Service

CIP

CoOL

WS-Trust

WS-Security

Policies

Resource

Hierarchies

Figure 4: General architecture.

All SOAP messages between the application (web

service client) and the web service itself have to

pass intermediaries, to enforce the conﬁgured security

policies on message (SOAP) level (see Fig. 5). In-

termediaries are a pipeline of message ﬁlters (proxy)

which support WS-Security(OASIS, 2006).

The client side intermediary adds encryption, in-

tegrity checks and credentials. The server-side inter-

mediary decrypts, veriﬁes the integrity and veriﬁes

the authorization in credentials. It offers the same

interface as the web service plugged behind it and

is therefore invisible from outside. The Security To-

ken Service (STS) (OASIS, 2005) on the client device

generates signed context information retrieved from

the client’s Context Information Providers (CIP) and

adds as well the role information for the subject.

The retrieved context information is converted

into a XACML request via XSLT (W3C, 1999) trans-

formation, which is sent to a Policy Decision Point

(PDP) that enforces the access control policy. If the

XACML response is “Permit” the original request

from the web service client is passed to the web ser-

vice and processed there. Otherwise, an exception is

sent to the client application.

The response of the web service is as well passed

through the security proxy with its message pipeline.

First, the response ﬁlter is applied to make the web

service response compliant to the access control pol-

icy, using the XACML response from the Contextual

Authorization Service. Afterwards additional ﬁlters

take care of encryption/decryption and integrity.

The standard for access control policies is

XACML(OASIS, 2003). XACML supports RBAC

policies as well as context-aware access control. The

policy enforcement relies on verifying attribute val-

ues distributed in four categories, related to the sub-

ject, the resource, the action and the environment. To

Figure 5: Activity diagram of web service call processing.

support evaluation of context information, the exist-

ing implementation can be extended by deﬁning new

primitive attributes types that offer a higher level of

abstraction for data representation. As an example the

authorization policy for emergency is shown in Fig. 6.

The goal of the authorization service is to en-

force context-aware access control to web ser-

vices(Lachmund et al., 2006).

The server-side message ﬁlter calls the method

authorizationRequest of the Contextual Authoriza-

tion Service providing the following three parameters:

ActionTo contains in the action to be performed and

the resource description. Parameter Message contains

the SOAP message request. Credentials contains all

credentials attached to the requestor.

The ActionTo parameter is used to retrieve the as-

sociated XACMLRequestGenerator and the security

policy to be applied. The context information needed

to enforce the policy is evaluated out of the security

policy and requested from the available CIPs.

The XACMLRequestGenerator converts the in-

coming message and the credentials into a XACML

request using XSLT transformations. It adds the data

retrieved from the CIPs. The generated request is

evaluated by the PDP. Before the evaluation starts the

set of nodes of the requested resources is determined.

The evaluation can be based on the resource as well

as on context information or the message content. The

resulting response contains a separate result for each

node in the hierarchy (see Fig. 7).

When the access to a resource is permitted the

original web service request is sent to the web service

and processed there. The web service response has

again to pass the message pipeline. It evaluates all

not permitted subresources and applies a XML trans-

formation to modify the SOAP message accordingly.

The result of the enforcement function f

′

(AR)

is used to make the data returned by the web service

DYNAMIC CONTEXT-AWARE ACCESS CONTROL - Use of Resource Hierarchies to Define Fine-grained, Adaptable

Authorization Policies

391

<Rule RuleId="MixedLocalisationRule"

Effect="Permit">

<SubjectAttributeDesignator DataType=string

AttributeId="role"/></Apply>

<AttributeValue DataType="string">physician

</AttributeValue>

</Condition>

<SubjectAttributeDesignator

DataType=cool#GPSLocation

AttributeId="SubjectLocation"/>

</Apply>

<SubjectAttributeDesignator

DataType="cool#GPSLocation"

AttributeId="ObjectLocation"/>

</Apply>

<AttributeValue DataType="integer">50

</AttributeValue>

</Apply>

<SubjectAttributeDesignator

DataType="cool#Emergency"

AttributeId="ObjectEmergency"/></Apply>

</Apply>

</Condition></Rule>

</Policy>

Figure 6: Authorization Policy example.

call compliant to the policy. The message response is

passed through a ﬁlter, that either removes the data,

which is not in the set of permitted nodes.

Filter

(R) = {r

} with (r

,Permit) ∈ f

′

(AR)

Two possible modiﬁcations can be applied: If the

access to an optional node of the response is denied

the part can be removed from the structure. In the

case of a mandatory element the information must be

blanked out (e.g. replaced with “xxx...” for strings).

The result of the ﬁltering is a modiﬁed response which

is compliant to the access control policy.

5 RELATED WORK

RBAC based models are widespread. Many exten-

sions like GRBAC, OR-BAC and DRBAC were in-

troduced to make the original approach more ﬂexible

and to overcome static permissions. GRBAC(Moyer

<Result ResourceID=

"http://localhost/MedicalData/personal">

<Decision>Permit</Decision>

</Result>

<Result ResourceID=

"http://localhost/MedicalData">

<Decision>Permit</Decision>

</Result>

<Result ResourceID=

"http://localhost/MedicalData/insurance">

</Result> ...

</Response>

Figure 7: XACML response for a resource hierarchy.

et al., 2000) is an extension that uniformly applies

the concept of roles not only to subjects, but also

to objects and system states. OR-BAC(Kalam et al.,

2003) offers the use of contextual rules related to per-

missions, prohibitions, obligations and recommenda-

tions often valid in speciﬁc organizational structures.

The DRBAC model proposed in (Zhang and Parashar,

2004) uses context information during the enforce-

ment process. A change in the user’s context implies

a change of his access privileges.

A combination of these models would be sufﬁ-

cient to meet all requirements of our 2 scenarios.

However, none of the approaches is able to deal

with the special requirements of the SOA architec-

ture without inﬂuencing the development paradigm

and performance. Like already concluded in section

3.1 the use of these approaches is not possible in a sys-

tem built out of loosely coupled application services

with very general interfaces without contradicting the

principles behind.

Our approach is based on a strict separation of ap-

plication and security that is imposed by our archi-

tecture. There are other frameworks like the Open

Group’s Authorization API, the Policy Machine from

NIST (Galiasso et al., 2000) and the Object Secu-

rity Attributes middleware (Beznosov, 2002), which

allow to externalize the authorization policies and to

enforce them in the framework or middleware. Not all

of them allow the use of dynamic context-information

during the policy enforcement process. Our approach

goes further: It allows the separation of security-

related application knowledge in a way that the ap-

plication focuses only on functional aspects. Autho-

rization policies can be designed and modiﬁed in-

dependly from the application and can include all

context-information relevant and available to the sys-

tem.

In addition, the use of resource ﬁlters allows a

SECRYPT 2007 - International Conference on Security and Cryptography

392

modiﬁcation of the service response and request in

order to modify it according the authorization policy.

The service itself can be designed and implemented

in a very generic way.

The use of resource hierarchies is quite common.

Normally similar single resources are grouped, like

printers (Ilechko and Kagan, 2006). The hierarchies

are used to assign identical authorization policies, of-

ten ACLs, to all members. Our approach is the ﬁrst

using the resource hierarchy in the opposite way and

putting single resources in a hierarchy that can be ad-

dressed explicitly in the authorization policy.

6 CONCLUSION

We present a dynamic context-aware access control

that can be used in a SOA based architecture. We

propose a separation of business and security logic on

the service level that allows the deﬁnition of adapt-

able and easily extensible authorization policies out-

side the service. The complexity when mixing access

control into the business logic can be avoided. The

externalized authorization policies are more explicit.

The authorization policies are dynamically en-

forced using runtime context information. Resource

hierarchies make it possible to deﬁne the authoriza-

tion policy granularity outside the service. The deﬁ-

nition of the resource hierarchy itself is based on ser-

vice, on the needs of the client application and, if

needed, on additional context information. The hi-

erarchy helps to keep the relationships between the

sub resources, which would not be the case when the

service itself would split its functionality to a similar

level.

The use of context information questions the way

in which the information is acquired. Context-aware

services and applications have to deal with issues of

trust and dependability. In this paper, we did not ad-

dress the related problems but we will focus them in

the future.

Performance in SOA based application is an issue

investigated by industry and the research community.

The proposed architecture consisting of messages ﬁl-

ters and the Contextual Authorization Services adds

an additional bottleneck. Retrieving and processing

of context information is also time consuming. Due

to the application of the resource ﬁlters after the busi-

ness logic it is also possible that the SOA service pro-

cesses and retrieves more data than later passed to the

client applications. There is a need for adaptation of

our architecture in the area of high performance ap-

plication.

REFERENCES

Beznosov, K. (2002). Object security attributes: Enabling

application-speciﬁc access control in middleware. In

4th International Symposium on Distributed Objects

and Applications (DOA), pages 693–710.

Chen, G. and Kotz, D. (2000). A Survey of Context-

Aware Mobile Computing Research. Technical Report

TR2000-381, Dartmouth College, Computer Science,

Hanover, NH.

den Bergh, J. V. and Coninx, K. (2005). Towards inte-

grated design of context-sensitive interactive systems.

In PERCOMW ’05: Proceedings of the Third IEEE In-

ternational Conference on Pervasive Computing and

Communications Workshops.

Galiasso, P., Bremer, O., Hale, J., Shenoi, S., and al. (2000).

Policy mediation for multi-enterprise environments.

In ACSAC ’00: Proceedings of the 16th Annual Com-

puter Security Applications Conference.

Ilechko, P. and Kagan, M. (2006). Authorization concepts

and solutions for j2ee applications.

Kalam, A. A. E., Benferhat, S., Mi

ege, A., Baida, R. E.,

Cuppens, F., Saurel, C., Balbiani, P., Deswarte, Y., and

Trouessin, G. (2003). Organization based access con-

trol. In POLICY ’03: Proceedings of the 4th IEEE In-

ternational Workshop on Policies for Distributed Sys-

tems and Networks, page 120, Washington, DC, USA.

Lachmund, S., Walter, T., Bussard, L., Gomez, L., and

Olk, E. (2006). Context-aware access control. In

IWUAC’06: Proceedings of the third Annual Interna-

tional Conference on Mobile and Ubiquitous Systems.

Mikalsen, M. and Kofod-Petersen, A. (2004). Represent-

ing and Reasoning about Context in a Mobile Envi-

ronment. In Schulz, S. and Roth-Berghofer, T., edi-

tors, Modeling and Retrieval of Context 2004 (MRC),

volume 114, pages 25–35.

MOSQUITO (2006). IST 004636 MOSQUITO Project.

Moyer, M., Covington, M., and Ahamad, M. (2000). Gen-

eralized role-based access control for securing future

applications. In 23rd National Infromation Systems

Security Conference (NISSC 2000).

OASIS (2003). eXtensible Access Control Markup Lan-

guage (XACML) 1.1.

OASIS (2005). Web Service Trust Language (WS-Trust)

1.3.

OASIS (2006). Web Service Security: SOAP Message Se-

curity 1.1 (WS-Security 2004).

Sandhu, R. S., Coyne, E. J., Feinstein, H. L., and Youman,

C. E. (1996). Role-based access control models. IEEE

Computer, 29(2):38–47.

W3C (1999). W3C XSL transformations (XSLT) 1.0.

Zhang, G. and Parashar, M. (2004). Context-aware dynamic

access control for pervasive computing.

DYNAMIC CONTEXT-AWARE ACCESS CONTROL - Use of Resource Hierarchies to Define Fine-grained, Adaptable

Authorization Policies

393