This document proposes using model transformations as a way to implement runtime support for rule-based access control evaluation. It describes transforming access control policies defined in a policy language into transformation models that can be executed by a model transformation engine to evaluate access requests. This approach aims to provide reusable and adaptable access control evaluation engines that are independent of specific policy languages. It involves defining metamodels for policies, requests, and evaluations, transforming policies into transformation models, and using additional transformations to implement conflict resolution algorithms. Performance evaluation shows the approach performs comparably to other access control evaluation implementations. The goal is to leverage model transformation techniques to generate reusable and customizable access control evaluation engines.

1. Runtime Support for Rule-Based Access-Control
Evaluation through Model-Transformation
Salvador Martínez - UOC & Mines Nantes-inria-Lina, Nantes, France
Jokin García - IK4-IKERLAN, Arrasate, Spain
Jordi Cabot - ICREA UOC, Barcelona, Spain

2. “The purpose of access control is to limit the Actions or operations that a
legitimate user of a computer system can perform. Access control constrains
what a user can do [...]. In this way access control seeks to prevent activity that
could lead to a breach of security”. Sandhu, Ravi S., and Pierangela Samarati. IEEE communications
magazine 32.9 (1994): 40-48.
Subject
Action Object
Permission
Permission
assignment
Rule: mechanism to assign permissions to Subjects.
Policy: a set of rules defining the security requirements of a system.

3. Access-Control lists (ACL)
Attribute-based Access-Control (ABAC)
Discretionary Access-Control (DAC)
Mandatory Access-Control (MAC)
Identity-Based Access-Control (IBAC)
Organization-based Access-Control (OrBAC)
Role-based Access-Control (RBAC)
Temporal Role-based Access-Control (TRBAC)
Rule-based Access-Control (RAC)

4. Infrastructure components for AC integration:
Design time
(static)
Runtime
(dinamic)
Divided in:

5. Infrastructure: nowadays as reference monitor
1. Language for policies and
access requests. (too many?)
2. Evaluation engine (PDP).
3. Interface mechanism between
access-requests and
resources (PEP). (solved by
AOP and the like)

6. Problem?
Focus is in Access-control languages and not in their evaluation.
Lack of reusable PDPs. Existing “reusable” PDPs are tight to concrete access-
control languages (e.g. XACML, EPAL).
PDPs as black boxes, difficult to adapt to different situations.
We are obliged to reinvent the wheel!!

7. Requirements: what would be a better situation?
Easy to use. Concrete syntax should be easy to adapt (without changing the rest)
The policy representation should be explicit. The evaluation execution should be
adaptable: add tracing, enhance outcome, etc.
Efficiently capable to face complex escenarios (live evaluation): Lazy execution,
incremental evaluation, reactivity...

8. Request Decision
Rule1 (conditions)-> decision
Rule2 (conditions)-> decision
Rule3 (conditions)-> decision
Evaluation Engine
Read policy
Rule1 match request (with conditions) to decision
Rule2 match request (with conditions) to decision
Rule3 match request (with conditions) to decision
Transformation Engine
Read transformation
Request Model Decision Model
find rule
evaluate conditions
issue decision
match request
evaluate guards
create decision model

9. Approach:
● Basic ready-to-use workflow
● Advanced fully-tunable workflow

10. Basic Workflow
Policy
PEP-PDP
Decision
Write security
policy rules
using policy
language
Write access
requests using
Access
language
read
Issue
access
decision
Rule r1 (
Subject S1 {attributes <'role' = 'Manager'>},
Object O1,
Action Read
) -> Accept
Rule r2 (
Subject S2 {attributes <'role' = 'Employee'>},
Object O1,
Action Read
) -> Deny
Access(
Subject S1 {attributes <'role' = 'Manager'>},
Object O1,
Action Read
)

11. Module SecurityPolicy create OUT: Evaluation from IN: Request;
nodefault rule rule1 {
from
s:Req!Requests (
s.filter(Sequence{Tuple{id='S1', attributes = Sequence{Tuple{name = 'role', value = 'manager'}}},
Tuple{id='O1', attributes = Sequence{}},
Tuple{id='read', attributes = Sequence{}}}))
to
t : Evaluation!Evaluation (
effect <- 'Permit',
ruleId <- 'Rule1',
ruleOrder <- 1)
}
nodefault rule rule2 {
from
s:Req!Requests (
s.filter(Sequence{Tuple{id='S2', attributes = Sequence{Tuple{name = 'role', value = 'employee'}}},
Tuple{id='O1', attributes = Sequence{}},
Tuple{id='read', attributes = Sequence{}}}))
to
t : Evaluation!Evaluation (
effect <- 'Deny',
ruleId <- 'Rule2',
ruleOrder <- 2)
}

12. Security Policy
Policy Model
Trasf. Model
HOT: Policy
to
Transformation
Transformation
code
Request model Eval. model
Request
metamodel
Evaluation
metamodel
Transf.
metamodel
RULE COMBINATION
ALGORITHMS
-first match
-deny overrides
-accept overrides
-others...
Refining
Transf.
refines
implements
Policy.
metamodel
1
2
3
4
1
2
3
4
Language dependent
Language independent
injection
Advanced
Workflow

13. Implementation with ATL
(and other modeling tools)

14. 1.Policy
Metamodel
& Injection

15. XText Grammar…
Policy:
rules+=Rule*;
Rule returns Rule:
'Rule' id=ID '(' lhs=LHS ')' '->' rhs=RHS;
LHS returns LHS:
conditionfields += ConditionField ("," conditionfields +=
ConditionField)*;
RHS returns RHS:
decisions+=AccessDecision;
ConditionField:
(Subject | Object | Action)
(
'{'('attributes' '<' attributes+=Attribute ( ","
attributes+=Attribute)* '>' )?
'}')? ;
Attribute returns Attribute:
{Attribute} name=EString '=' value=EString;
...
...

16. 2. HOT: From policies to trans. specifications
What the HOT transformation does:
1. Creates a transformation module from the policy root.
2. Creates OCL operations to factorize the encoding of access-request
conditions into OCL predicates.
3. Creates an ATL rule for each access-control rule with:
- Match : Request element
- A guard calling the OCL operation that evaluates the conditions
- Generates as output an Evaluation element with a decision (and some tracing info.)

17. HOT: Looks… scary? It is at least tedious...
rule Rule2MatchedRule {
from
s : Policy!Rule
to
mr : ATL!MatchedRule (
name <- s.id,
isNoDefault <- true,
isAbstract <- false,
isRefining <- false,
inPattern <- ip,
outPattern <- op
),
-- start from part
ip : ATL!InPattern (
elements <- Sequence{ipe},
filter <- filter
),
ipe : ATL!SimpleInPatternElement(
varName <- 's',
type <- ipet
),
-- start filter
filter: ATL!OperationCallExp (
operationName <- 'filter'
),
fvar: ATL!VariableExp (
referredVariable <- ipe,
appliedProperty <- filter
),
fseq: ATL!SequenceExp(
parentOperation <- filter
),
fsub: ATL!TupleExp (
collection <- fseq
--retrieve subject attributes
),
fobj: ATL!TupleExp (
collection <- fseq
--retrieve objetc attributes
),
fact: ATL!TupleExp (
collection <- fseq
--retrieve action attributes
),
--end filter
ipet : ATL!OclModelElement (
name <- 'Request',
model <- om
),
om : ATL!OclModel (
name <- 'Request'
),
--end from part
--begin to part
op : ATL!OutPattern (
elements <- Sequence{ope}
),
ope : ATL!SimpleOutPatternElement(
varName <- 't',
type <- opet,
bindings <- Sequence{b1, b2}
),
opet : ATL!OclModelElement (
name <- 'Evaluation',
model <- om2
),
om2 : ATL!OclModel (
name <- 'Evaluation'
),
--begin bindings
b1 : ATL!Binding (
propertyName <- 'effect',
value <- se1
),

18. HOT: Generating it from the Policy metamodel
rule Rule2MatchedRule {
from
s : Policy!Rule
to
mr : ATL!MatchedRule (
name <- s.id,
isNoDefault <- true,
isAbstract <- false,
isRefining <- false,
inPattern <- ip,
outPattern <- op
Modular Acceleo
templates
Metamodel ATL HOT

19. 3. Conflict Resolution
create OUT: Evaluation refining IN: Evaluation;
helper context Evaluation!Evaluation
def:isFirstMatch():Boolean =
let allEvaluations :
Sequence(Evaluation!Evaluation) =
Evaluation!Evaluation.allInstances()
->asSequence() in
allEvaluations->iterate(p; y : Boolean = true |
if p.request.toInteger() <
self.request.toInteger() then
false
else
if y = true then
true
else
false
endif
endif);
rule Evaluation {
from
s : Evaluation!Evaluation(s.isFirstMatch())
to
t : Evaluation!Evaluation ()}
Resolution algorithms as refining
transformations on Evaluations:
- First match
- Deny overrides
- Accept overrides
- Others
Completely independent from the
policy language.

20. Performance Evaluation

21. Conclusions
Model transformation engines can be used as AC evaluation engines.
An important amount of work can be delegated to “generators”.
Performance (often a problem in MDE) is in par with other implementations.
Future work
Multi-policy environments.
Experimenting alternatives execution modes (Lazy, incremental, reactive, parallel).
Validation and Verification of the policy by using MT V&V techniques.

22. Questions time!!