1 / 33

A Rigorous Approach to Incorporating Access Control Features into Applications

A Rigorous Approach to Incorporating Access Control Features into Applications. Eunjee Song Computer Science Department Baylor University October 25, 2008. Presentation Outline. Motivation Background Model-Driven Engineering (MDE) Aspect Oriented Modeling (AOM)

greg
Télécharger la présentation

A Rigorous Approach to Incorporating Access Control Features into Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

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

  9. Develop domain-specific notations STANDARDDESIGNNOTATIONS Develop verification technology Develop code generators UK USA RMTR air_in taxi_in CODE GENERATOR taxi_out air_out VERIFICATION PRODUCT CODE UNIT TEST Model-Driven Engineering PRODUCT REQUIREMENTS MIDDLEWARE, OS, PLATFORM 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. software modules Spreading and tangling of crosscutting concerns (29 % LOC) In yellow colored code, access permissions are checked. In red colored code, some variable values are tested and in case of error conditions, some actions are carried out. In blue colored code, some parameters of certain functions are checked.

  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) • Frameworks for introducing aspect orientation without changing existing languages (e.g., Spring, JBoss) • Modeling with (suitable extensions of) UML

  15. Model Composition Aspect Model 1 Aspect Model 2 Composed Model Aspect Model N Model Analysis Primary Model Aspect-Oriented Modeling Aspect-Oriented Design Model … AOM Overview

  16. primary model a b c a b c woven model a b c d Aspect-Oriented Modeling attack model access control aspect compose with simulate threat scenario on service logging aspect compose with to produce woven model to produce

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

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

  19. A Banking Application Model:Class Diagram * BankUser 1 Controller transfer(fromAccount:Account, toAccount:Account, amount:Money) withdraw(fromAccount:Account, amount:Money) deposit(toAccount:Account, amount:Money) Account 1 withdraw(amount:Money) deposit(amount:Money) *

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

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

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

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

  25. necessary property 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.

  26. necessary property 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

  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. RBAC RBAC RBAC Incorporating Access Control Features into Applications: An Example • An RBAC aspect is incorporated into a sample banking application transfer withdraw deposit

  29. RBAC RBAC RBAC Suggested Solutions • 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. transfer transfer withdraw withdraw deposit deposit

  30. Summary • Separating access control features as patterns • Verifiable composition through generation of proof obligations • Discharging proof obligation systematically

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

  32. Thank you very much! Questions?

More Related