Context-aware Authorisation

A context-aware authorisation mechanism uses the context of users to authorise (in other words, to control accesses) them for accessing a service. Among many such mechanisms, a few of the most influential ones are presented.

One of the earliest works to propose how contextual information can be incorporated for access control scenarios is Generalized Role Based Access Control (or GRBAC) [44] which is an extension of the popular Role Based Access Control (RBAC) model [45]. In this ap- proach, three different types of roles are defined: Subject Roles (denoted as SRole), Object Roles (denoted as ORole) and Environment Roles (denoted as ERole). Subject roles, similar to the concept of roles in RBAC, represent the role of an individual in a system. Object roles represent different security related properties of an object in a system. Finally, environment roles represent contextual information that expresses the time of day, weather conditions and other spatial and temporal values. Similar to RBAC, GRBAC defines policies that determine which operations (denoted as op) are permitted in a transaction. A transaction is defined as a tuple of <SRole, ORole, ERole, op> which expresses that a subject having SRole is permitted to perform operation op on an object with ORole under the conditions of ERole contextual information. Compared to the commonly used RBAC model, GRBAC is more expressive which makes it suitable for context-aware authorisation schemes. Based on the concept of GRBAC and environment roles, an architecture has been presented in [46] which illustrates the applicability of leveraging contextual information in the form of environment roles to control accesses in a smart home environment. The authors represent environment roles in different forms. For example, the roles of users in the smart homes are represented using a hierarchy of family such as father, mother and siblings. Temporal roles are represented using a hierarchy of day and time whereas spatial roles are represented using internal loca- tions within the smart home such as the first floor, second floor, bedroom, kitchen and so on. Based on these environment roles, the authors have implemented a system that utilises the transaction tuple of GRBAC for controlling accesses to different resources inside the smart home. The smart home has been equipped with sensors to capture the environment roles and the user has the ability to specify policies that dictates which resources are accessible by which roles under what contexts. Even though both these works are influential in nature

2.5. Context-aware Identity Management 26

in the domain of context-aware authorisation, one major problem is that environment roles introduce complexities in administering policies which in turn makes it difficult to ensure that the policies are conflict free. In addition, a large number of environment roles makes the system very difficult to manage manually.

To tackle this problem, Zhang and Parashar have proposed a Dynamic RBAC (DRBAC) model [47] by extending the traditional RBAC model. The model adjusts static roles and permission assignments dynamically using contextual information. The DRBAC consists of several components:

• USERS representing the set of entities who try to access services from a service provider.

• ROLES representing the set of roles that users can assume in a service provider.

• PERMS representing the set of permissions for accessing one or more resources in the provider.

• ENVS representing the contextual information of a user in the system.

DRBAC defines different rules to assign roles (from the ROLES set) to a user (from the USERSset) and permissions (from the PERMS set) to resources and uses policies to deter- mine which user having what roles can access which resource(s). One of the striking features of DRBAC is its capability to capture the changes of the environment in the system and of the user and to enforce permissions accordingly. For example, a user having roles r1 and r2

can assume role r1 only if she is at location l1 and can assume role r2 only if she is at loca-

tion l2. Depending on the roles at a particular context, the user is allowed to access particular

resources. One limitation of the proposal is its lack of any explanation on how the location of a user would be detected by the provider. In addition, there is no discussion if the proposal can be used for identity management.

None of these works consider how to verify the authenticity and validity of contextual in- formation. To overcome this limitation, a context sensitive access control architecture was defined in [48]. The architecture introduces several components including Context Owner (CO), Context Provider (CP), Context Broker (CB), and Context-aware Service Provider (CASP). A CO is the owner of the contextual information that is collected from different sources. It is solely responsible for deciding when, why, how and where contextual infor- mation is released, and who can store such information. A CP is responsible for ensuring different contextual information is released as per the requirements of the CO of the re- spective information. A CASP is responsible for providing services to a user, based on her context. The authors provide a detailed protocol flow using their architecture and explain the mechanism for verifying the validity and authenticity of contextual information. The major problem of the architecture is the reliance on several external parties which may be difficult

2.5. Context-aware Identity Management 27

to implement for federated services considering different security domains and trust issues. Also, it is unclear how their proposal can be used for identity management.

The authors in [49] have proposed a model describing how contextual information can be included during an authorisation process in highly dynamic environments. Contextual in- formation is provided by different devices which are regarded as observers. The validity of the contextual information is verified by a trusted third party. The defined model consists of contextual conditions which are tuples of the form (<context, operation, object>) and dic- tates which entity with which context can perform which action on which object. A user is authorised to perform the specified operation on the respective object only if the context is valid. The authorisation decision also includes several conditions that are combined us- ing logical rules. Their model of tuple is similar to the eXtensible Access Control Markup Language (XACML) model [50] and does not provide any additional advantages over the XACML model.