eunjee song computer science department baylor university october 25, 2008 a rigorous approach to...

Eunjee SongComputer Science Department

Baylor UniversityOctober 25, 2008

A Rigorous Approach to Incorporating Access Control Features

into Applications

2

Presentation Outline

Motivation

Background

Model-Driven Engineering (MDE)

Aspect Oriented Modeling (AOM)

Verifiable Composition Overview

Summary & Contribution

Other Research Topics

3

Motivation

Example: Banking Application

Access control policy features are often spread across and tangled with other functionality in a design.

ATMAccess Control Features Electronic

Funds Transfer

Access Control Features

Customer Information Management

Access Control Features

Policy

Changed!

4

maintain independently

is appliedis appliedis applied

Motivation

ATM Customer Information Management

Access

Control

Features

Access

Control

Features

Access

Control

Features

Access Control Pattern

ElectronicFunds Transfer

Separate access control features from application

5

is appliedis applied

Motivation

Loan

Management

Access Control Pattern

incorporating a pattern into other applications

Does the resulting system have

desired properties?

E-commerce

Program? Design?

What is Model-Driven

Engineering (MDE)?

7

S_2

S_22

S

S_2

C

S_1

S_21

S_22S_21

1 1

Secondary Actor

Use Case 1

Primary Actor

Use Case 2

Use Case 3

INFORMALGRAPHICALLANGUAGES


PRODUCT CODE

PRODUCTREQUIREMENTS

MIDDLEWARE, OS, PLATFORM

UNIT TEST

“Old” Software Development Process

Source: taken from slides by Dr. T. Weigert, @ U. of Missouri-Rolla

8

PRODUCT CODEUNIT TEST


ERROR-PRONEAND SLOW;

DIFFICULT TOREUSE

S_2

S_22

S

S_2

C

S_1

S_21

S_22S_21

1 1

Secondary Actor

Use Case 1

Primary Actor

Use Case 2

Use Case 3



INFORMALITYAND IMPRECISION

LEAD TO MISUNDER-STANDINGS

LONG DELAY TOREPAIR DEFECTS

ESCAPINGINSPECTION

PRODUCTREQUIREMENTS

DEFECTSREPAIRED ATCODE LEVEL

“Old” Software Development Process


9

PRODUCT CODEUNIT TEST

VERIFICATION

Model-Driven EngineeringSTART

-

always takes too long

MEETING

PRESENT ARGUMENTS

COMPANY X OPINION

MOTOROLA OPINION

THROW OUT IDEA

COMPANY Y OPINION

AGREESUPERIOR ARGUMENT

COFFEE BREAK

where the real work is done

PROPOSE DECISION

MEETING AGREES

LUNCHwell deserved

MOTOROLAWITH

{ int value;sll_ptr *s;{ sll_ptr *ptr1, *ptr2 = s;

if (value == s->car) {s = s->next;free(ptr2);

} else {ptr1 = ptr2;while (((ptr2 = ptr2->next)!=NULL)

&& (!found))if (value == ptr2->car) {

found = TRUE;ptr1->next = ptr2->next;free(ptr2);

} else ptr1 = ptr2;} } }

STANDARDDESIGN

NOTATIONS

STANDARDDESIGN

NOTATIONS

CODE GENERATOR

UK USA RMTR

air_in

taxi_in

taxi_out

air_out


PRODUCTREQUIREMENTS

Developdomain-specific

notations

Developverificationtechnology Develop

code generators


Why aspect-oriented modeling/

programming?

from “Aspect-oriented modeling the past, present and the future” presented on AOSD conference by Dr. Aksit

11

software modules

Spreading and tangling of crosscutting concerns (29 % LOC)

In yellow colored code, access permissions are checked.

In blue colored code, some parameters of certain functions are checked.

In red colored code, some variable values are tested and in case of error conditions, some actions are carried out.

12

Aspect-oriented modeling problems

These concerns are spread and tangled;

These concerns have their own life-time;

These concerns crosscut the “logical decomposition” of software;

In case these concerns are not separated/composed explicitly, the complexity increases, and the evolution of software becomes problematic (results in redefinitions of the exiting code).

13

Aspect-Oriented Software Development (AOSD)

Aspect-Oriented Programming (AOP)

Capturing behaviors that crosscut across many units of abstraction in a given software application

Aspect-Oriented Software Development (AOSD)

refers the complete software development life cycle evolving the aspect –orientation process

14

Approaches to Realize Aspect-Orientation

Extensions to existing languages such as Java,

C, and C++ (e.g., Hyper/J, AspectJ)

Modeling with (suitable extensions of) UML

Frameworks for introducing aspect orientation

without changing existing languages (e.g.,

Spring, JBoss)

15

Aspect Model 1

Aspect Model N

Primary Model Composed Model

…

Aspect-OrientedDesign Model

Aspect Model 2

Model

Composition

Model

Analysis

AOM Overview

Aspect-Oriented Modeling

16

Aspect-Oriented Modeling

service logging aspect

ba c dwoven model

attack model

simulate threat scenario on

ba c

access control aspect

a b cprimary model

woven model

compose with

to producecompose with

to produce

17

Overview of the Approach:A Banking Example

bankingapplicationmodel

banking domain

name space

model element names

access control features as a pattern

(generic RBAC)

bindingvalues

context-specificaccess control features

(banking-specific RBAC)

instantiate

necessary property

verifiablecomposition

proofobligation

composed model

19

A Banking Application Model:Class Diagram

Account withdraw(amount:Money)

deposit(amount:Money)

Controller

transfer(fromAccount:Account, toAccount:Account, amount:Money)

withdraw(fromAccount:Account, amount:Money)

deposit(toAccount:Account, amount:Money)

*

1

1

BankUser *

20

A Banking Application Model:transfer operation Sequence Diagram

:BankUser :Controller

toAccount

:Accounttransfer(…)

withdraw(…)

deposit(…)

fromAccount:Account

context Controller:: transfer(fromAccout:Account, toAccount:Account,amount:Money) : Boolean

pre: truepost: result =

(fromAccount^withdraw(amount).hasReturned() and fromAccount^withdraw(amount).result() = true)

and (toAccount^deposit(amount).hasReturned() and toAccount^deposit(amount).result() = true)

Postcondition of Controller::transfer

withdraw message sent to fromAccount has returned and result=true

deposit message sent to toAccount has returned and result=true

21

Instantiating a Generic RBAC



(generic RBAC)

banking domain

name space

model element names



bindingvalues

instantiate

22

A Context-specific RBAC Class Diagram

BankUser PermissionBankRole

TransactionType

BankSession

checkAccess(tar:Account, op:TransactionType)

transfer(fromAccount:Account, toAccount:Account, amount: Money)

AssignTo

Has

InitiatesSessionRole

EnforcedOnBasedUpon

1..*

1..* 1..*

1

withdraw(fromAccount:Account, amount: Money)

deposit(toAccount:Account, amount: Money)

1..*1..*

1..*

1..* 1..*

1..*1..*

Account

<<|User >>

<<|Target>>

<<|Role>>

<<|OperationType>>

<<|Permission>>

<<|Session>>

<<|Operation>>

<<|CheckAccess>>

23

Verifiable Composition



(generic RBAC)

banking domain

name space

model element names



bindingvalues

instantiate

necessary property

(P2)

verifiablecomposition

composed model

proofobligation

(P1)

(P1 implies P2)

24

Composed Class Diagram

BankUser PermissionBankRole

TransactionType

BankSession

checkAccess(tar:Account, op:TransactionType)


AssignTo

Has

InitiatesSessionRole

EnforcedOnBasedUpon

1..*

1..* 1..*

1



1..*1..*

1..*

1..* 1..*

1..*

1..*

Account

withdraw(amount: Money)

deposit(amount: Money)




Controller1

1

11..*

1..*

25

Necessary Property (P2) for transfer: TransferProp

If the transfer operation is authorized on the specified two accounts, if the source account has enough funds to

cover the transfer amount then the funds are transferred by the

time the transfer operation terminates.

Otherwise the fund will not be transferred.

necessary property

26

Necessary Property (P2) for transfer: TransferProp

context BankSession:: transfer(fromAccout:Account, toAccount:Account,amount:Money) : Boolean

verify TransferProp:

let successful-transfer =

(if fromAccount.balance@pre >= amount

then (fromAccount.balance = fromAccount.balance@pre - amount

and toAccount.balance = toAccount.balance@pre + amount))

in

if (self^checkAccess(fromAccount, TRANSFER).hasReturned() and self^checkAccess(fromAccount, TRANSFER).result()=true) and

(self^checkAccess(toAccount, TRANSFER).hasReturned() and self^checkAccess(toAccount, TRANSFER).result()=true)

then successful-transfer

necessary property

27

Verifiable CompositionOverview

Verifiable properties concerned with effects of operations

Proof obligations evolve during composition of sequence diagrams describing operations

Proof obligation: P1 implies P2 P1: the postcondition under which transfer

operation in BankSession of the composed model returns true

P2: the necessary property for the transfer operation behavior, TransferProp.

28

Incorporating Access Control Features into Applications: An Example

transferwithdraw

RBAC

deposit

RBAC

An RBAC aspect is incorporated into a sample banking application

RBAC

30

Suggested Solutions

transferwithdraw

RBAC

deposit

transferwithdraw

RBAC

deposit

RBAC

Changing the way to incorporate the pattern using composition directives

Adding an invariant guaranteeing access to withdraw and deposit whenever access to transfer is guaranteed.

31

Summary

Separating access control features as

patterns

Verifiable composition through generation

of proof obligations

Discharging proof obligation systematically

33

Other Research Topics

Verifiable compositions of models with automating the discharge of proof obligations

using Alloy, USE, or UMLSec with graph-based composition techniques (e.g.,

MATA) with meta-level composition techniques (e.g.

Komposer)

Improving adaptability & fragility in AOM/AOP Model Interfaces (for two-way obliviousness) in AOM

XMI-based model/constraint transformation

34

Thank you very much!

Questions?

eunjee song computer science department baylor university october 25, 2008 a rigorous approach to...

Documents

rolla slide

application slide

access permissions

aksit slide

primary actor use case

secondary actor use

research topics slide

code generators source