Cluster Computing 9,19–27,2006
C 2006Springer Science +Business Media,Inc.Manufactured in The United
States.
SESAME:Scalable,Environment Sensitive Access Management Engine
GUANGSEN ZHANG and MANISH PARASHAR
The Applied Software Systems Laboratory (TASSL),Dept.of Electrical and Computer Engineering,Rutgers University,94Brett Road,Piscataway,NJ 08854
Abstract.As computing technology becomes more pervasive and mobile services are deployed,applications will need flexible access control
mechanisms.Although lots of researches have been done on access control,these efforts focus on relatively static scenarios where access depends on identity of the subject.They do not address access control issues for pervasive applications where the access privileges of a subject not only depend on its identity but also on its current context and state.In this paper,we present the SESAME dynamic context-aware access control mechanism for pervasive applications.SESAME complements current authorization mechanisms to dynamically grant and adapt permissions to users based on their current context.The underlying dynamic role based access control (DRBAC)model extends the classic role based access control (RBAC).We also present a prototype implementation of SESAME and DRBAC with the Discover computational collaboratory and an experimental evaluation of its overheads.Keywords:security,access control,context-aware,pervasive computing,role based
1.Introduction
Pervasive computing and communication technologies are rapidly weaving themselves into the fabrics of everyday life and have the potential for fundamentally redefining the way we interact with information,each other,and the world around us.The proliferation of smart gadgets,mobile devices,PDAs and sensors has enabled the construction of pervasive comput-ing environments,transforming regular physical spaces into intelligent spaces [7].Such intelligent spaces provide services and resources that users can access and interact with via per-sonal portable devices such as a PDA using short-range wire-less communications such as Bluetooth or IEEE 802.11.The resulting anytime-anywhere access infrastructures is enabling a new generation of applications that can leverage this per-vasive information Grid to continuously manage,adapt and optimize.One example of such an application is the Aware Home project at Georgia Institute of Technology [10].Sen-sors in the home can capture,process and store a variety of information about its residents and their activities,enabling the Aware Home application to detect and respond to events in the room.Another application is the Intelligent Room project at MIT.In this application,computers are embedded in a room so that people can interact with computers the way they do with other people,using speech,gesture,movement and con-text [14].Other applications are described in [4,9].Such pervasive applications are characterized by continuous perva-sive access to information,resources and services and ad hoc,dynamic interactions between participating entities,and lead to significant research challenges.
One key challenge in pervasive applications is managing security and access control.Access Control List (ACL)is a very commonly used access control mechanism.In this ap-proach,permission to access resources or services is moder-ated by checking for membership in the access control list associated with each object.However,this strategy is inade-quate for pervasive applications as it does not consider con-text information.In a pervasive environment,users are mobile and typically access resources (information,services,sensors,etc.)using mobile devices.As a result the context of a user (i.e.location,time,system resources,network state,network security configuration,etc.)is highly dynamic,and granting a user access without taking the user’s current context into account can compromise security as the user’s access privi-leges not only depend on “who the user is”but also on “where the user is”and “what is the user’s state and the state of the user’s environment”.As a result,even an authorized user can damage the system as the system may have different secu-rity requirement within different contexts.Traditional access control mechanisms such as access control list break down in such an environments and a fine-grained access control mech-anism that changes the privilege of a user dynamically based on context information is required.
Although a lot of work has been done in the area of ac-cess control,most of this work is user-centric,where only credentials of the user are considered when granting access permission.Relativel
y little research has been done to com-bine context information with credentials while making ac-cess control decisions.The existing research however does not address pervasive applications where context is dynamic and a user’s privileges must continuously adapt based on the context.
This paper presents a dynamic context-aware access con-trol mechanism that dynamically grants and adapts permis-sions to users according to current context.The proposed mechanism extends the role based access control (RBAC)model [3],while retaining its advantages (i.e.ability to define and manage complex security policies).The model dynami-cally adjusts Role Assignments and Permission Assignments based on context information.In our approach,each user is assigned a role subset (by the authority service)from the en-tire role set.Similarly the resource has permission subsets for
20ZHANG AND PARASHAR each role that will access the resource.During a secure in-
teraction,state machines are maintained by delegated access
control agents at the subject(Role State Machine)to navigate
the role subset,and the object(Permission State Machine)to
navigate the permission subset for each active role.The state
machine consists of state variables(role,permission),which
encode its state,and commands,which transform its state.
These state machines define the currently active role and its
assigned permissions and navigate the role/permission subsets
to react to changes in the context.
The rest of this paper is organized as follows:Section2
presents background and related work.Section3outlines a
motivating application.Section4presents the proposed dy-
namic context-aware access control model.Section6presents
a short discussion about the model and its implementation.
Section7concludes the paper.
2.Background and related work新知
Role based access control(RBAC)[3,16]is an alternative to
traditional discretionary(DAC)and mandatory access control
(MAC).In RBAC,users are assigned roles and roles are as-
signed permissions.A principle motivation behind RBAC is
the ability to specify and enforce enterprise specific security
policies in a way that maps naturally to an organization’s struc-
ture.As user/role associations change more frequently then
role/permission associations,in most organizations,RBAC
results in reduced administrative costs as compared to asso-
ciating users directly with permissions.It can be shown that
the cost of administrating RBAC is proportional to U+P
while the cost of associating users directly with permissions
is proportional to U∗P,where U is the number of individuals
in a role and P is the number of permissions required by the
role.Sandhu et al.[3,16]define a comprehensive framework
for RBAC models which are characterized as follows:
r RBAC
:the basic model with users associated with roles
and roles associated with permissions.
r RBAC
1:RBAC0with role hierarchies.
r RBAC
2
:RBAC1with constraints on user/role,role/role, and/or role/permission associations.
Recently RBAC was found to be the most attractive so-lution for providing security features in different distributed computing infrastructure[16].Although the RBAC models vary from very simple to pretty complex,they all share the same basic structure of subject,role and privilege.Other fac-tors such as relationship,time and location,which may be part of an access decision,are not considered in making ac-cess control decision in these models.In this paper,we extend RBAC0to provide context-aware access control mechanisms for pervasive applications.
Giuri and Iglio[5]have proposed a role-based access con-trol model that provides special mechanisms for the definition of content-based access control policies.By extending the no-tion of permission,they have allowed for the specification of security policies in which the permission of an object may depend on the content of the object itself.For example,in a health-care organization,the physician is only allowed to access and modify patient records related to his or her patient.
Woo and Lam[19]designed a distributed authorization service using their Generalized Access Control Language (GACL).In their design,they use the notion of system load as the determining factor in certain access control decisions, so that,for example,certain programs can only be executed when there is enough system capacity available.
Finally,Michael J.Covington et al.[10,11]have proposed the Generalized Role Based Access Control(GRBAC)model. In this model,they extend the traditional RBAC by applying the roles to all the entities in a system.(In RBAC,the role concept is only used for subjects).By defining three types of ,Subject roles,Environment roles,and Object roles, GRBAC uses context-information as a factor in making access decisions.
All of the research efforts described above take additional factors into consideration when make access control decision. However,both Giuri,Iglio and Woo,Lam don’t consider con-text information as a key factor in their access control mech-anism.In GRBAC,the definition of environment roles allows the model to partially address problem we described,but it may not be feasible in practice because the potential large amount of environment roles make the system hard to main-tain.Also,by defining too many roles in the system,it loses the advantage that RBAC provides.
3.Access control challenges for pervasive applications To illustrate the motivation of our research,let us discuss an ex-ample application that will be enabled by a pervasive comput-ing infrastructure in a smart building of a university,as illus-trated infigure1.The building has many rooms including fac-ulty offices,administration offices,conference rooms,class-rooms and laboratories.Sensors in the building can capture, process and store a variety of information about the building, the users and their activities.Pervasive applications in such an environment allow faculty,staff,students and
administrators
Figure1.Smart building application.
SCALABLE,ENVIRONMENT SENSITIVE ACCESS MANAGEMENT ENGINE21田间持水量
to access resources/information from any locations at anytime while inside this building using mobile devices(PDAs)and wireless networks.While user credentials are still the basis for all the access control decisions,user’s context information and application state should also be considered.For exam-ple,a student can only control the audio/video equipment in a classroom if she/he is scheduled to present in that class at that time by the faculty in charge.Similarly the payroll server should not be allowed to access if its load is above80%or if the access is over an insecure link.In such applications,privileges assigned to the user will change as context changes.If the user is accessing the resource while the user’s context information is changing(say the moves from a secure network link to an insecure link),specific access control mechanisms are needed to ensure that system/application security and consistency are maintained without decreasingflexibility.
The examples above embody many of the key ideas of the research presented in this paper.To maintain system security for such a pervasive application,we have to dynamically adapt access permissions granted to users as context information for the session changes.Context information her
e includes envi-ronment of the user such as location,time that the user access the resource and system information such as CPU usage and network bandwidth.The traditional RBAC models[3]do not directly address the requirements of such an application.In the RBAC model,the user is assigned a subset of roles when the user begins a session.This subset of roles are then used to access resources.During a session,although roles can be activated or deactivated based on constraints such as role con-flict or prerequisite roles,the user’s access privilege is not changed based on context information.Recently,Michael J. Covington et al.,have proposed the GRBAC model[11]that used context to provide access control for Aware Home ap-plications.However,the definition of environment role is not feasible for pervasive applications as described in the previous section.
4.Dynamic role based access control model用
发展的
眼光看中国
Dynamic Role Based Access Control model(DRBAC)ad-dresses the dynamic access control requirement of applica-tions in pervasive environments.It extends the traditional Role Base Access Control(RBAC)model to use dynamic context information while making access control decision.Specifi-cally,DRBAC addresses two key requirements motivated by the application in Section3:(1)A user’s access privileges must change when the user’s context changes.(2)A resource must adjust its access permission when its system ,network bandwidth,CPU usage,
memory usage) changes.In this section,wefirst formally define DRBAC and then describe its operation.
4.1.DRBAC Definition
The DRBAC definition is based on the RBAC formalism pre-sented in[8].DRBAC has the following components:
r USERS.A user is an entity whose access is being con-trolled.USERS represents a set of users.
r ROLES.A role is a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role.ROLES represents a set of roles.
r PERMS.A permission is an approval to access one or more RBAC protected resources.PERMS represents a set of permissions.
r ENVS.ENVS represent the set of context information in the system.We use an authorized“Context Agent”to collect context information in our system.
r SESSIONS.A session is a set of interactions between sub-jects and objects.A user is assigned a set of roles during each session.The active role will be changed dynamically among the assigned roles for each interaction.SESSIONS represents a set of sessions.
r UA.UA is the mapping that assigns a role to a user.In the session,each user is assigned a set of roles,the context information is used to decide which role is active.The user will access the resource with the active role.
r PA.PA is the mapping that assign permissions to a role.
Every role that has privilege to access the resource is as-signed a set of permissions,and the context information is used to decide which permission is active for that role.
The model is illustrated infigure2.In the approach,a Central Authority(CA)maintains the overall role hierarchy. When the user logs on the system,based on the user’s capa-bility,a subset of the role hierarchy is assigned to the user for each session.Then the CA sets up an agent for that user and delegates the user’s right to that agent.The agent will monitor the environment status of the user and dynamically change the active role of the user.Every resource maintains a set of permission hierarchies for each potential role that will access the resource.The resource maintains its environme
nt and dynamically adjusts the permissions for each role.We summarize the above discussions below:
DRBAC Definition:
–USERS,ROLES,PERMS,ENVS and SESSIONS(users, roles,permissions,environments and sessions,respec-
tively).
Figure2.Dynamic access control model.
22ZHANG AND PARASHAR –ACT RO L E and ACT P E RM I SSI O N(active role
and active permission respectively).
–UA⊆USERS×ROLES,a many-to-many mapping user-to-
role assignment relation.
–PA⊆PERMS×ROLES,a many-to-many mapping
permission-to-role assignment relation.
–Assigned roles(u:USERS,e:ENVS)→2ROLES,the map-
ping of user u onto a set of roles.
–Assigned permissions(r:ROLES,e:ENVS)→2PERMS,the
mapping of role r onto a set of permissions.
–User sessions(u:USERS)→2SESSIONS,the mapping of
user u onto a set of sessions.
–Session roles(s:SESSIONS)→2ROLESS,the mapping of
session s onto a set of roles.Formally:session roles(s i)
⊆{r∈ROLES|(session roles(s i),r)∈UA}
–RH⊆ROLES×ROLES is a partial order on ROLES called
the inheritance relation,written as≥,where r1≥r2only
if all PERMS of r2are also PERMS of r1,and all users of
r1are also users of r2.
–PH⊆PERMS×PERMS is a partial order on PERMS
called the inheritance relation,written as≥,where p1≥
p2only if all permissions of p2are also permissions of p1,
and all roles of p1are also roles of p2.
4.2.DRBAC explained
In DRBAC,each user is assigned a role subset from the en-
tire role set.Similarly,each resource will assign a permission
极端主义subset from the entire permission set to each role which has a
privilege to access the resource.Figure3illustrates the rela-
tionship between the role hierarchy maintained at the Central
Authority(CA)and the role hierarchy assigned to a particular
user.It can be seen that the role hierarchy a user is a subset of
the overall role hierarchy.
State machines maintain the role subset for each user and
the permission subset for each role.A state machine consists
of state variables,which encode its state,and events,which
transform its state.In DRBAC,there is a Role State Machine
for each user,and a Permission State Machine for each role.
The role and permission are used as state variables respec-
tively.The Context Agent collects context information and
generates pre-defined events to trigger transitions in the
state
Figure3.Role hierarchy state
machine.
Figure4.Permission hierarchy state machine.
machines.A permission state machine is illustrated infig-
ure4.
A null permission implies no permission.A transition is
defined as T(Initial State,Destination State).So T(P1,P2)
represents the transition from P1to P2and T(P2,P1)rep-
resents the transition from P2to P1.The Role State Machine
is similar to the Permission State Machine.
4.3.DRBAC operation
The operation of DRBAC is illustrated using the example pre-
sented in Section3.In this example,when Professor B logs
on the system in her office with a PDA,the central authority
assigns her a subset of roles,for example,Professor,Lec-
turer and Faculty,based on her credentials.Then the central
authority also sets up an access control agent on her PDA,
which maintains the role state machine.Events issued by the
context agent will trigger transitions between the roles in the
role state machine.Now,consider a security policy that de-
fines B’s active role as Professor when she is in the office(see
figure5,where the dashed circle is the active role),and de-
fines the transition as:Change role from Professor to Faculty
when professor B leaves her office.
When professor B accesses the resource in her office,the
active role Professor is used.The resource maintains the per-
mission state machines as shown infigure 6.Thefigure
shows that each of the roles,Professor,Faculty and Lecturer,
have their own permission state machines.The dashed circle
represents the current active permission for each role.The
null means the role does not have permission to access the
resource.Similar to the role state machine,the context agent
at the resource will trigger transitions in the permission state
machine.In this example,we assume that the active
permis-
Figure5.Role hierarchy for the smart building.
SCALABLE,ENVIRONMENT SENSITIVE ACCESS MANAGEMENT ENGINE
23
Figure6.Permission hierarchy for the resource.
sion of the role professor is P1while the system load of the resource is low.P1means both read and write privilege.The security policy for the resource may define a permission tran-sition for role professor as:Transit permission from P1to P2 when the system load is high.The permission P2means only read privilege.
Based on the situations defined above,we can describe some scenarios to illustrate dynamic access control.
r When professor B moves out of her office,the context agent will send an event to the access control agent on her PDA.This event will trigger a transition in the role state machine,changing her active role to Faculty.As a result, professor B will not be able to write to resource once she leaves her office as role Faculty only has the permission P2or null.
r When professor B accesses the resource in her office,her active role is professor,which has both read and write privilege on the resource as long as the system load of the resource is low.If the system load becomes critically high,the resource permission state machine will change the active permission for professor B’s role professor to P2and she will lose the privilege to write the resource.
From the scenarios described above,we see that DRBAC can enhance the security of the pervasive applications.The DRBAC mechanism implemented in this application guaran-tees that professor B’s privilege to access the resource will be changed dynamically when the context changes.Using context information to change the user’s privileges prevents resources from being incorrectly used.
5.SESAME/DRBAC prototype implementation
A prototype of SESAME and the DRBAC model has been implemented as part of the Discover[2,18]computational collaboratory.Discover is a Grid-based computational col-laboratory that
enables geographically distributed scientists and engineers to collaboratively access,monitor,and control distributed applications,services,resources and data on the Grid using pervasive portal.Key components of the Discover collaboratory include:
r Discover Collaborative Portals[18]that provide users with pervasive and collaborative access to Grid applica-tions,services and resources.Using these portals,
users
Figure7.Dynamic access control in discover.
can discover and allocate resources,configure and launch applications and services,and monitor,interact with,and steer their execution.
r Discover Middleware Substrate[2,12]that enables global collaborative access to multiple,geographically dis-tributed instances of the Discover computational collab-oratory,and provides interoperability between Discover and external Grid services such as those provided by Globus[15].
r DIOS Interactive Object Framework(DIOS)[13]that en-ables the runtime monitoring,interaction and computa-tional steering of Grid applications and services.DIOS enables application objects to be enhanced with sensors and actuators so that they can be interrogated and con-trolled.
An overview of the integration of SESAME and DR-BAC with Discover is presented infigure7.SESAME ensures the users can access,monitor and steer Grid re-sources/applications/services only if they have appropriate privileges and capabilities.As Discover po
rtals are perva-sive and the Grid environment is dynamic,this requires dy-namic context aware access management.Note that authen-tication services are provided by GSI[6]in our prototype implementation.
In our implementation,users entering the Discover collaboratory using the portal are assigned a set of roles when they log in.A Role State Machine is then locally set up for each user,which dynamically adjusts the active role based on events from the local context agent.Similarly,the Permission State Machines are set up at the application(or ser-vice/resource)for each role that will access it.The Permission State Machines similarly adjust the active permissions based on events from the local context agent.The context agents are authorized by the central authority using GSI delegation mechanisms.The access control policy is stored in the policy repository,which is maintained by an Authentication&Au-thorization Service within Discover Middleware Substrate. Polices are specified in XML and define role/permission assignments and transitions as illustrated infigure8.
24ZHANG AND
PARASHAR
Figure8.Sample RoleTransition policy in XML. Policies defined for our implementation include UserP
olicy, RoleHierarchyPolicy,RoleAssignmentPolicy,Permission-AssignmentPolicy,EventPolicy,RoleTransitionPolicy and PermissionTransitionPolicy.
In our prototype implementation,we assume that a secu-rity administrator will guarantee the correctness of a policy for a object or subject—i.e.SESAME sets up the Role State Machines and Permission State Machines without considering checking them for errors or conflicts.There are no inherent constraints on the number of roles and permissions,or on the relationships betweens the roles or permissions.To illus-trate our implementation,consider a simple example with a single user with three roles and a Grid resource with three permissions,as shown in Table1and2respectively.The role and permission hierarchies for this example are shown in figure9.
We consider two types of context information in our im-plementation:(1)Object context such as a user’s location, time,local resource state and link state,and(2)Subject con-text,such as the current load,availability,connectivity for a resource.Context agents build on existing Grid middleware services.For example object context can be collected using the Context Toolkit[1]and subject context can be obtained using NWS[17].
Table1
Permission assignments for the example.
Role Permissions Super user P1,P2,P3 Basic user P2,P3 Guest P3
Table2
Permission definition for the example.
sce
Permission Privileges
P1Steer Object,View Object,Basic P2View Object,Basic
P3
Basic
Figure9.Role and permission hierarchies for the example.
5.1.SESAME/DRBAC operation
The operation of the prototype is illustrated using a set of simple scenarios.These scenarios,although somewhat con-trived,demonstrate the effectiveness and utility of the DRBAC model for Grid applications.For each of these scenarios,con-sider a user(say N)equipped with a mobile devices such as a PDA,and involved in collaboration scientific investigation using Discover.Assume that the user’s environment is part of the pervasive Grid environment with appropriate middleware services.
Assume that user N logs into the system using her PDA. Based on her credentials,the Authentication&Authorization service assigns her a set of roles.The Authority Service also sets up an access control agent on her PDA,which main-tains the role state machine.A DRBAC policy defined to select an appropriate role based on the level of security of her wireless her active role is Super User while the network is in her laboratory or of-fice)and is Basic User if it is insecure.The correspond-ing EventPolicy and RoleTransitionPolicy may be defined as follow:
–EventPolicy—Generate event insecure when N’s link has no encryption.
女体
解剖授业–RoleTransitionPolicy—Transit role from Super User to Basic User when event insecure is generated.
A corresponding permission state machine is maintained on the application side as shown infigure10.As seen in thefigure each role has its own permission state machine.The dashed circle represents the current active permission for each role.A DRBAC policy is defined so that the active permission of the role Super User is P1while load is low and P2when the system load increases above some threshold,as there is a possibility that the application may get corrupted.The cor-responding EventPolicy and PermissionTransitionPolicy may be defined as follow:
–EventPolicy—Generate event highload when load in-creases above Threshold.
–PermissionTransitionPolicy—Transit permission from P1 to P2when event highload is generated.
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议