A context-aware access control framework - CiteSeerX

A

access control framework for e- service provision

context-aware

Vassilis Kapsalis Industrial Systems Institute Patras Greece

kapsalisgisi.gr

Dimitris Karelis Technological Educational Institute of Patras Greece

dkarelisgteipat.gr

Loukas Hadellis Technological Educational Institute of Patras Greece

loukasgteipat.gr

Patras Greece

papadopoulosgee.upatras.gr

permit the grouping of a set of permissions related to a position in an organization, rather than the person assigned to the permission. With the advent of web services, any resource may be accessed through the Internet, based on an XML-based interface, conforming to the Web Services Description Language (WSDL) specification [2]. The relevant web services technologies form the foundation that enable the provision of large-scale e-services by a multitude of service providers (SPs). SPs may be defined as business entities that provide value-added e-services to their customers through a web services infrastructure, such as preventive maintenance, energy management services,

Abstract - The emerging web services technologies constitute the infrastructure that enables the provision of a new generation of e-services and applications. However, the provision of e-services through the Internet imposes increased risks, since it exposes data and sensitive information outside the customer premises. In this paper, we propose a context-aware, access control architecture, in order to support fine-grained authorizations for the provision of e-services, based on an end-to-end web services infrastructure. Access permissions to distributed web services are controlled through an intermediary server, based on a role-based access control (RBAC) model, which incorporates dynamic context information, in the form of context constraints. A high level of abstraction of the physical environment is achieved by using the concepts of simple and composite context conditions. Also, the paper proposes adequate mechanisms for updating context dynamically. Finally, an example use case is presented.

etc. However, the provision of e-services by SPs through the Internet imposes increased risks, since it exposes sensitive data information outside the customer premises. Thus, an advanced security mechanism has to be incorporated in the e-services framework, in order to protect this information against unauthorized access. Role-based access control (RBAC) is the most popular access control model that is applied in current software systems [3]. RBAC uses the concept of roles to embody a collection of permissions within an organizational setup. However, when traditional RBAC makes access control, it takes into account the roles and it does not enable the specification of more advanced rules that are aware of other context information, such as time, location, trust level, etc. Several researchers have proposed extensions to the RBAC model, in order to enable the enforcement of more complex rules and the inclusion of context information in authorization decisions. Bertino et al. [4] introduced the specification of temporal constraints on role enabling and hence provided a mechanism to enforce time-dependent access control (TRBAC). Covington et al. [5] introduced Generalized Role-Based Access Control (GRBAC), which enhanced traditional RBAC, by incorporating the notion of object roles and

I. INTRODUCTION

Access control is concerned with permitting only authorized users (subjects) to access services and resources (targets), by limiting the activity of legitimate users who have been successfully authenticated, based on their access rights. Access control models and mechanisms have been extensively presented in the literature controlling access to resources, including files, directories, web pages, XML documents, objects, etc. [1]. In general, these models are categorized as discretionary access control (DAC), mandatory access control (MAC) and role-based access control (RBAC). DAC policies restrict access to objects based on the identity of the subjects and/or groups to which they belong and are discretionary in the sense that if a subject is the owner of an object, the subject can pass its access permissions on to another subject. In a M\AC model, all subjects and objects are classified based on predefined sensitivity levels that are used in the access decision process. Role-based access control (RBAC) models

0-7803-9484-4/05/$20.00 §2005 IEEE

George Papadopoulos University of Patras

environment roles, with the traditional notion of subject roles. Georgiadis et al. [6] introduced the Context-based

932

Team Access Control model (C-TMAC), in which users are associated with contexts, like roles are used to associate users with permissions. Zhang et al. [7] presented the Dynamic Role Based Access Control (DRBAC) model, a context-aware access control mechanism for pervasive applications, which dynamically grants and adapts permissions to users based on their current context. Neumann et al. [8] introduced a framework for a special kind of RBAC constraints, namely context constrains, which are defined as dynamic exogenous authorization constraints. However, the above mentioned research works do not address specifically the e-service provision era. Our work proposes a domain-specific context categorization, based on the requirements imposed by the provision of large-scale e-services. By using the concepts of simple and composite context conditions, a high level of abstraction of the physical environment is achieved, resulting into context interpretation. Also, adequate mechanisms for updating context dynamically are presented. The system architecture and the corresponding operations are presented and the proposed architecture is applied in an example use case. II.

eliminated if utilities had the ability to shift some of the demand from peak to off peak times. In order to achieve this, utilities may offer demand reduction programs to their customers. These types of programs give the customer a monthly credit for allowing the utility to interrupt power to the customer's major loads during peaks or emergencies up to an agreed number of times. This operation is also known as load shedding, and constitutes a power curtailing to loads, such as HVAC compressors, water heaters, etc. Furthermore, the energy management provider (ESP) is able to shift loads in time. This means that the operation of one or more loads is shifted from a time when there is a peak rate to a low rate time. III. ACCESS CONTROL REQUIREMENTs FOR E-SERVICES

The provision of e-services requires that the corresponding SPs have direct access to their customers' information systems, in order to access specific items (resources) related to their business interests. An overview of a typical e-services framework is illustrated in Fig. 1.

E-SERVICE PROVISION

The provision of e-services through the Internet constitutes a new era for service providers (SPs), in order to provide value-added services to their customers, by exploiting the emerging web services infrastructure. Typical types of e-services include preventive maintenance, energy management, security, healthcare services, etc. Throughout this paper we will be based on two e-services of great value both for service providers and customers, namely the preventive maintenance and the energy management services. Many manufacturers of expensive equipment or components have wanted to offer long-term monitoring and maintenance contracts, but the cost of sending out a cadre of engineers to different sites each day on routine system checks was very high. Web services, along with advanced sensor technology, change the equation. The provision of preventive maintenance services can be offered by equipment vendors, which have to monitor a number of operation parameters related to the installed equipment. Each maintenance SP (MSP) monitors and/or controls specific systems/devices, in order to schedule routine service tasks based on real operation data and, furthermore, to avoid potential failures through early detection of malfunction signs, thus providing a higher quality of service. As far as energy services are concerned, the need for a substantial amount of new production assets could be

Fig. 1. E-service provision through the Internet.

Since, these resources usually belong to the same information system, adequate permissions for each resource have to be defined. Each resource, constituting either a simple or a composite service can be accessed as a web service, featuring a WSDL interface. Thus, the access control mechanism must enable the specification of authorizations for every resource starting from a coarse level (e.g., an entire web service) down to a finer level (e.g., a particular method). Also, it would be desirable to specify fine-grained access control authorizations on operation parameters, or even on value ranges for a specific parameter. Normally, there is a different authorization permission set for each SP, concerning resource, operations and operation parameters. However, there are cases, in which different SPs need to perform the same operations on one or more

933

resources. For example, a MSP may control an HVAC system for maintenance purposes, while an ESP may control the same system for energy optimization. Since the same resource has to be controlled by more than one different SP, a conflict situation may arise from issued contradicting commands. Specifically, a switch-on command by the ESP may not be allowed if the MSP has already issued a switch-off command for the same resource. Resolving this conflict requires the incorporation of a new mechanism that will take into account the current situation for access control. Access may depend on the current status of the resource being requested, e.g., a device that has been set in fault state can not be controlled. For some types of applications access may depend not only on the status of the protected resource but, also, on the status of any relevant entities, which have a kind of dependence and interaction with the requested resource. The status of the relevant entities, described as a situation, constitutes the protected resource's environment. Finally, information about past events related to each involved entity and the environment may influence the access decision. Obviously, the status of the requestor is always taken into account for permitting access. This status includes relatively static environment characteristics like, a requestor's affiliation to an organization, etc. and dynamic and often changing attributes like time, location, etc. Thus, any dynamic information that can affect the access control decision has to be taken into account; this information is context. Context may be defined as any information that can be used to characterize the situation of an entity [9]. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves. In general, context is application specific. Concerning the access control requirements imposed by the provision of e-services, context is defined and categorized as: - User context: the status of the user (subject) making a request - Resource context: the status of the resource (object)

capability. A typical authorization policy in RBAC is represented as "User U in role R has permission P". A context-aware access control mechanism is represented as "User U in role R who fulfills constraint C has permission P". A context constraint is defined through the terms context data, context data acquisition and context condition, which is further categorized as simple condition and composite condition, thus forming a multi-level context model: - Context data is defined as any raw data values of the relevant entities (subject, object, environment, history), which affect the access control. These are data at a low level of abstraction, capturing isolated features of a situation, corresponding to single values, e.g., "on vs. off', "value=32", etc. - Context data acquisition is the actual mechanism by which the context data is acquired. Concerning web services, this acquisition is usually accomplished by a web service's operation invocation. - Simple context condition is a predicate that checks the validity of a condition and consists of an operator and two operands. The first operand is context data, while the second one may be either context data or a predefined value. The simple context condition returns a Boolean value (true or false). Actually, this is the mechanism for obtainingfirst-order context information from raw data. - Composite context condition is defined as a regular expression, consisting of Boolean operators and two or more operands. These operands may be simple context conditions and context data of Boolean type. Note that, by its definition, a composite context condition may contain other composite context conditions, as well. Through this mechanism, higher-order context information is obtained, providing several levels of abstraction that relate more to situations than to specific physical values, thus achieving context interpretation. - Context constraint is defined as consisting of one or more (simple or composite) context conditions. A context constraint is fulfilled and returns true if all its constituent context conditions hold. Fig. 2 illustrates the context model for context interpretation that derives meaningful multi-level context information from raw data, through the use of simple and composite context conditions. Under this model, context conditions may consist of several condition combinations, including first- and higherorder conditions, thus forming a mechanism for context fusion. In effect, each composite condition corresponds to a high-level interpretation of the current situation. By using a multi-level hierarchy of context conditions, a high degree of reusability is achieved, since any context condition constitutes an autonomous entity that may be reused to one or more higher-order context conditions.

being requested

the status of any entities relevant to the specific request (resource's environment) - History context: specific previous events and situations, which constitute an additional dimension of context information, including user, resource and - Environment context:

environment history

A. Context Constraints Context has to be incorporated in the access control mechanism, in order to extend the traditional RBAC model to gain many advantages from its context-aware

934

Composite Context Condition

/Cmposite Context Condition

Simple Context Condition

Context Data

Composite CGntxt Conditio

Simple Context Condition

Context Data

0

EThe resource layer consists of the installed devices/systems at the customers' premises, which have .CI to be accessed. Their functionality is exposed as one or 'C:T more web services. The communication of the customers' systems with the intermediary server is °0EZ N achieved through XML-based SOAP messages. The -------client layer consists of the clients, which have access to "I X the resource layer. They may be service providers (SPs) @ end-users. The intermediary server operates as an 0,,°b ¢ and/or isolator, residing between the resource and the client layers, operating as a proxy for the protected endpoint resources. -

m0

H

Simple Context Conditiot

Context Data

Context Dat

A. The Modules ofthe Intermediary Server The proposed security infrastructure, implemented by the intermediary server, comprises four modules: SOAP server, authentication module, authorization module, context module and SOAP client, as shown in Fig. 3. The constituent modules are described below. SOAP server: It constitutes the front-end by which, the intermediary server receives the client requests. As soon as the SOAP server receives a message for a resource access, it formulates a request for an access decision and forwards it to the authentication module. Authentication module: This module receives the data requests coming from the SOAP server and verifies the identities of the users against the database of enrolled identities. In general, for incoming SOAP messages, authentication may be based on common authentication mechanisms, such as IP-based authentication, HTTP basic authentication, etc. Authorization module: The proposed authorization mechanism will be an extension of RBAC, incorporating context-aware capabilities. Depending on the policy associated with the requested resource, the authorization module checks if the user belongs to a role with permissions to access the specific resource. If the role has the proper permissions rights, then the module checks if the role is associated with any context constraint. If the permission has to satisfy a context constraint (context-aware), then the authorization module has to check the fulfillment of this context constraint, by applying a proper request to the context module. Context module: This module, checks if the context constraint associated with a specific request is fulfilled. This check analyzes each context constraint into its constituent context conditions (simple and/or composite) and checks the validity of each of them. The context constraint is fulfilled and returns true if its constituent conditions are fulfilled, otherwise it returns false. The context module collects data, relevant to the context of the protected resources. A way to achieve this is through

Fig. 2. Multi-level context model.

IV. SYSTEM ARCHITECTURE

This section proposes an architecture, which incorporates context into the access control mechanism for an e-services infrastructure. This architecture is based on an intermediary server that sits in front of one or more protected resources (usually web services) and performs, among other operations, the authentication and authorization without modification to the original code (Fig. 3). The intermediary server is to web services security what an IP firewall is to network security, with a number of additional features that add security, reliability, availability, scalability and interoperability to a service without modifying the service itself. In effect, it constitutes an isolation layer between clients and servers, being capable to integrate dissimilar technologies. The architecture consists of three layers: the resource layer, the intermediary server and the client layer. The chosen integration technology for these layers is based on the web services standards (XML, HTTP, SOAP and WSDL), since they constitute the prevailing technologies for enterprise integration. Intermediary Server

Access policies

Users/roles

& perm ss ons l~~~~~~Resource layer on systerns)

S 0 =

>

Client layer (SPs / end users)

(Automa

0UI

°'~

Ln

.

t

nt

~~~~~providers'

SjContext

Context informatiion

Fig. 3. The system architecture.

935

a pull mechanism, in which the context module must explicitly request context information. It can either make this request on a periodic basis (polling) or when a new access request takes place. In a push mechanism, context providers push updated context information to the context module, either in a periodic basis or when a change is detected (event-based). The system may support both models for context acquisition; the ondemand pull model is used for resources that don't require fast response, while the event-based push model is used for resources with demanding requirements, concerning minimization of delays. SOAP client: This module acts as a proxy for forwarding the requests to the remote resources. V.

order context condition. Then thefirst- and higher-order context conditions that constitute the context constraint are defined as follows: * Simple Context Conditions (st order): SCC 1: Request initiated from the ESP site (User domain = "ESP domain") SCC2: HVAC module is operating in heating mode (Operation mode = "Heating") SCC3: HVAC module is operating in cooling mode (Operation mode = "Cooling") SCC4: HVAC module is not on fault state (NOT HVAC Fault-state) SCC5: Air temperature is lower than the upper heating setpoint (Temp < Upper_H_setpoint) SCC6: Air temperature is higher than the lower cooling setpoint (Temp > Lower C_setpoint) SCC7: Last command issued by the MSP is not off a switch command (NOT Switch-off by_MSP)

EXAMPLE USE CASE

This section presents a typical example use case that involves both the ESP and the MSP, which have access to the same installed HVAC system. Suppose that the ESP following a load rotation strategy, after a load curtailment, issues a switch-on command to an HVAC module for resuming operation. This is allowed to be invoked by the ESP, provided that the request initiated from the ESP's site, the HVAC module is not on fault state, the air temperature is lower than the upper limit when heating or higher than a low limit when cooling and a switch-off command has not issued before by the MSP, who has a higher priority for the specific command. Thus, for this operation, the client (ESP) access rights depend on the user context (request from trusted domain), the resource context (HVAC operation status), the environment context (air temperature) and the history context (previous commands issued by the MSP). The procedure for the creation of the access permissions in this use case is as follows. Initially, the authentication method for each resource is defined. Although any authentication mechanism may be used, basic HTTP authentication may be adequate for many cases. Considering an OPC XML-DA infrastructure at the resource layer, each resource may correspond to an OPC item [10]. Then, the entities (users, roles) that will have access to the protected resources are defined; we define the ESP and MSP roles. Each user is assigned to one or more roles and each role is granted permissions to access certain resources. For the example use case, the ESP is allowed to invoke the Write operation of the XML-DA OPC server corresponding ItemName="PLC1.HVACSwitch" with the value="ON", under a specific context constraint, which corresponds to the context model, illustrated in Fig. 4. In effect, the context constraint is identical to the highest-

The simple context conditions belong to the following context categories: user context (SCC1), resource context (SCC2, SCC3, SCC4), environment context (SCC5, SCC6) and history context (SCC7).

E

. SCC2 ,

)main

Operation de

sSCC3SI SCC 4

HA satu

Airtem

SCC5

StCC

SCC7

0

llpper heating Lower coolin

perture

n

..

coma t LasjXi

Fig. 4. Levels of context information.

Composite Context Conditions (higher- order): CCC1: Air temperature within allowable limits for switch-on in heating mode (SCC2 AND

-

SCC5)

-

CCC2: Air temperature within allowable limits for switch-on in cooling mode (SCC3 AND

SCC6)

-

936

CCC3: Air temperature within allowable limits for switch-on (CCC 1 OR CCC2)

The system functionality and the constituent parts of our architecture have been described. A use case example presented the application of our architecture in a typical scenario, involving two service providers, for the provision of both maintenance and energy management services.

CCC4: State and temperature allows the switchon operation (CCC3 AND SCC4) - CCC5: Switch-on operation allowed (SCC 1 AND CCC4 AND SCC7) After the definition of the context constraint, the administrator associates it with the specific permission (switch-on the HVAC module). It is obvious that the multi-level hierarchy of context conditions forms an abstraction level that results into a meaningful representation of the current situation and also, offers a high degree of reusability. During the run-time operation, the access control mechanism receives requests by SPs, which are checked against the configured access rules and eventually either forwarded to the protected resources or rejected, by returning specific error messages. The whole procedure is performed in a completely transparent way. -

VI.

REFERENCES [1]

[2] [3]

CONCLUSIONS

[4]

This paper described a context-aware access control architecture, in order to meet specific requirements, imposed by the provision of e-services, based on an endto-end web services infrastructure. The proposed architecture can control access pernissions to distributed web services, conforning to the WSDL specification, from a coarse to a fine-grained level, through an intermediary server, in a completely transparent way to both clients and protected resources. The access control mechanism is based on an RBAC model, which incorporates dynamic context infornation. Context was classified based on specific requirements imposed by the e-services provision era, into four main categories. The proper combination of two context update mechanisms (pull- and push-mode of operation) results into performance optimization. Simple and composite context conditions were used, in order to obtain context information from raw sensor values (low level) at a high level of abstraction, thus achieving context interpretation. By using a multi-level hierarchy of context conditions, the architecture provides a high degree of reusability. The context-aware access control mechanism is implemented dynamically, by checking the context constraint associated with each access request at the time of the specific request submission.

[5]

[6]

[7]

[8]

[9]

937

N. Damianou, et. al., "A Survey of Policy Specification Approaches", http://www.doc.ic.ac.uk/-mss/Papers/PolicySurvey.pdf. Web Services Description Language (WSDL) 1.1, http://www.w3.org/TR/wsdl. R. Sandhu, D. Ferraiolo, and R. Kuhn, "The nist model for role-based access control: Towards a unified standard", In Proceedings of ACM Workshop on Role-Based Access Control. ACM, July 2000.Elisa Bertino, Piero Andrea Bonatti and Elena Ferrari, "TRBAC: A Temporal Role-Based Access Control Model," ACM Transactions on Information and System Security, Volume 4, No. 3, August 2001, pp. 191-223. Michael J. Covington, Prahlad Fogla, Zhiyuan Zhan, and Mustaque Ahamad, "A Context-aware Security Architecture for Emerging Applications", In Proceedings of the Annual Computer Security Applications Conference (ACSAC), Las Vegas, Nevada, USA, December 2002. Christos K. Georgiadis, loannis Mavridis, George Pangalos and Roshnan K. Thomas, "Flexible Team-Based Access Control Using Contexts," Proceedings of the Sixth ACM Symposium on Access Control Models and Technologies, May 2001, Chantilly, Virginia, USA. G. Zhang and M. Parashar, "Dynamic Context-aware Access Control for Grid Applications", Proceedings of the 4th International Workshop on Grid Computing (Grid 2003), Phoenix, AZ, USA, IEEE Computer Society Press, pp 101 108, November 2003. Gustaf Neumann and Mark Strembeck., "An Approach to Engineer and Enforce Context Constraints in an RBAC Environment," Proceedings of the Eighth ACM Symposium on Access Control Models and Technologies, June 2003, Como,

Italy. Anind K. Dey and Gregory D. Abowd, "Towards a Better Understanding of Context and Context-Awareness", In the Workshop on The What, Who, Where, When, and How of Context-Awareness, as part of the 2000 Conference on Human Factors in Computing Systems (CHI 2000), The Hague, The Netherlands, April 3, 2000. OPC Foundation, OPC XML-DA Specification, vI.0, 2003, http://www.opcfoundation.org.