1. Eunjee Song Computer Science Department Baylor University October 25, 2008 A Rigorous Approach to Incorporating Access Control Features into Applications

2. 2 Presentation Outline  Motivation  Background  Model-Driven Engineering (MDE)  Aspect Oriented Modeling (AOM)  Verifiable Composition Overview  Summary & Contribution  Other Research Topics

3. 3 Motivation Example: Banking Application  Access control policy features are often spread across and tangled with other functionality in a design. ATM Access Control Features Electronic Funds Transfer Access Control Features Customer Information Management Access Control Features Policy Changed!

4. 4 maintain independently is applied Motivation ATM Customer Information Management Access Control Features Access Control Features Access Control Features Access Control Pattern Electronic Funds Transfer  Separate access control features from application

5. 5 is applied Motivation Loan Management Access Control Pattern incorporating a pattern into other applications  Does the resulting system have desired properties? E-commerce Program? Design?

6. What is Model-Driven Engineering (MDE)?

7. 7 S_2 S_22 S S_2 C S_1 S_21 S_22 S_21 1 1 Secondary Actor Use Case 1 Primary Actor Use Case 2 Use Case 3 INFORMAL GRAPHICAL LANGUAGES INFORMAL GRAPHICAL LANGUAGES PRODUCT CODE PRODUCT REQUIREMENTS MIDDLEWARE, OS, PLATFORM UNIT TEST “Old” Software Development Process Source: taken from slides by Dr. T. Weigert, @ U. of Missouri-Rolla

8. 8 PRODUCT CODE UNIT TEST MIDDLEWARE, OS, PLATFORM ERROR-PRONE AND SLOW; DIFFICULT TO REUSE S_2 S_22 S S_2 C S_1 S_21 S_22 S_21 1 1 Secondary Actor Use Case 1 Primary Actor Use Case 2 Use Case 3 INFORMAL GRAPHICAL LANGUAGES INFORMAL GRAPHICAL LANGUAGES INFORMALITY AND IMPRECISION LEAD TO MISUNDER- STANDINGS LONG DELAY TO REPAIR DEFECTS ESCAPING INSPECTION PRODUCT REQUIREMENTS DEFECTS REPAIRED AT CODE LEVEL “Old” Software Development Process Source: taken from slides by Dr. T. Weigert, @ U. of Missouri-Rolla

9. 9 PRODUCT CODE UNIT TEST VERIFICATION Model-Driven Engineering STANDARD DESIGN NOTATIONS CODE GENERATOR UKUSARMTR air_in taxi_in taxi_out air_out MIDDLEWARE, OS, PLATFORM PRODUCT REQUIREMENTS Develop domain-specific notations Develop verification technology Develop code generators Source: taken from slides by Dr. T. Weigert, @ U. of Missouri-Rolla

10. Why aspect-oriented modeling/ programming? from “Aspect-oriented modeling the past, present and the future” presented on AOSD conference by Dr. Aksit

11. 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. 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. 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. 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. 15 Aspect Model 1Aspect Model NPrimary ModelComposed Model … Aspect-Oriented Design Model Aspect Model 2 Model Composition Model Analysis AOM Overview Aspect-Oriented Modeling

16. 16 Aspect-Oriented Modeling service logging aspect bacd woven model attack model simulate threat scenario on bac access control aspect abc primary model woven model compose with to producecompose with to produce

17. 17 Overview of the Approach: A Banking Example banking application model banking domain name space model element names access control features as a pattern (generic RBAC) binding values context-specific access control features (banking-specific RBAC) instantiate necessary property verifiable composition proof obligation composed model

18. 18 Generic RBAC: Class Diagram Template |User|Permission|Role |OperationType |Target |Session |CheckAccess(|tar:|Target, |op:|OperationType) |Operation(|tar:|Target 1..*, |params*) |UserAssignment |PermAssignment |UserSession |SessionRole |PermTarget |PermOp |a |b |c |d |i |f |e |h |g 1

19. 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. 20 A Banking Application Model: transfer operation Sequence Diagram :BankUser:Controller toAccount :Account transfer(…) withdraw(…) deposit(…) fromAccount:Account context Controller:: transfer(fromAccout:Account, toAccount:Account,amount:Money) : Boolean pre: true post: 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. 21 Instantiating a Generic RBAC banking application model access control features as a pattern (generic RBAC) banking domain name space model element names context-specific access control features (banking-specific RBAC) binding values instantiate

22. 22 A Context-specific RBAC Class Diagram BankUser Permission BankRole TransactionType BankSession checkAccess(tar:Account, op:TransactionType) transfer(fromAccount:Account, toAccount:Account, amount: Money) AssignTo Has Initiates SessionRole EnforcedOn BasedUpon 1..* 1 withdraw(fromAccount:Account, amount: Money) deposit(toAccount:Account, amount: Money) 1..* Account >

23. 23 Verifiable Composition banking application model access control features as a pattern (generic RBAC) banking domain name space model element names context-specific access control features (banking-specific RBAC) binding values instantiate necessary property (P2) verifiable composition composed model proof obligation (P1) (P1 implies P2)

24. 24 Composed Class Diagram BankUser Permission BankRole TransactionType BankSession checkAccess(tar:Account, op:TransactionType) transfer(fromAccount:Account, toAccount:Account, amount: Money) AssignTo Has Initiates SessionRole EnforcedOn BasedUpon 1..* 1 withdraw(fromAccount:Account, amount: Money) deposit(toAccount:Account, amount: Money) 1..* Account withdraw(amount: Money) deposit(amount: Money) transfer(fromAccount:Account, toAccount:Account, amount: Money) withdraw(fromAccount:Account, amount: Money) deposit(toAccount:Account, amount: Money) Controller 1 1 1 1..*

25. 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. 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. 27 Verifiable Composition Overview  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. 28 Incorporating Access Control Features into Applications: An Example transfer withdraw RBAC deposit RBAC  An RBAC aspect is incorporated into a sample banking application RBAC

29. 29

30. 30 Suggested Solutions transfer withdraw RBAC deposit transfer withdraw 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. 31 Summary  Separating access control features as patterns  Verifiable composition through generation of proof obligations  Discharging proof obligation systematically

32. 32 Contribution  Provides techniques to use an AOM approach for  Checking policy enforcement in an access control aspect model  Integrating multiple access control aspects to enforce the hybrid access control policy  Eases tasks of analyzing access control features during the design: Verifiable composition  Helps early identification of errors arising from faulty interactions among access control features and other application features.

33. 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. 34 Thank you very much! Questions?