As shown in chapter 3, the GemRBAC+CTX model, which is the conceptual RBAC model on top of which GemRBAC-DSL has been designed, comes with an operationalization of the semantics of the policies it supports. Since the GemR- BAC+CTX model and GemRBAC-DSL have the same expressiveness, we can define the semantics of GemRBAC-DSL by mapping its constructs to the corre- sponding OCL constraints defined for the GemRBAC+CTX model.
Each entity in the hpreamblei of a GemRBAC-DSL specification corresponds to an instance of a UML class in the GemRBAC+CTX model: users, roles, permissions, operations, and logical locations (hgeofencesi) are mapped to instances of the homonymous classes in GemRBAC+CTX. Similarly, role and permission hierarchies correspond to the homonymous associations in the GemRBAC+CTX model.
Each type of RBAC policy is mapped to the corresponding OCL constraint template defined in the GemRBAC+CTX model; in each template the symbolic parameters are replaced with the actual entities used in the specification. For instance, the semantics of the object-based DSoD policy
objDSoD: conflicting-roles-activation author, reviewer on-same-object;
can be defined by the OCL invariant DSoDCR of the class Session (introduced on
page 27), by replacing the parametersr1 and r2 with roles authorand reviewer.
Regarding contextual policies, the context to be assigned/enabled (as pre- scribed by the policy) is represented in the GemRBAC+CTX model, as an asso- ciation with the corresponding role/permission. For example, consider the policy
which enables role employee only inside the logical location denoted by the la- bel “office”. Figure 4.2 depicts an excerpt of an instance of the GemRBAC+CTX model in which roleemployeeis associated to aSpatialContextobject that contains
the object LLEmployee of type LogicalLocation, which denotes the location “of-
fice”. This object is associated with object rloc1 of typeRelativeLocation, which
contains aQualitativeDirection. The policy loc can be mapped to the OCL in-
variant relativeLocationRoleEnabling of class Session (introduced on page 40),
parametrized with roleemployee.
Expressing the semantics of GemRBAC-DSL policies as OCL constraints on the GemRBAC+CTX model enables the users of the language to benefit from the model-driven policy enforcement mechanisms as we will show in chapter 6. Briefly, making an access decision for a policy can be reduced to checking the corresponding OCL constraint on a instance of the GemRBAC+CTX model, which represents a snapshot of the system at a certain time.
Table 4.1: Mapping of GemRBAC-DSL constructs to OCL constraints on the GemRBAC+CTX model
Type of policy OCL constraint ref
hPrereqRolei context User inv PreqRole page 24
hPrereqPermissioni context Role inv PreqPermisssion page 24
hCardActivationi context Session inv CardinalityActivation
page 24 hCardUseri context User inv CardinalityRole page 24
hCardPermissioni This policy is expressed in a similar way as the previous one by replacing the context of
Userwith the context of Permission.
page 24 hCardRoletoPermissioni context Role inv CardinalityPermission page 24
hCardRoletoUseri This policy is expressed in a similar way as the previous one by replacing the instances
of permissions with instances of users.
page 24 hPrecEnablingi context inv RoleEnablingPrecedence page 25
Dependency hPrecEnablingi
context Session inv RoleActivationDependency
page 25 hRoleHierarchyi context User inv RoleHierarchy page 26
hPermissionHierarchyi context Role inv RoleHierarchy page 26
hSSoDCU i context Role inv SSoDCU page 26
hSSoDCRi context User inv SSoDCR context Role inv SSoDCP2
page 26 hSSoDCRi context User inv SSoDCR
context Role inv SSoDCP2
page 26
hSSoDCPi context Role inv SSoDCP1 page 26
hDSoDCRi context Session inv DSoDCR page 27
hDSoDCU i context Role inv DSoDCU web1
hDSoDCPi context Role inv DSoDCP web1
hDSoDCRi context Session inv ObjectDSOD page 27
hDSoDCRi context Session inv OperationalDSoD page 28
hDSoDCRi context Session inv HistoryDSOD page 29
Role-based hBoDi context Session inv RoleBoD page 29
Subject-based hBoDi context Session inv SubjectBoD page 30
hDelegationi context Delegation inv TotalDelegation context Delegation inv
MultiStepDelegation context delegation inv PartialDelegation
context Delegation inv StrongTransfer context Delegation inv
StaticWeakTransfer context Delegation inv DynamicWeakTransfer context Delegation inv AutomaticRevocation
page 32
hRevocationi context Delegation inv RevacationDependency
context Delegation inv StrongRevocation context Delegation inv
CascadingRevocation
page 33
TPA with
habsoluteTimei
context Session inv AbsoluteBTIRoleEnab context Permission inv
AbsoluteBTIPermAssign
context Role inv AbsoluteTPRoleAssign context Role inv AbsoluteUBIRoleAssign
page 35 web2
TPA with
hperiodicTimei
context Role inv
periodicUnboundTIRoleAssign
page 38
TPA with
hactiveDurationi
context Session inv
DurationAbsoluteBTIRoleEnab
page 38 TPRInd
hsDayOfWeeki
context Role inv indexRoleAssign page 37
TPRH hiHouri context Role inv
RelativeHoursRoleAssign
web2 TPRDM
hdayOfMonthH i
context Role inv
DayOfMonthHoursRoleAssign context Permission inv DayOfMonthHoursPermAssign
web2
TPRDW hdayOfWeekH i
context Permission inv DayOfWeekHourPermAssign
page 36 TPRMD
hmonthDayOfWeekH i
context Role inv
MonthDayOfWeekHourRoleAssign
web2
TPCT
hcompositeTimei
This policy can be checked by a logical conjunction of two temporal policies: one with absolute time and one with relative time.
SPP hphysicalLocationi context Role inv
physicalLocationRoleAssign
page 39 SPL hgeofencei context Session inv
logicalLocationRoleEnabling
page 40 SPR hrelativeLocationi context Session inv
relativeLocationRoleEnabling
page 40 SPThSpatioTemporali This policy can be checked by a logical conjunction
of the spatial and temporal policies.
Legend. TP: temporal policy; TPA: TP with absolute time; TPR: TP with rel-
ative time; TPRInd: TPR containing an index; TPRH: TPR of type hour inter-
val; TPRDM: temporal policy with a relative time of type day of month that op- tionally overlays hours; TPRDW: TPR of type day of week that optionally over- lays hours; TPRMD: TPR of type day of month that optionally overlays days of week (the days of week may optionally overlay hours); TPCT: TP with compos- ite time; SP: spatial policy; SPP: SP with a physical location; SPL: SP with a logical location; SPR: SP with a relative location; SPT: spatio-temporal policy.
Table 4.1 describes the mapping of each RBAC policy supported by GemRBAC- DSL to its corresponding OCL constraint(s) defined on the GemRBAC+CTX model. The first column indicates the type of policy and the corresponding gram- mar rule. The second column denotes the corresponding OCL constraints, whose full definition can be found in the reference indicated in the third column. The ref- erence “web” and “web2” are the websiteshttps://github.com/AmeniBF/GemRBAC-model
and https://github.com/AmeniBF/GemRBAC-CTX-model.git, respectively.