Runtime Support for Rule-Based Access-ControlEvaluation through Model-Transformation

Salvador Martínez - UOC & Mines Nantes-inria-Lina, Nantes, FranceJokin García - IK4-IKERLAN, Arrasate, SpainJordi Cabot - ICREA UOC, Barcelona, Spain

“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.

SubjectAction Object

PermissionPermissionassignment

Rule: mechanism to assign permissions to Subjects.

Policy: a set of rules defining the security requirements of a system.

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)

Infrastructure components for AC integration:

Design time(static)

Runtime(dinamic)

Divided in:

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)

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!!

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...

Request

Decision

Rule1 (conditions)-> decisionRule2 (conditions)-> decisionRule3 (conditions)-> decision

Evaluation Engine

Read policy

Rule1 match request (with conditions) to decisionRule2 match request (with conditions) to decisionRule3 match request (with conditions) to decision

Transformation Engine

Read transformationRequest Model Decision Model

find ruleevaluate conditionsissue decision

match requestevaluate guardscreate decision model

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

Basic Workflow

Policy

PEP-PDP

Decision

Write securitypolicy rulesusing policy language

Write accessrequests usingAccesslanguage

read

Issueaccessdecision

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)

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)}

Security Policy

Policy Model

Trasf. Model

HOT: Policy to

Transformation

Transformationcode

Request model Eval. model

Request metamodel

Evaluation metamodel

Transf. metamodel

RULE COMBINATIONALGORITHMS

-first match-deny overrides-accept overrides-others...

Refining Transf.

refines

implements

Policy. metamodel

1

2

3

41

2

3

4

Language dependent

Language independentinjection

Advanced Workflow

Implementation with ATL (and other modeling tools)

1.Policy Metamodel& Injection

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;......

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.)

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 filteripet : ATL!OclModelElement ( name <- 'Request', model <- om),

om : ATL!OclModel ( name <- 'Request' ),--end from part--begin to partop : 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 bindingsb1 : ATL!Binding ( propertyName <- 'effect', value <- se1),

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

3. Conflict Resolutioncreate OUT: Evaluation refining IN: Evaluation;

helper context Evaluation!Evaluationdef: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.

Performance Evaluation

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.

Questions time!!