STRoBAC – Spatial Temporal Role Based Access Control

11
STRoBAC – Spatial Temporal Role Based Access Control Kim Tuyen Le Thi 1 , Tran Khanh Dang 1 , Pierre Kuonen 2 , and Houda Chabbi Drissi 2 1 HCMC Univerisity of Technology, VNU HCMC, Ho Chi Minh City, Vietnam {tuyenltk,khanh}@cse.hcmut.edu.vn 2 College of Engineering and Architecture, Fribourg, Switzerland {pierre.kuonen,Houda.Chabbi}@hefr.ch Abstract. The development of geography-based services and systems has created the demands in which access control is the primary concern for geospatial data security. Although there are a variety of models to manage geospatial data access, none of them can fulfil the access control requirements. The objective of this paper is to propose a model that can support both spatio-temporal aspects and other contextual conditions as well as access control based on the role of subject. We call this model Spatial Temporal Role Based Access Control (STRoBAC). In addition, we propose an extension of GeoXACML framework, which is highly scal- able and can help in declaring and enforcing various types of rules, to support the proposed model. This is the crucial contribution of our re- search compared to the existing approaches and models. Keywords: Access Control Model, GeoXACML, GIS Database, Or- BAC, Spatio-temporal Data, STRBAC, STRoBAC. 1 Introduction Geographic Information System (GIS) is the technology integration of hardware, software, and data for capturing, managing, analyzing, and displaying geograph- ical information (e.g. buildings, streets, cities) [23]. Its applications have been widely developed and used in many fields (e.g. land and resource management, market analysis, geographic data browsing) [19]. However, the rapid growth of geography-based services and systems may pose serious threats to national se- curity and personal privacy. Furthermore, geospatialdata is very sensitive, espe- cially locations of government buildings, military camps, etc. [1]. Therefore, the need to build an access control model to protect geographical data and prevent unauthorized dissemination is really necessary and urgent. The current models for geospatial data are often based on the characteristics of geospatial objects or subjects (e.g. feature type, specific area of object, loca- tion of requester, his/her roles within the valid area, etc.). Nevertheless, they do not provide the specification and enforcement of security policies supporting fully the kinds of restrictions. For instance, GeoXACML [10], SDE [9] or View N.-T. Nguyen et al. (Eds.): ICCCI 2012, Part II, LNAI 7654, pp. 201–211, 2012. c Springer-Verlag Berlin Heidelberg 2012

Transcript of STRoBAC – Spatial Temporal Role Based Access Control

STRoBAC – Spatial Temporal Role

Based Access Control

Kim Tuyen Le Thi1, Tran Khanh Dang1, Pierre Kuonen2,and Houda Chabbi Drissi2

1 HCMC Univerisity of Technology, VNU HCMC, Ho Chi Minh City, Vietnam{tuyenltk,khanh}@cse.hcmut.edu.vn

2 College of Engineering and Architecture, Fribourg, Switzerland{pierre.kuonen,Houda.Chabbi}@hefr.ch

Abstract. The development of geography-based services and systemshas created the demands in which access control is the primary concernfor geospatial data security. Although there are a variety of models tomanage geospatial data access, none of them can fulfil the access controlrequirements. The objective of this paper is to propose a model that cansupport both spatio-temporal aspects and other contextual conditions aswell as access control based on the role of subject. We call this modelSpatial Temporal Role Based Access Control (STRoBAC). In addition,we propose an extension of GeoXACML framework, which is highly scal-able and can help in declaring and enforcing various types of rules, tosupport the proposed model. This is the crucial contribution of our re-search compared to the existing approaches and models.

Keywords: Access Control Model, GeoXACML, GIS Database, Or-BAC, Spatio-temporal Data, STRBAC, STRoBAC.

1 Introduction

Geographic Information System (GIS) is the technology integration of hardware,software, and data for capturing, managing, analyzing, and displaying geograph-ical information (e.g. buildings, streets, cities) [23]. Its applications have beenwidely developed and used in many fields (e.g. land and resource management,market analysis, geographic data browsing) [19]. However, the rapid growth ofgeography-based services and systems may pose serious threats to national se-curity and personal privacy. Furthermore, geospatial data is very sensitive, espe-cially locations of government buildings, military camps, etc. [1]. Therefore, theneed to build an access control model to protect geographical data and preventunauthorized dissemination is really necessary and urgent.

The current models for geospatial data are often based on the characteristicsof geospatial objects or subjects (e.g. feature type, specific area of object, loca-tion of requester, his/her roles within the valid area, etc.). Nevertheless, theydo not provide the specification and enforcement of security policies supportingfully the kinds of restrictions. For instance, GeoXACML [10], SDE [9] or View

N.-T. Nguyen et al. (Eds.): ICCCI 2012, Part II, LNAI 7654, pp. 201–211, 2012.c© Springer-Verlag Berlin Heidelberg 2012

202 K.T. Le Thi et al.

based [9] access control do not mention about role or spatial characteristics ofsubjects. Meanwhile, GeoRBAC [3] proposes the access control based on the as-signed relations between spatial roles, privileges and users. Notable are STRBAC[7] provides the concept of spatio-temporal aspects, and Or-BAC [2] proposesthe way of expressing contextual conditions (including spatial and temporal con-ditions). However, they are just ideas and do not propose specific solutions forimplementing. The remainder of this paper represents related concepts, detailsabout STRoBAC model and an extension of GeoXACML to support this model.

2 Related Works

2.1 Spatial Temporal Role Based Access Control (STRBAC)

STRBAC is an extension of RBAC (Role Based Access Control) model thatsupports temporal and location constraints [7]. For the spatial aspect, STRBACuses the definition of raw location (or physical location which can be the sig-nal from the user’s mobile, infra-red sensor or GPS device) and logical location.STRBAC limits the access of resources from a particular set of pre-defined lo-cations: Location-by-Address (according to physical location), Location-by-Use(associate location with its usage), Location-by-Organization (distinguish loca-tion based on the organization level), and User-Defined Location (for other pur-poses). For the temporal aspect, STRBAC proposes particular time intervals.Time is described by particular date is called non-recurring interval (e.g. eachdate has the start date and end date). On the other hand, recurring interval isrepresented by particular interval (e.g. daily, weekly, monthly and yearly).

In summary, STRBAC combines both spatio-temporal factors into access con-trol data; however, it is just an idea and not provides the restrictions on user-rolebinding. Another issue is deactivating user role automatically as soon as he/shemoves to the place where his/her role does not satisfy the constraints.

2.2 Organization Based Access Control (Or-BAC)

OrBAC defines permissions (or obligations, prohibitions) that apply within or-ganization to control the activities performed by roles on views [2]. And hence, toactivate a given access control, the subject must be assigned to a given role, theobject must be used in a given view and the action must partake in some activ-ities. Beside these conditions, there are extra conditions that are called context,such as spatial or temporal requirements and other contextual conditions.

There are eight basic sets of entities in Or-BAC: Org (a set of organization),S (a set of subjects), A (a set of actions), O (a set of objects), R (a set of roles),A (a set of activities), V (a set of views) and C (a set of contexts). An accesscontrol policy can be represented by a set of rules having the following forms:

∀s, ∀α, ∀o, (Condition→ Is permitted(s, α, o))

STRoBAC 203

which means every subject s ∈ S is permitted to perform action α ∈ A on objecto ∈ O, if a given condition is satisfied (similarly for Is prohibited, Is obligedand Is dispensed). The determinant in the form is Condition which is definedby the conjunction of variety kinds of condition and constraints:

cond subject(s) ∧ cond action(α) ∧ cond object(o) ∧ constraint(s, α, o)where:

cond subject(s) is condition of subject s (s is empowered in a role or not). Or-BAC provides the built-in predicate Empower to represent this conditionover domains Org × S ×R. If org is organization, s is subject and r is role,Empower(org, s, r) means that org empowers s in r.

cond action(α) is condition of action α. Similar to Empower predicate, overdomains Org×A×A, predicate Consider(org, α, a) means that org considersaction α implements activity a.

cond object(o) is condition of object o. Over domains Org × O × V , predicateUse(org, o, v) means that org uses object o in view v.

constraint(s, α, o) is extra condition (or context) that joins subject s, action αand object o. Satisfying the constraint is necessary to active the rule. Overdomains Org × S × A × O × C, predicate Hold(org, s, α, o, c) means thatwithin organization org, context c holds between s, α and o.

Let us consider the rule “a person who works in the Department of Defence ispermitted to access the important defensive position on specific map layer if he isstanding in his office”, which cond subject(s), cond action(α) and cond object(o)respectively is: s is a person who works in the Department of Defence, α is anaction of accessing and o is a specific map layer. Meanwhile, constraint(s, α, o)is position of s must be within the area of s’s office. Now, the policy can bemodelled by the general rule Concrete Permission Derivation:

∀org ∈ Org, ∀s ∈ S, ∀α ∈ A, ∀o ∈ O, ∀r ∈ R, ∀a ∈ A, ∀v ∈ V , ∀c ∈ CPermission(org, r, α, v, c) ∧Empower(org, s, r) ∧ Use(org, o, v) ∧Consider(org, α, a) ∧Hold(org, s, α, o, c)→ Is permitted(s, α, o)

that is in the organization org, if (1) role r has permission to perform activitya on view v within context c, and (2) org empowers subject s in role r, and(3) org uses object o in view v, and (4) org considers that action α implementsactivity a, and (5) context c holds between s, α, and o, then s is permittedto perform action α on object o. Three similar general rules respectively calledConcrete Prohibition, Obligation and Dispensation Derivation are used to deriveinstances of Is prohibited, Is obliged and Is dispensed.

In addition, Or-BAC defines context algebra to build conjunctive (c1&c2),disjunctive (c1 ⊕ c2) and negative (c) contexts from elementary contexts.

∀org ∈ Org, ∀s ∈ S, ∀α ∈ A, ∀o ∈ O, ∀c ∈ C, ∀c1 ∈ C, ∀c2 ∈ C,Hold(org, s, α, o, c1&c2)← (Hold(org, s, α, o, c1) ∧Hold(org, s, α, o, c2))Hold(org, s, α, o, c1 ⊕ c2)← (Hold(org, s, α, o, c1) ∨Hold(org, s, α, o, c2))Hold(org, s, α, o, c)← ¬(Hold(org, s, α, o, c)

204 K.T. Le Thi et al.

In summary, although Or-BAC supports many different types of condition (moredetails are presented in [2]), beside the weakness that not propose a specific so-lution to implement the model, Or-BAC is sometimes not possible to express allthe possible conditions. For instance, the medical context of urgency, there aremany different possibilities so that it is actually impossible to provide an exhaus-tive definition of such a context. Next section will present a brief introductionabout XACML and GeoXACML, the most suitable declaration and enforcementlanguage for implementing access control model.

2.3 eXtensible Access Control Markup Language (XACML)

XACML is an standard of Organization for the Advancement of StructuredInformation Standards (OASIS), that describes both policy and access controldecision request/response language [12]. The policy language is used to describesgeneral access control requirements with standard extension points (functions,data types, combining logic, etc.). Meanwhile, the request/response languageallows user to form a query asking a given action should be allowed or not. Thereare some basic elements of XACML can be mentioned: PolicySet contains otherPolicies or PoliciySets; Policy expresses a single access control policy through aset of Rules; Target element is used to find a policy that can apply to a givenrequest; Attribute is named value of know type and represents the characteristicsof the objects; and Attribute Values is the specific value of Attribute (name ofuser, the file which user want to access, the time of day, etc.).

Differences between XACML Version 2.0 and 3.0. Compared with ver-sion 2.0, XACML 3.0 has several advantages [13]. Firstly, version 3.0 supportsto express more flexible for Target element. The whole schema of core XACML2.0 and 3.0 [15][16] and an example about Target element [13] will provide aclearer view. Secondly, user can customize the categories to extend some othercontextual conditions instead of using the final set of categories (e.g. emergencycategory). In addition, version 3.0 defines Advice element which is analogousto Obligation. The obligation and the value of obligation id and arguments areforced to interpret; meanwhile it is optional for advice. In other words, obliga-tions were static in the sense that we could not convey the value of an attributethat may change at runtime. The next advantage is the ability to delegate ad-ministrative rights. Namely, a global administrator can delegate constrained ad-ministrative rights to local administrators. And finally, multiple aspects on anycategory can be allowed (version 3.0), instead of only multiple resources (version2.0). For instance, it is possible to ask “Can I view resource 1 and can I viewresource 2?” in version 2.0 and “Can I view and edit resource 1?” in version 3.0,which the reply can be “Permit to view and Deny to edit”. However, XACML 2.0and all the associated profiles were approved as OASIS Standards on February1, 2005 [14]; meanwhile version 3.0 still in progress. But with mentioned ad-vantages, version 3.0 can support to describe policy and request/response moreflexible and suitable to express the contextual conditions of the proposed model.

STRoBAC 205

An Extended RBAC Profile of XACML. To support role based accesscontrol, XACML uses four specific types of policy as follow: Role < PolicySet >,Permission < PolicySet >,HasPrivilegesOfRole < Policy >, and RoleAssi-gnment < Policy >. More details about these types of policy are representedin [17]. Notable is RoleAssignment < Policy > is used by Role EnablementAuthority (REA) that assigns various role attributes to users and enable themwithin a session. Based on this concept, the authors of [5] define additionalfour Enablement Authorities (EA). Namely, ViewEA (VEA, assigning objects toviews), ActivityEA (AEA, deciding to use actions in activities), and ContextEA(CEA, evaluating contextual conditions). With this extension, the authors canuse XACML to express the Or-BAC model as well as other models that based onRBAC. However, XACML does not support spatial data. Therefore, GeoXACMLof Andreas Matheus [10] will be considered in the next section.

2.4 Geospatial eXtensible Access Control Markup Language

The first version of GeoXACML [10] provides a possible recommendation onhow to declare and enforce access rights effectively and flexibly. According to theextension points of XACML, < AttributeV alue > is used to add new data typesfor GeoXACML by assigning the appropriate value to the DataType attribute,and ensuring the syntax corresponds with Geography Markup Language (GML)2.1.2 definition (language is used for expressing geographical features) [11].

Beside, the declaration of spatial restrictions also requires spatial functions fortesting the specific topological constellation between two geometries (e.g. within,touches, etc.). Furthermore, GeoXACML can support the basic spatial access re-strictions based on rules (e.g. class-based, object-based and spatial restrictions).All examples for these kinds of restriction are represented in [10].

In addition, a prototype of GeoXACML has been implemented. However, itonly has the component evaluates the access request with some basic functionsfor integrating spatial data and functions into XACML, and does not considerthe restrictions about temporal characteristics, contextual information and userroles. Nevertheless, because GeoXACML uses XML encoding to express accessrights, it can be flexible to add new tags or re-define the structure of files, aswell as can be extended by adding new data types, functions, the componentsfor processing temporal conditions, etc. The evidence is the current version ofGeoXACML, version 1.0 [18] which supports many kinds of spatial functions. Ageneral view about the mentioned concepts is presented in Table 11; note thatall the conditions are considered as contextual conditions and divided into threekinds of concerning objects: user, data, and other (for role and rule based).

In summary, the proposed model will support the following contextual condi-tions: (1) location of user (user spatial aspect), (2) the time when user send hisrequest (user temporal aspect), (3) the spatial boundary of the resource (dataspatial aspect), (4) role and rule based access control (other kind of objects),

1 Spa. is Spatial; Temp. is Temporal;√

means has; means do not have; ? meansunclear; UD is User Define; Ru is Rule and Ro is Role.

206 K.T. Le Thi et al.

Table 1. A general view about the proposed model with contextual restrictions

User Data OtherSpa. Temp. Spa. Temp. Spa. Temp.

STRBAC√ √ √ √ √

Or-BAC√ √ √ √

+ (UD)√

+ (UD)

XACML 3.0√

?√

+ (Ru)

XACML 3.0 + RBAC√

?√

+ (Ro + Ru)

GeoXACML 1.0√ √ √

+ (Ru)

STRoBAC√ √ √ √

+ (Ro + Ru)√

+ (Ro + Ru)

and finally (5) content of data (e.g. when and where data is stored) is optional.Next section will represent in detail about the proposed model, STRoBAC.

3 The Proposed Model: STRoBAC

STRoBAC model is developed from the work of [8], it based on STRBAC modelto describe location and time information; express the contextual conditionsbased on Or-BAC and use GeoXACML extension based on XACML 3.0 associ-ated with RBAC to implement the model.

Similar to Or-BAC model , STRoBAC has basic sets of entities: S ( sub-jects), A (actions), O (objects), R (roles), A (activities), V (views) and C (con-texts), (Org set will not be considered). Any entities in STRoBAC model mayhave some attributes. This is represented by predicates that associate the en-tities with the value of these attributes. For instance, if s is a subject, thenWork in(s,Department) will return true if s work in Department.

Let us back to the section 2.2 and 2.3 about the general rule of Or-BACand extended RBAC profile of XACML. Mapping between two sections, thebuilt-in predicates of Or-BAC (Empower(org, s, r), Use(org, o, v), Consider,and Hold(org, s, α, o, c)) can be replaced by REA(s, r), V EA(o, v), AEA(α, a),and CEA(s, α, o, c), respectively. Furthermore, based on the core RBAC [7], per-mission includes which action is performed on which object. Therefore, predicatePermission(org, r, α, v, c) is replaced by a conjunctive of Permission(p, a, v)and PEA(p, r, c); where Permission(p, a, v) defines permission p that performactivity a on view v and PEA(p, r, c) assign permission p to role r within contextc. Beside, unlike other models, STRoBAC model considers not only context holdsbetween subject, action and object, but also the context of assigning subject inrole, using object in view and considering action in activity. Therefore, contextelement c is added into each predicate. Namely, within context c: REA(s, r, c)is true if subject s is assigned in role r, V EA(o, v, c) is true if object o is usedin view v and AEA(α, a, c) is true if action α is considered in activity a. Thedefinitions of role, activity, view, context and policy are based on these predi-cates. A role definition corresponds to a logical rule that has REA predicate inthe conclusion. Let us consider again the example in section 2.2 with conditionwhen assign role to subject: “a staff holds the Observer role in the Department ofDefence is permitted to access the important defensive position on specific map

STRoBAC 207

layer, if he is standing in his office; senior staffs (staff works more than 5 years)have the working time between 7 – 11 AM can be assigned to Observer role”.

∀s ∈ S, ∀d ∈ O,REA(s,Observer,Working time)←Work in(s,DD) ∧Working years(s, d) ∧ (d > 5) ∧Working time(s, 7, 11)

where Working years(s, d) and Working time(s, 7, 11) respectively is true if dis the working year of subject s and working time of s is between 7 – 11 AM.Activity and view definition can be expressed in the similar way. Meanwhile,reuse the example above with additional temporal condition “subject’s requesttime must be between 7 – 11 AM”, the context definition (contextual conditionshold between subject, action and object) can be expressed as follow:

∀s ∈ S, ∀α ∈ A, ∀o, po ∈ O,CEA(s, α, o, Personal Office&Request time)←(Personal office(s, po) ∧ Is located(s, po)) ∧Request time(s, 7, 11)

where Personal office(s, po) returns true if po is the personal office of sub-ject s; Is located(s, po) returns true if subject s is standing in his office andRequest time(s, 7, 11) is true if his request time is between 7 AM – 11 AM.

Now, the policy can be expressed by the components of STRoBAC as follow:

∀s ∈S, ∀α ∈A, ∀o ∈O, ∀r ∈ R, ∀a ∈ A, ∀v ∈ V , ∀c, c1, c2, c3, c4 ∈ C,REA(s, r, c1) ∧ V EA(o, v, c2) ∧ AEA(α, a, c3) ∧ PEA(p, r, c4) ∧CEA(s, α, o, c) ∧ Permission(p, a, v)→ Is permitted(s, α, o)

where c can be one of c1, c2, c3, c4 or combination of them. The policy of above-mentioned example can be expressed as follow:

∀s ∈ S, ∀α ∈ S, ∀o ∈ O,REA(s,Observer,Working time) ∧ V EA(o, Specific Map Layer) ∧AEA(α,Access) ∧ PEA(Access Specific Layer,Observer) ∧CEA(s, α, o, Personal Office&Request time) ∧Permission(Access Specific Layer, Access, Specific Map Layer)→ Is permitted(s, α, o)

where, Permission predicate defines permission Access Specific Layer thatperforms activity Access on view Specific Map Layer. The context of VEA,AEA and PEA are absent in this policy. The similar way is used to express thedefinition of Is prohibited, Is obliged and Is dispensed.

Beside, the concept of spatial and temporal in STRBAC model (section 2.1)can be expressed by the predicates in STRoBAC model. Some basic predicatesare used (similar to Or-BAC model): Before T ime, After T ime, Before Date,After date, On Day, Is Located, Location, etc. For instance:

– Logical location: Location and Is Located predicate are used to determinelocation of subject and whether subject is located in a specific area or not.

– Non recurring interval: example “between February 22, 2012 to February 28,2012” can be expressed in STRBAC is (2012/02/22 . . .2012/02/28) and inSTRoBAC is After Date(2012/02/22)&Before Date(2012/02/28)

208 K.T. Le Thi et al.

– Recurring Interval: example “between 9 AM to 5 PM everyday” can be ex-pressed in STRBAC is (09 : 00 : 00 . . . 17 : 00 : 00) and in STRoBAC is(After T ime(09 : 00 : 00)&Before T ime(17 : 00 : 00))

Because the logical location is always used to define location constraints [7],therefore the way to express physical location will not be considered. Theseexamples also show that STRoBAC can support to express the mentioned con-textual conditions in Table 1. Another model can be mentioned is X-STROWL2

[21], which focus on integrates XACML with the OWL ontology for semanticreasoning on hierarchical roles and describes the general contextual constrains,instead of proposing the general rule for expressing policy with specific spatio-temporal constrains like the model in this paper. Next section will represent howto extend GeoXACML to support STRoBAC model.

4 Extend GeoXACML to Support STRoBAC

Both of GeoXACML and XACML use the same process of evaluating user’srequests. Therefore, to support STRoBAC, some additional components willbe added in the process, (e.g. REA, VEA, AEA, CEA and PEA). However,permission includes which action is performed on which object, hence, PEA willalso includes VEA and AEA. Data-flow in Fig. 1 represents this extension. Moredetails about this process is represented in the core specification [15][16].

The process begins with the basic steps are performed similar to the firststeps in XACML (1–5). The Context Handler will does the major part of workis collecting all of the necessary information and then return to PDP (23). Forinstance, Context Handler requests (6) and receives (19) a list of selected rolefrom RoleEA. However, to evaluate which role is selected, RoleEA needs to knowabout the attributes of these roles (7). These requests are sent again from Con-text Handler to PIP (8). Then PIP obtains the attributes from the Repository (9)and returns them to the Context Handler (10). Beside, because REA predicatehave context element c in the definition, hence Context Handler has to vali-date the context before returning attributes to RoleEA (11). Similar to RoleEA,ContextEA needs to know the context attributes, then step 12–15 are performedsimilar to step 7–10. After receives the necessary attributes (16), ContextEA val-idates the context and returns the result to Context Handler (17). Then, RoleEAreceives the role attributes(18) and returns the list of selected roles to ContextHandler (19). Note that the steps according to PermissionEA are performedin parallel (or the order does not matter) and totally similar to the steps ofRoleEA. Beside, there are some other kinds of attributes can be requested (e.g.number of access requests from the log file). Therefore, Context Handler obtainsthem from PIP (20, 21, 22) and returns all of necessary attributes to the PDP(23). Furthermore, to evaluate the final context element in the general rule ofSTRoBAC (context holds between subject, action and object), the context has

2 Similar idea with STRoBAC, but they are developed independently at the sametime.

STRoBAC 209

Fig. 1. Data-flow diagram of extended GeoXACML to support STRoBAC

to be evaluated again and returns the context validation result to PDP (24–32).The last steps (34, 35) are performed similar to steps in XACML.

In addition, to support STRoBAC model, spatial functions, data types andnew identifiers/attributes have to be added in GeoXACML. However, besidethe implementation of GeoXACML (based on Sun’s XACML 1.1), [14] providesmany open sources implement XACML. Notable is the implementation of Sun’sXACML [20], HERAS-AF [6], XACMLight [22] and Enterprise Java XACML[4]. Nevertheless, Sun’s XACML just supports XACML version 1.1, meanwhilethe implementation of Enterprise Java XACML has not been updated for a longtime and it does not have a clear manual. Compare with XACMLight, HERAS-AF supports more components and has the fuller manual. For these reasons,HERAS-AF will be chosen for the implementation of this research. More detailsabout HERAS-AF as well as the way to extend it will be considered in the future.

5 Conclusion

In this paper, we proposed STRoBAC model that can support spatio-temporalaspects and other contextual conditions for GIS data. STRoBAC is the combi-nation of using spatio-temporal concepts of STRBAC with the way of expressingcontextual conditions in Or-BAC and the process of role, activity, view and con-text assignment, proposed in the extended RBAC profile of XACML. Further-more, unlike other models, beside the context holds between subject, action and

210 K.T. Le Thi et al.

object, we proposed other additional contexts (e.g. contexts of assigning subjectin role, using object in view, and assigning action in activity). The paper alsorepresents a way of extending GeoXACML to support STRoBAC model. Moredetails about new functions, data types, identifiers/attributes and the imple-mentation of GeoXACML that supports STRoBAC based on XACML 3.0 andHERAS-AF will be discussed in the future.

References

1. Chun, S.A., Atluri, V.: Geospatial Database Security. In: Gertz, M., Jajodia, S.(eds.) Hand Book of DB Security App. and Trends, pp. 247–248. Springer (2007)

2. Cuppens, F., Boulahia, N.C.: Modeling Contextual Security Policies. InternationalJournal of Information Security 7(4), 285–305 (2008)

3. Damiani, M.L., Bertino, E., Catania, B., Perlasca, P.: GEO-RBAC: A SpatiallyAware RBAC. ACM Trans. on Info. and System Security 10(1) (2007)

4. E.J. XACML (June 2012), http://code.google.com/p/enterprise-java-xacml/5. Haidar, D.A., Cuppens-Boulahia, N., Cuppens, F., Debar, H.: An Extended RBAC

Profile of XACML. In: 3rd ACM Workshop on Secure Web Services, pp. 13–22(2006)

6. HERAS-AF (June 2012), http://www.herasaf.org/7. Kumar, M., Newman, R.E.: STRBAC – An Approach Towards Spatio-Temporal

Role-Based Access Control. In: Communication, Network and Information Security,USA, pp. 150–155 (2006)

8. Le, T.K.T., Tran, T.Q.N., Dang, T.K.: An Enhanced Access Control Model forGIS Database Security. In: 4th Regional Conference on Information and Commu-nication Technology, Vietnam, pp. 129–136 (2011)

9. Lin, J., Fang, Y., Chen, B., Wu, P.: Analysis of Access Control Mechanisms forSpatial Database. In: ISPRS (2008)

10. Matheus, A.: Declaration and Enforcement of Access Restrictions for DistributedGeospatial Information Objects, Master Thesis, Fakultat fur Informatik TechnischeUniversitat Munchen (2005)

11. Matheus, A.: GeoXACML, A Spatial Extension to XACML. The Federal ArmedForces Germany Univ., Discussion paper 05-036 (June 16, 2005)

12. OASIS Brief Introduction to XACML (April 2012),http://www.oasis-open.org/committees/download.php/2713/

Brief Introduction to XACML.html

13. OASIS Differences between XACML 2.0 and XACML 3.0 (April 2012),http://wiki.oasis-open.org/xacml/DifferencesBetweenXACML2.0AndXACML3.0

14. OASIS XACML (April 2012), http://www.oasis-open.org/committees/tchome.php?wg abbrev=xacml#CURRENT

15. OASIS XACML 2.0 Core Specification (April 2012),http://docs.oasis-open.org/xacml/2.0/access

control-xacml-2.0-core-spec-os.pdf

16. OASIS XACML 3.0 Core Specification (April 2012),http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf

17. OASIS XACML 3.0 and Core Hierarchical Role Based Access Control (April 2012),http://docs.oasis-open.org/xacml/3.0/xacml-3.0-rbac-v1

-spec-cs-01-en.pdf

STRoBAC 211

18. OGC GeoXACML (April 2012),http://www.opengeospatial.org/standards/geoxacml

19. Sophat, S.: Fundamentals of Geographic Information Systems. Royal University ofPhnom Penh (2007)

20. Sun’s XACML (June 2012), http://sunxacml.sourceforge.net21. Tran, T.Q.N., Dang, T.K.: X-STROWL: A Generalized Extension of XACML for

Context-aware Spatio-Temporal RBAC Model with OWL. In: 7th InternationalConference on Digital Information Management, Macau (to appear, 2012)

22. XACMLight (June 2012), http://sourceforge.net/projects/xacmllight/23. What is GIS (October 2011), http://www.gis.com/content/what-gis