Captain Jason Furlong Department of Electrical & Computer Engineering

1. Using Aspect-Oriented Software Development to build a Scenario Based Access Control Reference Monitor Captain Jason Furlong Department of Electrical & Computer Engineering Royal Military College of Canada

2. Outline • Overview of Thesis • Background • Reference Monitor Design • Validation • Discussion & Future Work

3. Overview of Thesis Motivation Goals Results

4. The Problem… • Security is one of many concerns that influence the development of an Enterprise Information System • Access Control is a security sub-concern • Access Control cannot be easily localized. • The implementation of the Security concern must be precise and consistent • Implementation of a Access Control Policy

5. Goals • Use Aspect-Oriented Software Development (AOSD) to separate the Access Control sub-concern in an enterprise application • Create a reusable framework to build a reference monitor • Implement a Scenario Based Access Control model (SBAC)

6. Results • Primary functionality and Access Control were separated • Reusable reference monitor framework created • SBAC model implemented • Two J2EE validation exercises • Polydecompositional Architecture

7. Background Information Aspect Oriented Software Design (AOSD) Reference Monitor Scenario Based Access Control (SBAC)

8. What is AOSD? Aspect-Oriented software Development (AOSD) aims at addressing crosscutting concerns by providing means for their systematic identification, separation, representation and composition. -Awais Rashid

9. Cross-cutting Concerns Source: AspectJ Website and Gregor Kiczales

10. Some Benefits of AOSD • Better separation of concerns • More adaptable and easier to reuse • Simpler System evolution: • Programmer specialization through application transparency Source: Elrad and Coady

11. Reference Monitor • Security Abstraction • Originally conceived as a part of a security kernel and implemented with a combination of hardware and software.

12. Reference Monitor Audit File Subjects Reference Monitor (policy) Objects Access Control Database Source: Morrie Gasser, Building a Secure Computer System, 1988

13. Reference Monitor • An ideal Reference Monitor satisfies these 3 Requirements: • Completeness: It must be impossible to bypass • Isolation: It must be tamperproof • Verifiability: It must be shown to be properly implemented

14. Scenario Based Access Control (SBAC) • Set of scripted scenarios • Mimics the workflow of an enterprise environment • Based on the observability of Objects and their ability to pass messages to each other

15. SBAC (continued) • Permissions rise and fall according the flow of the scenario • In following a Scenario, the model is deterministic and can satisfy a Safety Analysis

16. The AOSD Reference Monitor Design

17. Permissions Scenarios Reference Monitor Design Client Web Aspect PermissionTable Business Logic Database J2EE Application Reference Monitor

18. object Drafter workflow specification Join Point object Cheque SBAC Formal Model SBAC Reference Monitor Intercepted by aspect Reference Monitor modeled as calls class Scenario object Permission Table which creates which creates object SBACPermission object SBACPermission used to find a corresponding permission in stored in permissionList :Hashtable

19. Method Matrix • Needed a rigorous methodology for determining allocation of pointcuts • First validation example had 8 cooperating classes = 56 caller/receiver relationships • Defined both dynamic and static relationships between participating objects

20. Validation Cheque Passing application Certificate Authority application

21. The Implementation Environment • Two Examples operating on a J2EE application server. • Can run on Win32 or *NIX. • HTML user interface using Jakarta-Struts, an MVC framework.

22. The Two Implementations • Cheque example: a set of cooperating objects working within an EJB1. • Built for concurrency of actions • Multiple actors in the scenario 1. EJB: Enterprise Java Bean

23. Cheque Passing Example

24. Certificate Authority Application • Second example: a SOAP-based military HQ Certificate Authority server • Single Threaded • Closer to a real-world Web Services application • Only two actors in the scenario: user and server • Developed from a real-world problem provided by DRDC Ottawa.

25. J2EE Architecture Web Browser Human Interface SAAJ Clients and Servers Machine Interface Client HQManager sends out CRLs Firewall and IPSec device Struts Servlets and JSPs SAAJ Http Servlet Web HQManager Session EJB Change firewall settings or close connections EJB Entity EJBs File System Stores signed certificates Database Stores Certificates, CRLs and client data Persistence IPSec Device checks for certificate validity

26. Discussion & Future Work Some interesting things I found along my journey

27. Benefits of AOSD - revisited • Better separation of concerns • More adaptable and easier to reuse • Simpler System evolution: • Programmer specialization through application transparency and obliviousness

28. Reference Monitor Requirements • Completeness: • Intercepts all calls to an object using AspectJ “wildcards”. • Isolation: • Application by AspectJ would be difficult to subvert by rogue code. • Verifiability: • Uses SBAC, a provably safe Access Control model.

29. Code Weaving J2EE Aspect Pointcuts & Advice Code Weaving SBAC Framework Workflow Model Dependencies SBAC Model Application

30. Polydecompositional Architecture • AOSD permitted simultaneous decomposition of two separate architectures: • Base Functionality • Access Control sub-concern • Combined at compile time • A polydecompositional architecture is a design concept that ensures concern isolation for independent design decomposition before a stage of coalescence to create a software component.

31. Application Transparency • Implementation allowed for pluggable security at compile time. • 2 different build files • Reference monitor framework could be easily rebuilt to allow for run-time switching. • Business logic was almost completely oblivious of security concern

32. AOSD • Limitations of AOSD • AspectJ is a static implementation • Slower run-time implementation; typical AspectJ overhead is between 22% and 2900% • AspectJ was useful for unobtrusive bug tracking and testing with JUnit.

33. SBAC • Working dynamic SBAC reference monitor that can satisfy a safety question • SBAC Doesn’t work for everything, like some J2EE features that require polymorphism. • Building the security model can take time depending on the workflow representation • Policy implementation can be fragile – if workflow changes, then the scenarios have to be rewritten.

34. uses uses uses creates creates pointcut callChequeRegistry(): call(* ChequeRegistry.*(..)) && (within(DrafterClass)|| within(SupervisorClass)|| within(ChequeMailingMachine)); pointcut callSupervisorClass(): call(* SupervisorClass.*(..)) && within(ChequeRegistry); pointcut callDrafterClass(): call(* DrafterClass.*(..)) && (within(ChequeRegistry)|| within(SupervisorClass)); pointcut callChequeMailingMachine(): call(* ChequeMailingMachine.*(..)) && (within(SupervisorClass)); pointcut callChequeSignature(): call(* ChequeSignature.*(..)) && within(SupervisorClass); pointcut callEnvelope(): call(* Envelope.*(..)) && within(ChequeMailingMachine); pointcut callStampRepository(): call(* StampRepository.*(..)) && within(ChequeMailingMachine); produces produces Method Matrix Methodology Functional Requirements Security Policy Workflow SBAC Scenarios Is checked against Method Matrix Pointcut Definitions & Compiler Errors

35. Future Work • Use a dynamic AOSD technology such as AspectWerkz or JBoss-AOP–Clean up some of the pointcuts–Integrate with the J2EE server software • Automate generation of scenarios from Rational Rose (or other UML/MSC tool) • Refine the SBAC framework–Performance–Make the framework more opaque • Implementation in a COTS environment where components aren’t fully trusted

36. Summary • AOSD modularizes cross-cutting concerns • Created Reference monitor using AspectJ that was completely modular • Dynamic Implementation of SBAC using AOSD and AspectJ

37. Questions ?

38. AOSD Technologies • 5 Implementations: • Multidimensional Separation of Concerns • Traversal Specifications • Composition Filters • Class Introduction • Join Point Interception AspectJ

39. Join Point Interception • A family of languages based on a GPL • AspectJ, AspectWerkz, JBoss-AOP (Java) • AspectC++ (C++) • Pythius (Python) • Others based on: Squeak/Smalltalk, XML, C#/.net, Perl, Ruby, UML…

40. Join Points Join Point public void setx(int a) {..} Bar.setx(5) Foo Bar

41. Pointcuts • Named collections of Join Points that have something in common • AspectJ has its own language for describing pointcuts • Can also describe events in the context of other pointcuts • Example: • All the calls to the String class • All the calls to a particular module/package/library that return a Foobar Object

42. Advice • This is the base-language code that has been attached to a particular pointcut or set of pointcuts • 3 types: • Before • After • Around

43. Class Introduction in AspectJ Given: public class Cheque{ private int value;} …and in another module… public aspect ModifiedCheque{ public int Cheque.getValue(){ return value;} }

44. Aspects • Modular entity that consisting of pointcuts and advice. • This is a module in and of itself that can have its own attributes and proprietary methods. • There are also abstract Aspects which can be inherited from.

45. pointcut wildcards advice Sample Aspect import business.cheque; public aspect chequeLogger{ pointcut callChequeSetters(Cheque cheque): call(public * Cheque.set*(..))&& target(cheque); before(): callAllSetters(Cheque cheque){ System.out.println(“Calling set method on cheque” + cheque.toString());} }//end testAspect

46. Class Introduction • Allows the addition of methods, attributes and interfaces to an existing class without subclassing or editing existing code • Violates traditional encapsulation methods

47. Compiler Warnings & Errors • AspectJ pointcuts can be used to generate compiler errors and warnings • Example: • only ChequeRegistry can access a Cheque Object pointcut chequeCalls(): call(public * Cheque.*(..))&& !within(ChequeRegistry); declare error: chequeCalls(): “Security Error: This is a static method access violation";

48. AOSD (continued) • Use of Interface Introduction • Used pointcuts and method introduction to obtain context of some user interface method calls. //serverStatus scenario publicvoid HQManager.SserverStatus(){} publicabstractvoid HQLocal.SserverStatus(); pointcut SserverStatus(HQServerStatusForm form): execution(public HashMap HQServerStatusForm.getStatus())&& this(form); before(HQServerStatusForm form): SserverStatus(form){ form.hqLocal.SserverStatus(); }

49. Join point limitations public void setX(int x); Produces the same join point (and permission) as: public void setX(Integer x); This reduces the obliviousness of the security implementation.

50. Security Policy Implementation • Resultant policy is a set of Message Sequence Charts • I used both high-level and low-level MSCs