An Architecture for Specification and Enforcement ofTemporal Access Control Constraints using OWL

Hassan TakabiSchool of Information

SciencesUniversity of Pittsburgh

Pittsburgh, PA, USAhatakabi@sis.pitt.edu

Minsoo KimArtificial Intelligence

LaboratoryAjou University

Suwon, South Koreavisual@ajou.ac.kr

James B. D. JoshiSchool of Information

SciencesUniversity of Pittsburgh

Pittsburgh, PA, USAjjoshi@sis.pitt.edu

Michael B. SpringSchool of Information

SciencesUniversity of Pittsburgh

Pittsburgh, PA, USAspring@sis.pitt.edu

ABSTRACTThe Semantic Web is an extension of the World Wide Webthat has been growing in recent years. One important issuein the Semantic Web environment is access control. Inte-grating Role-Based Access Control (RBAC) models, whichhave been accepted as a powerful approach to security man-agement, with the Semantic Web helps to reduce the com-plexity of Web security management. The Generalized Tem-poral RBAC (GTRBAC) model combines the key featuresof the RBAC model with a temporal framework to addresssituations where processes and functions may have limitedtime spans or periodic temporal durations, and it is usefulfor applications with inherent temporal semantics such asworkflow-based systems. There have been several attemptsto adopt basic components of the RBAC to the SemanticWeb using Web Ontology Language (OWL). In this paper,we show how to model temporal constraints and restrictionsin GTRBAC using OWL. In order to do this, we define OWLontologies that represent temporal constraints in GTRBACand describe implementation of a scalable architecture forspecification and enforcement of GTRBAC policies. Theapplicability of the represented model is shown using a run-ning example.

Categories and Subject DescriptorsK.6.5 [MANAGEMENT OF COMPUTING AND IN-FORMATION SYSTEMS]: Security and Protection; D.4.6[SECURITY AND PROTECTION]: Access Controls

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SWS’09, November 13, 2009, Chicago, Illinois, USA.Copyright 2009 ACM 978-1-60558-789-9/09/11 ...$10.00.

General TermsSecurity, Design, Languages

KeywordsGTRBAC, OWL, Access Control, Temporal Constraints

1. INTRODUCTIONThe Semantic Web is an extension of the World Wide Web

that allows knowledge, information and data to be sharedon the Web and reused across applications and enterprises.It is important for security frameworks, particularly accesscontrol models to capture the heterogeneous and distributednature of the Semantic Web [12]. A security framework forthe Semantic Web needs a language to express security poli-cies [16].

To meet this need, some Semantic Web based policy lan-guages for access control have been developed [16, 17, 18, 19,20]. Rei is implemented in Prolog with a semantic represen-tation of policies using the Resource Description Framework(RDF) [16, 17]. KAoS uses the DARPA Agent Markup Lan-guage (DAML) as the basis for representing and reasoningabout policies for web services [18, 19]. Ponder is an object-oriented policy language for the management of distributedsystems and networks [20]. These policy languages describepolicies over heterogeneous domains and support commonunderstanding among participants who might not use thesame information model. However, a policy language with-out ties to a model gives the designer little guidance. Con-versely, a model may not have the organized structure toexpress all the policy details or may leave important aspectsunspecified [2]. Integrating access control models with theSemantic Web helps to reduce the complexity of web securitymanagement [12]. To support a model in a policy languagethere must be some ways to express the components and fea-tures of the model in the language. This expression shouldbe natural and leverage thinking along the lines of the modelwhile expressing model details.

21

Web Ontology Language (OWL) is a standard knowledgerepresentation and specification language for the SemanticWeb, making it a natural tool for providing access control inthat context [3]. Describing security policies by OWL helpsweb entities to better understand and share the security poli-cies. The use of OWL to define policies has several impor-tant advantages that become critical in distributed environ-ments involving coordination across multiple organizations.First, most policy languages define constraints over classesof targets, objects, actions and other constraints (e.g., timeor location). A substantial part of the development of apolicy is often devoted to the precise specification of theseclasses, e.g., the definition of what counts as a full time stu-dent or a public printer. This is especially important if thepolicy is shared between multiple organizations that mustadhere to or enforce the policy even though they have theirown native schemas or data models for the domain in ques-tion. The second advantage is that OWL’s grounding inlogic facilitates the translation of policies expressed in OWLto other formalisms, either for analysis or for execution. Al-though OWL is not a language for expressing authorizationpolicies, it has successfully been used for this purpose inprevious work. Some researchers have used OWL as a rep-resentation language for RBAC policies [2, 13, 12, 11, 14, 8].It has been used for representing RBAC policies, reasoningabout RBAC authorizations, handling negative authoriza-tions, and specifying constraints. Given the potential of alanguage like OWL, it would be good to assess whether OWLis expressive enough to support more complicated accesscontrol models. To this end, we chose the Generalized Tem-poral Role Based Access Control (GTRBAC) model thatcombines the key features of the RBAC model with a pow-erful temporal framework [1]. The GTRBAC model allowsspecification of a comprehensive set of time based accesscontrol policies, including periodic as well as duration con-straints on role enabling, user-role and role permission as-signments, and role activations. It provides an event basedmechanism for supporting dynamic access control policies,which are crucial for developing secure workflow-based en-terprise applications. In addition, the temporal hierarchiesand separation of duty constraints facilitated by GTRBACallow specifying fine-grained temporal semantics. BecauseOWL is based on XML, it is a language for which there willbe supporting tools.

In this paper, we examine the relationship between theGTRBAC model and OWL and model temporal constraintsand restrictions in OWL. To enforce GTRBAC in the Se-mantic Web context, we define OWL ontologies that repre-sent temporal constraints and restrictions in GTRBAC andshow how they can be used to specify and implement tempo-ral constraints. We also propose a scalable architecture forspecification and enforcement of GTRBAC policies. More-over, we show how to enforce restrictions and constraints inGTRBAC using an example scenario.

The remainder of this paper is organized as follows: Sec-tion 2 presents a brief description of the OWL and the GTR-BAC model. Section 3 discusses the related work. Section 4describes the example scenario that we use in this paper. InSection 5, we show how to represent temporal constraints inGTRBAC using OWL. In section 6, we model enforcementof constraints using OWL. In Section 7, we describe the sys-tem architecture. Finally, Section 8 discusses conclusionsrelated to the study.

2. BACKGROUNDThis section reviews the OWL and the GTRBAC model.

2.1 Semantic Web and OWLIn the Semantic Web, ontologies are used to specify a

domain of interest that consists of terms representing indi-viduals, classes of individuals, properties, and axioms thatassert constraints over them. It provides a structured vo-cabulary that describes concepts and relationships betweenthem as well as a specification of the meaning of terms usedin the vocabulary. Different ontology languages provide dif-ferent facilities. The W3C standards for ontology languagesare based on RDF, which provides a basic capability forspecifying graphs with a simple interpretation as a semanticnetwork. Since it is a graph-based representation, RDF dataare often reduced to a set of triples where each representsan edge in the graph or alternatively, a binary predication.The Web Ontology Language OWL [3] is a family of stan-dard knowledge representation language for the SemanticWeb based on Description Logic (DL) with a representationin RDF. By using a reasoner we can check whether all of thestatements and definitions in the ontology are mutually con-sistent. However, there is a tradeoff between expressivenessand efficient reasoning. The more expressive the languageis, more difficult and less efficient the reasoning is. W3C’sWeb Ontology Working Group defines OWL as three differ-ent sub-languages: OWL-Lite, OWL-DL and OWL-Full. Adefining feature of each sub-language is its expressiveness.OWL-DL may be considered as an extension of OWL-Liteand OWL-Full an extension of OWL-DL.

2.2 GTRBACThe Generalized Temporal Role Based Access Control

(GTRBAC) model is an extension of Temporal RBAC (TR-BAC) which is an RBAC extension to address temporal con-straints. In particular, GTRBAC model allows one to ex-press periodic and duration constraints on roles, user-roleassignments, and role-permission assignments. Numerousactivation constraints including cardinality constraints andmaximum active duration constraints can lead to further re-striction of activation of a role in an interval. The GTRBACmodel extends the structure of the TRBAC model such thatits features including event and trigger expressions subsumethose of TRBAC.

2.2.1 Temporal Constraints in GTRBACIn GTRBAC, a role can have one of the three states: dis-

abled, enabled, and active. Being in disabled state meansthat a user cannot acquire the permissions associated withthe role. A role in the disabled state can be enabled. Whena role is in enabled state, users who are authorized to usethe role at the time of the request can activate the role.If a user activates a role in enabled state, the state of therole becomes active. The active state indicates that there isat least one user who has activated the role. If a disablingevent occurs, roles in the enabled or active state transit tothe disabled state. The model allows the specification of thefollowing types of constraints: temporal constraints on roleenabling, user-role, and role-permission assignments, activa-tion constraints, runtime events, constraint enabling expres-sions, and triggers. Priorities are associated with each eventin GTRBAC. In GTRBAC, event expressions, priorities, andstatus predicates are used to express the constraints.

22

2.2.2 Periodicity and Duration Constraints on RoleEnabling and Assignments

The model uses periodicity constraints to specify the inter-vals. Periodicity constraints are intervals during which a rolecan be enabled or disabled, and during which a user-role as-signment or a role permission assignment is valid. Generally,periodicity constraint expressions are specified by (I, P, pr :E). The pair (I, P ) specifies the intervals during which anevent E takes place. E can be one of the assignment events:“assignp/deassignp p to r” or “assignu/deassignu u to r”or a role enabling event: “enable/disable r”. pr indicates thepriority of event.

The model uses duration constraints to specify durationsfor which enabling or assignment of a role is valid. In caseof an event occurrence, the duration constraint associatedwith the event validates the event for the specified durationonly. Generally, the duration constraint expressions for roleenabling and assignment are specified by ([(I, P )|D], Dx, pr :E), where x is either R, U , or P , corresponding to events:“enable/disable r,”“assignu/deassignu r to u,” and“assignp/deassignp p to r,” respectively. D and Dx refer tothe durations such that D ≤ Dx. The symbol “|” between(I, P ) and D indicates that either (I, P ) or D is specified.The square bracket in [(I, P )|D] implies that this parameteris optional.

2.2.3 Temporal Constraints on Role ActivationDuration constraints can be applied on role activations

whereas periodicity constraints on role activations shouldnot be applied. The duration constraints can be classifiedinto two types: total active duration constraint and max-imum duration per activation constraint. The total activeduration constraint on a role restricts the number of therole’s activation duration in a given period to a specifiedvalue. The total active duration can be specified on per-roleand per-user-role basis. Per-role constraint restricts the to-tal active duration for a role, while per-user-role constraintrestricts the total active duration for a role by a particularuser.

3. RELATED WORKThere have recently been some efforts to look at OWL as

a representation language for RBAC policies. Finin et al.have introduced ROWLBAC, a representation of RBAC inOWL [2, 13]. They propose two different approaches: onemaps roles to classes and subclasses, and the other mapsroles to values. In the first case roles are represented asclass of users, and the role hierarchy relation is mapped tothe subsumption relation in OWL. Then it maps SoD con-straints to class disjointness constraints in OWL. The sec-ond approach is to map classes onto individuals and bindusers to classes through the property role. It models con-straints through specialized properties e.g. DSoD and SSoD.However, a standard DL reasoner can not detect constraintviolations and we need to add rules to the ontology thatdegrades performance. Knetchel et al. have proposed anapproach that uses OWL for reasoning about RBAC autho-rizations [8]. The model can support both roles and classhierarchies. However, it does not take into considerationSoD constraints. Heilili et al have defined users and rolesas classes [12]. In order to handle negative authorizations,they define two corresponding classes for each role, each per-mission or prohibition has corresponding classes for roles

and users. In other words, for each permission, there is aclass of roles that has that permission, and then a class ofusers that has that permission. It is similar for each pro-hibition. Di et al. have described another approach usingOWL to specify the RBAC constraints [11]. Their approachmodels roles, users, permissions, and session as classes, withproperties to relate users to roles and roles to permissions.They also define functional mappings between sessions androles and specify constraints such as separation of duty con-straints, prerequisite constraints and cardinality constraintswith OWL. However, in order to specify separation of dutyand other constraints rules must be added.

Kolovski et al. have developed a DL-based analysis toolfor XACML policies [10]. Their proposed approach repre-sents a mapping between Description Logics and XACML aswell as reasoning methods to verify properties of XACMLpolicies. Kagal et al. have proposed a general frameworkbased on semantic web technologies that supports generalpurpose policy systems and is able to solve mismatches amongdifferent policy languages [9]. Knechtel et al. have proposedRBAC-CH, an extension of Hierarchical RBAC [14]. The au-thors extend Hierarchical RBAC by using a class hierarchyof the accessed objects and present a concept to implementthis model in a DL knowledge base using an OWL ontology.The permissions of roles are defined on object classes andthen users permissions to objects automatically derived by areasoning service. Cirio et al. have proposed an access con-trol system for context-aware environments designed usingSemantic Web technologies, namely OWL and DescriptionLogic [15]. They adopt the RBAC model and extend it withcontextual attributes. The authors have developed a highlevel OWL ontology to express the elements of an RBACsystem and also a domain-specific ontology to capture thefeatures of a sample scenario. They use a DL reasoner toclassify users and resources, and verify the consistency ofthe access control policies. To the best of our knowledge,there is no work on time based access control policies thatwe address in this paper.

4. EXAMPLE SCENARIOTo illustrate our approach we use a simple scenario from

a medical information system that is adopted from [1]. Theexample is shown in Table 1. In row 1a, the enabling timesof DayDoctor and NightDoctor roles are specified as a pe-riodicity constraint. The (I, P ) forms for DayTime (9:00a.m.-9:00 p.m.) and NightTime (9:00 p.m.-9:00 a.m.) are asfollows:

DayTime = ([12/1/2008,∞], all.Days + 10.HoursB 12.Hours)

andNightT ime = ([12/1/2008,∞], all.Days + 22.Hours

B 12.HoursIn constraint 1b, Adams is assigned to the role of DayDoc-

tor on Mondays, Wednesdays, and Fridays, whereas Bill isassigned to this role on Tuesdays, Thursdays, Saturdays,and Sundays. The assignment in constraint 1c indicatesthat Carol can assume the DayDoctor role everyday between10:00 a.m. and 3:00 p.m. Constraint 2b specifies a durationconstraint of 2 hours for the enabling time of the NurseIn-Training role, but this constraint is valid only for 6 hoursafter the constraint c1 is enabled. Consequently, once theNurseInTraining role is enabled, Ami can activate the Nur-seInTraining role at the most for two hours.

23

Table 1: Example GTRBAC Access Policy for Medical Information System1 a (DayTime, enable DayDoctor), (NightTime, enable NightDoctor)

b ((M, W, F), assignu, Adams to DayDoctor), ((T, Th, S, Su), assignu, Bill to DayDoctor)c (Everyday between 10am-3pm, assignu, Carol to DayDoctor)

2 a (assignu Ami to NurseInTraining), (assignu Elizabeth to DayNurse)b c1=(6 hours, 2 hours, enable NurseInTraining)

3 a (enable DayNurse → enable c1)b (activate DayNurse for Elizabeth → enable NurseInTraining after 10 min)c (enable NightDoctor → enable NightNurse after 10 min), (disable NightDoctor → disable NightNurse after 10 min)

Trigger 3a indicates that the constraint c1 in row 2b isenabled once the DayNurse is enabled. As a result, the Nur-seInTraining role can be enabled within 6 hours. Trigger 3bindicates that 10 min after Elizabeth activates the DayNurserole, the NurseInTraining role is enabled for a period of 2hours. As a result, a nurse-in-training can have access tothe system only if Elizabeth is present in the system. Inother words, once the roles are assumed, Elizabeth acts as atraining supervisor for a nurse-in-training. Note that Eliza-beth can activate the DayNurse role multiple times withina duration of 6 hours after the DayNurse role is enabled.

5. TEMPORAL CONSTRAINTS IN OWLIn this section we describe OWL ontologies that concep-

tualize temporal constraints introduced in GTRBAC. Theontology defines restrictions and constraints in GTRBACincluding activation constraints, cardinality constraints, andtemporal constraints.

We create classes representing basic RBAC components(i.e., user, role, etc) as follows. The users are modeled asan OWL class User. The instances of this class representthe users/subjects on which the policies are defined. Theassociation between a user and a role is defined by the Ob-jectProperty hasRole(User, Role). Moreover, we can link auser to a permission by the ObjectProperty hasPermission(User, Permission).User rdfs:subClassOf owl:Thing

hasRole a rdfs:Property, owl:ObjectPropertyrdfs:domain :User;rdfs:range :Role.

hasPermission a rdfs:Property, owl:ObjectPropertyrdfs:domain :User;rdfs:range :Permission.

We define three classes Action, Object and Permission torepresent actions, objects/resources and permissions respec-tively. The Permission class binds a user to an action-objectusing two properties hasAction and hasObject.Action rdfs:subClassOf owl:ThingObject rdfs:subClassOf owl:ThingPermission rdfs:subClassOf owl:Thing

hasAction a rdfs:Property, owl:FunctionalPropertyrdfs:domain :Permission;rdfs:range :Action.

hasObject a rdfs:Property, owl:FunctionalPropertyrdfs:domain :Permission;rdfs:range :Object.

In order to represent a role hierarchy 〈R,¹〉, we modelroles as an OWL class Role, and all the roles in R as in-stances of this class. The ¹ relation is represent by theOWL property subRoleOf(Role, Role). Furthermore, we de-fine subRoleOf to be transitive by making it an instance of

owl:TransitiveProperty class. In this way, a reasoner can in-fer that if subRoleOf(Ri, Rj) and subRoleOf(Rj , Rk), thensubRoleOf(Ri, Rk). For example, we can model the relationbetween Professor and AssistantProfessor by adding to theontology the property subRoleOf( Assistant Professor, Pro-fessor). The association between a role and a permission canbe defined by ObjectProperty hasPermission(Role, Permis-sion).Role rdfs:subClassOf owl:Thing

subRoleOf a rdfs:Property, owl:TransitivePropertyrdfs:domain :Role;rdfs:range :Role.

hasPermission a rdfs:Property, owl:ObjectPropertyrdfs:domain :Role;rdfs:range :Permission.

The rest of this section describes the ontology which con-ceptualizes temporal constraints defined in the GTRBACmodel. We describe the important concepts in this paper.

5.1 Periodic ExpressionsPeriodic expressions are the basis for representing tempo-

ral constraints. Calendar classes represent temporal units(i.e. year, month, week, day, and hour). Using the Com-positeCalendar, it is possible to define temporal expressionbased on different temporal units.YearCalendar rdfs:subClassOf CalendarMonthCalendar rdfs:subClassOf CalendarWeekCalendar rdfs:subClassOf CalendarDayCalendar rdfs:subClassOf CalendarHourCalendar rdfs:subClassOf CalendarCompositCalendar rdfs:subClassOf Calendar

year a rdfs:Property, owl:ObjectPropertyrdfs:domain : CompositCalendar;rdfs:range : YearCalendar.

month a rdfs:Property, owl:ObjectPropertyrdfs:domain : CompositCalendar;rdfs:range : MonthCalendar.

week a rdfs:Property, owl:ObjectPropertyrdfs:domain : CompositCalendar;rdfs:range : WeekCalendar.

day a rdfs:Property, owl:ObjectPropertyrdfs:domain : CompositCalendar;rdfs:range : DayCalendar.

hour a rdfs:Property, owl:ObjectPropertyrdfs:domain : CompositCalendar;rdfs:range : HourCalendar.

Interval class is defined with two properties, beginTimeand endTime as follows.Interval rdfs:subClassOf owl:Thing

beginTime a rdfs:Property, owl:FunctionalPropertyrdfs:domain : Interval;

24

rdfs:range :date.endTime a rdfs:Property, owl:FunctionalProperty

rdfs:domain : Interval;rdfs:range : date.

The PeridociExpression class represents duration, for ex-ample 10 hours from 2009-06-09, 10.am.PeriodicExpression rdfs:subClassOf owl:Thing

baseCalendar a rdfs:Property, owl:ObjectPropertyrdfs:domain : PeriodicExpression;rdfs:range : CompositCalendar.

durationUnit a rdfs:Property, owl:DataTypePropertyrdfs:domain : PeriodicExpression;rdfs:range : String, owl:DataRange:{Year, Month,

Week, Day, Hour}.durationVariable a rdfs:Property, owl:FunctionalProperty

rdfs:domain : PeriodicExpression;rdfs:range : Integer.

The PeriodicTime class is conceptualized by hasIntervaland hasPeridociExpression properties.PeriodicTime rdfs:subClassOf owl:Thing

hasInterval a rdfs:Property, owl:ObjectPropertyrdfs:domain : PeriodicTime;rdfs:range : Interval.

hasPeriodicExpression a rdfs:Property, owl:ObjectPropertyrdfs:domain : PeriodicTime;rdfs:range : PeriodicExpression.

5.2 Events in GTRBACIn this section, we represent various types of events defined

in the GTRBAC model. Each Event class has properties re-lated to role, user, or permission depending on the type ofrelation being represented.Event rdfs:subClassOf owl:ThingUserRoleAssignment rdfs:subClassOf Event

hasUser a rdfs:Property, owl:ObjectPropertyrdfs:domain : UserRoleAssignment;rdfs:range : User.

hasRole a rdfs:Property, owl:ObjectPropertyrdfs:domain : UserRoleAssignment;rdfs:range : Role.

Similarly, we define other events such as UserRoleDeas-signment, RolePermissionAssignment, RolePermis-sionDeassignment, RoleEnabling, RoleDisabling, Role-Activation, ConstraintEnabling, and ConstraintDis-abling.

The Trigger class conceptualizes a trigger in GTRBAC.The class has triggeringEvent and triggeredEvent proper-ties.Trigger rdfs:subClassOf owl:Thing

triggeringEvent a rdfs:property, owl:objectPropertyrdfs:domain Triggerrdfs:range Event

triggeredEvent a rdfs:property, owl:objectPropertyrdfs:domain Triggerrdfs:range Event

5.3 Restrictions and ConstraintsThe restrictions and constraints, most important concepts

in GTRBAC, represent temporal constraints. While thereare several types of restrictions, we describe only role acti-vation restrictions. The RoleActivationRestriction class as-sociates with RoleActivation and RoleDeactivation events.

RoleActivationRestriction rdfs:subClassOf owl:ThingassociatedWith a rdfs:Property, owl:ObjectProperty

rdfs:domain : RoleActivationRestriction;rdfs:range : Event, owl:allValuesFrom:

RoleActivation.user a rdfs:Property, owl:ObjectProperty

rdfs:domain : RoleActivationRestriction;rdfs:range : User, owl:maxCardinality:1.

restrictTo a rdfs:Property, owl:FunctionalPropertyrdfs:domain : RoleActivationRestriction;rdfs:range : String, owl:DataRange:{PERROLE,

PERUSERROLE}.It has two subclasses according to the type of restriction;CardinalityRestriction and DurationRestriction class.The former restricts role activation by using activeCardinal-ity property, while the latter uses activeDuration property.The CardinalityRestriction is represented by two properties:activeCardinality and defaultCardinality. The MaxNum-berOfConcurrentActivationRestriction and TotalNum-berOfActivationRestriction are defined as subclasses ofCardinalityRestriction.The DurationRestriction is represented by activateDu-ration property. The MaxRoleDurationPerActivation-Restriction and TotalActiveRoleDurationRestrictionare defined as subclasses of DurationRestriction.

The Constraint classes represent temporal policies in GTR-BAC. Each Constraint class is associated with only oneevent. The ActivationConstraint class is related to activa-tion events and it is described by associatedWith, canDura-tion, and restriction properties.Constraint rdfs:subClassOf owl:ThingActivationConstraint rdfs:subClassOf Constraint

associatedWith a rdfs:Property, owl:ObjectPropertyrdfs:domain : Constraint;rdfs:range : Event, owl:allValuesFrom:

RoleActivation.canDuration a rdfs:Property, owl:ObjectProperty

rdfs:domain : ActivationConstraint;rdfs:range : PeriodicTime.

restriction a rdfs:Property, owl:ObjectPropertyrdfs:domain : ActivationConstraint;rdfs:range : RoleActivationRestriction.

It has two subclasses according to restriction type (dura-tion or cardinality), ActivationDurationConstraint andCardinalityConstraint which are described by restrictionproperty. The MaxRoleDurationPerActivationConstraintand TotalActiveRoleDurationConstraint are subclassesof ActivationDurationConstraint and the MaxNumberOf-ConcurrentActivationConstraint and TotalNumberO-fActivationConstraint are subclasses of CardinalityCon-straint. They are distinguished by owl:allValuesFrom on re-striction property.

The TemporalConstraint classes are related to all eventsexcept (de)activation events.TemporalConstraint rdfs:subClassOf Constraint

associatedWith a rdfs:Property, owl:ObjectPropertyrdfs:domain : Constraint;rdfs:range : Event, owl:allValuesFrom: {

UserRoleAssignment, UserRoleDeassignment,RoleEnabling, RoleDisabling,RolePermissionAssignment,RolePermissionDeassignment}.

25

Figure 1: The Proposed Architecture

The class is divided into two subclasses according to thetype of restriction, DurationConstraint and Periodici-tyConstraint. DurationConstraint class has two additionalproperties, canDuration and eventDuration. Periodicity-Constraint has periodicTime property in order to representperiodic restrictions.

6. ENFORCING RESTRICTIONS ANDCONSTRAINTS

In this section, we apply the presented model to our ex-ample scenario. The followings are policies shown in table 1.The specification in illustrative not exhaustive given spaceconstraints.

UsersAdams a gtrbac:User, Bill a gtrbac:User

RolesDayDoctor a gtrbac:Role, NightDoctor a gtrbac:Role,NurseInTraining a gtrbac:Role

EventsEnableDayDoctor a gtrbac:RoleEnablingEnableNurseInTraining a gtrbac:RoleEnablingAdamsToDayDoctor a gtrbac:UserRoleAssignmentEnableTable1-2b a gtrbac:ConstraintEnabling

IntervalsInterval1 a gtrbac:Interval

beginTime 20031201endTime 99991231

Periodic TimesDayTime a gtrbac:PeridicTime

interval Interval1hasPeriodicExpression DayTimeExp

DayTimeExp a gtrbac:PeriodicExpressiondurationUnit HOURdurationValue 12baseCalendar {AllYears, AllMonths, AllWeeks,

AllDays, 10}Table1-1b-1-time a gtrbac:PeridicTime

interval Interval1hasPeridocExpression Table1-1b-1exp

Table1-1b-1exp a gtrbac:PeriodicExpression

durationUnit HOURdurationValue 24baseCalendar {AllYears, AllMonths, AllWeeks,

(Monday, Wednesday, Friday), AllHours}It is similar for Table1-1b-2-time and Table1-1c-time.Constraints for Row1

Table1-1a-(a) a gtrbac:PeriodicityConstraintassociatedWith EnableDayDoctorperiodicTime DayTime

Table1-1b-(a) a gtrbac:PeriodcityConstraintassociatedWith AssignAdamsToDayDoctorperiodicTime Table1-1b-1-time

Constraints in Row2Table1-2b a gtrbac:DurationConstratin

associatedWith EnableNurseInTrainingcanDuration 6, HOUReventDuration 2, HOUR

Triggers in Row3Table1-3b a gtrbac:Trigger

triggeringEvent ActivateDayNursetriggeringPostfix for, ElizabethtriggeredEvent EnableNurseInTraingintriggeredPostfix after, 10, MINUTE

Table1-3c-(a) a gtrbac:TriggertriggeringEvent EnableNightDoctortriggeredEvent EnableNightNursetriggeredPostfix after, 10, MINUTE

7. SYSTEM ARCHITECTURE ANDIMPLEMENTATION

In this section, we present the system architecture andprovide an overview of the system components and technolo-gies. We extend our previous implementation architecture ofa scalable GTRBAC system to show how to specify policiesusing OWL DL and reason over the ontologies and how toenforce policies [21]. Our proposed system design is shownin Figure 1. As indicated in the figure, the system includesfour main modules: specification module, reasoning module,transformation module, and enforcement module.

26

Figure 2: The General Architecture of GTRBAC System

The specification module facilitates specifying tempo-ral constraints in OWL DL. We use Protege, a Java toolthat provides an extensible architecture for the creation ofcustomized knowledge-based applications [4]. The Protege-OWL editor enables users to build ontologies for the Se-mantic Web, in particular in the OWL. In order to reasonover the ontologies represented in Protege-OWL, a DIG [6]compliant reasoner is required. DIG interface provides animplementation-neutral mechanism for accessing Descrip-tion Logic reasoner functionality and allows a variety of toolssuch as ontology editors to interact with different DL rea-soners in a standard way. DIG 2.0 defines an XML Schemathat describes a concept language and accompanying op-erations to be used over an HTTP based interface to a DLreasoner. We use DIG 2.0 to communicate between the spec-ification module and the reasoning module. The reasoningmodule receives the policies from representation module,validates them, and if there is no error sends them to thetransformation module. The validation includes identifyingwhether policies are consistent or not. In this module, weuse RACER(Renamed Abox and Concept Expression Rea-soner), a well-known reasoner for the Semantic Web lan-guages [5]. RACER provides highly optimized inference ser-vices for sophisticated ontology applications by supportingrules, constraint reasoning, and expressive query answering.Using RACER as reasoner along with Protege, we check therepresented policies to determine if there is any inconsis-tency between policies.

The transformation module parses the validated poli-cies and generates appropriate rules based on those policies.These generated rules are used to evaluate applicable poli-cies and render an authorization decision. In this module, weuse Jena, a Java framework for building Semantic Web ap-plications [7]. Jena provides a programming environment forRDF, RDFS and OWL and includes a rule-based inferenceengine. Finally, the enforcement module is the system en-tity that performs access control by making decision requestsand enforcing authorization decisions. As mentioned earlier,policies are represented in OWL, validated, and transformed

to rules. These rules are used by GTRBAC engine in theenforcement module to enforce policies.

Our system implementation can be viewed as a traditionalRBAC system and a GTRBAC add-on module. An RBACengine is used to enforce RBAC policy and GTRBAC add-on does not affect the RBAC engine and can be added onany existing RBAC system no matter how it is implementedor enforced. In fact, the GTRBAC add-on module only up-dates the RBAC policies. Horizontally, the system is di-vided into three levels: Interface Level, Logical Level, andDatabase Level. On interface level, the administrators spec-ify/update the policies; and the user can issue access re-quests to the RBAC engine and get authorization decisionfrom it. At the database level, the RBAC policies are storedas a set of tables in a relational database. At the logicallevel, the specification module interacts with the reasoningmodule to check the consistency of the policies and the trans-formation module translates them to the data structures inthe database. The GTRBAC engine and RBAC engine alsoreside at the logical level. The details of implementation ofGTRBAC Engine have been discussed in our previous work[21]. The overall system architecture which is an extensionof our previously proposed architecture for GTRBAC imple-mentation engine, is shown in Figure 2.

As indicated in Figure 2, the system operates as follows.

• The security administrators write policies in OWL filesusing Protege-OWL editor.

• The OWL files are sent to RACER using DIG inter-face.

• RACER performs reasoning and checks the consistencyof OWL ontology and loads them into a DL knowledgebase.

• Jena framework generates rules based on validated DLknowledge base and loads them into a GTRBAC policybase.

27

• GTRBAC engine reads the GTRBAC policy base andbased on that updates the RBAC policy base.

• The access requester sends a request to RBAC engine.

• The RBAC engine evaluates updated RBAC policybase against the request.

• If access is granted, the RBAC engine permits accessto the service; otherwise denies it.

8. CONCLUSION AND FUTURE WORKIntegrating RBAC models with the Semantic Web helps to

reduce the complexity of Web security management. Therehave been several attempts to adopt basic components of theRBAC for the Semantic Web using OWL. The GTRBAC isan extension of RBAC that is useful for applications withtemporal semantics. It addresses situations that processesand functions may have limited time spans or periodic tem-poral durations. In an attempt to represent temporal con-straints in the Semantic Web, we have defined OWL ontolo-gies that represent temporal constraints in GTRBAC andshow how they can be used to specify and model tempo-ral constraints. Furthermore, we have proposed a scalablearchitecture for specification and enforcement of GTRBACpolicies. An example scenario is used to show the applica-bility and efficiency of the represented model.

AcknowledgementsThis research has been supported by the US National Sci-ence Foundation award IIS-0545912. We would like to thankthe anonymous reviewers for their helpful comments.

9. REFERENCES[1] J. Joshi, E. Bertino, U. Latif, and A. Ghafoor, “A

Generalized Temporal Role-Based Access ControlModel”, IEEE Transactions on Knowledge and DataEngineering, Vol. 17, No. 1, pages 4-23, 2005.

[2] T. Finin, A. Joshi, L. Kagal, J. Niu, R. Sandhu, W.Winsborough, and B. Thuraisingham, “ROWLBAC -Representing Role Based Access Control in OWL”, InProc. of the 13th ACM symposium on access controlmodels and technologies (SACMAT 2008), pages72-83, 2008.

[3] “OWL Web Ontology Language Overview”,http://www.w3.org/TR/owl-features/

[4] “http://protege.stanford.edu”

[5] “http://www.racer-systems.com”

[6] “http://dl.kr.org/dig”

[7] “http://jena.sourceforge.net”

[8] M. Knechtel, J. Hladik, and F. Dau. “Using owl dlreasoning to decide about authorization in RBAC”, InProc. of the OWLED 2008 Workshop on OWL:Experiences and Directions, 2008.

[9] L. Kagal, T. Berners-Lee, D. Connolly, and D.Weitzner, “Using semantic web technologies for policymanagement on the web”, In Proc. of the 21stNational Conference on Artificial Intelligence (AAAI),2006.

[10] V. Kolovski, J. Hendler, and B. Parsia, “Analyzingweb access control policies”, In Proc. of theInternational World Wide Web Conference (WWW2007), pages 677-686, 2007.

[11] W. Di, L. Jian, D. Yabo, and Z. Miaoliang, “Usingsemantic web technologies to specify constraints ofRBAC”, In Proc. of the Sixth International Conferenceon Parallel and Distributed Computing, Applicationsand Technologies (PDCAT 2005), pages 543-545, 2005.

[12] N. Heilili, Y. Chen, C. Zhao, Z. Luo, and Z. Lin, “AnOWL-Based Approach for RBAC with NegativeAuthorization”, In J. Lang, F. Lin, and J. Wang(Eds.): KSEM 2006, LNAI 4092, pp. 164-175, 2006.

[13] T. Finin, A. Joshi, L. Kagal, J. Niu, R. Sandhu, W.Winsborough, and B. Thuraisingham, “Role BasedAccess Control and OWL”, In Proc. of the fourthworkshop in the The OWL: Experiences and Direction(OWLED), 2008.

[14] M. Knechtel and J. Hladik, “RBAC Authorizationdecision with DL reasoning”, In Proc. of the IADISInternational Conference WWW/Internet, pages169-176, 2008.

[15] L. Cirio, I. F. Cruz, and R. Tamassia, “A Role andAttribute Based Access Control System UsingSemantic Web Technologies”, In Proc. of IFIPInternational Workshop on Semantic Web and WebSemantics (SWWS), pages 1256-1266, 2007.

[16] L. Kagal, T. Finin, and A. Joshi, “A policy basedapproach to security for the semantic web”, In Proc. ofInternational Semantic Web Conference (ISWC 2003),2003.

[17] L. Kagal, T. Finin, and A. Joshi, “A policy languagefor pervasive computing environment”, In Proc. ofIEEE Fourth International Workshop on Policy(Policy 2003), pages 63-76, Italy, 2003.

[18] A. Uszok, J. Bradshaw, R. Jeffers, N. Suri, P. Hayes,M. Breedy, L. Bunch, M. Johnson, S. Kulkarni, and J.Lott, “KAoS policy and domain services: Toward adescription-logic approach to policy representation,deconfliction, and enforcement”, In Proc. of IEEEFourth International Workshop on Policy (Policy2003), pages 93-98, Italy, 2003.

[19] J. Bradshaw, A. Uszok, R. Jeffers, N. Suri, P. Hayes,M. Burstein, A. Acquisti, B. Benyo, M. Breedy, M.Carvalho, D. Diller, M. Johnson, S. Kulkarni, J. Lott,M. Sierhuis, and R.V. Hoof, “Representation andreasoning for daml-based policy and domain servicesin kaos and nomads”, In Proc. of the AutonomousAgents and Multi-Agent Systems Conference(AAMAS 2003), pages 835-842, Australia, 2003.

[20] N. Damianou, N. Dulay, E. Lupu, and M. Sloman,“The ponder policy specification language”, In Proc. ofWorkshop on Policies for Distributed Systems andNetworks (POLICY 2001), UK, 2001.

[21] Y. Zhang and J. Joshi, “Design and Implementation ofa Scaleable GTRBAC System”, Submitted to 2009Annual Computer Security Applications Conference(ACSAC), USA, 2009.

28