Title: Using%20Aspect-Oriented%20Software%20Development%20to%20build%20a%20Scenario%20Based%20Access%20Control%20Reference%20Monitor
1Using 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
2Outline
- Overview of Thesis
- Background
- Reference Monitor Design
- Validation
- Discussion Future Work
3Overview of Thesis
4The 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
5Goals
- 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)
6Results
- Primary functionality and Access Control were
separated - Reusable reference monitor framework created
- SBAC model implemented
- Two J2EE validation exercises
- Polydecompositional Architecture
7Background Information
- Aspect Oriented Software Design (AOSD)
- Reference Monitor
- Scenario Based Access Control (SBAC)
8What is AOSD?
Aspect-Oriented software Development (AOSD) aims
at addressing crosscutting concerns by providing
means for their systematic identification,
separation, representation and composition. -Awai
s Rashid
9Cross-cutting Concerns
Source AspectJ Website and Gregor Kiczales
10Some 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
11Reference Monitor
- Security Abstraction
- Originally conceived as a part of a security
kernel and implemented with a combination of
hardware and software.
12Reference Monitor
Audit File
Subjects
Reference Monitor (policy)
Objects
Access Control Database
Source Morrie Gasser, Building a Secure Computer
System, 1988
13Reference 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
14Scenario 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
15SBAC (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
16The AOSD Reference Monitor Design
17Reference Monitor Design
Client
Web
Aspect
PermissionTable
Business Logic
Database
J2EE Application
Reference Monitor
18SBAC 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
19Method 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
20Validation
- Cheque Passing application
- Certificate Authority application
21The 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.
22The 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
23Cheque Passing Example
24Certificate 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.
25J2EE 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
26Discussion Future Work
- Some interesting things I found along my journey
27Benefits of AOSD - revisited
- Better separation of concerns
- More adaptable and easier to reuse
- Simpler System evolution
- Programmer specialization through application
transparency and obliviousness
28Reference 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.
29Dependencies
SBAC Model
Application
30Polydecompositional 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.
31Application 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
32AOSD
- 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.
33SBAC
- Working dynamic SBAC reference monitor that can
satisfy a safety question - SBAC Doesnt 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.
34Method Matrix Methodology
Functional Requirements
Security Policy
Workflow
SBAC Scenarios
Is checked against
Classes Cheque Mailer Supervisor Machine
Cheque M M
Mailer CM M
Machine M M
Method Matrix
Pointcut Definitions Compiler Errors
35Future Work
- Use a dynamic AOSD technology such as AspectWerkz
or JBoss-AOPClean up some of the
pointcutsIntegrate with the J2EE server
software - Automate generation of scenarios from Rational
Rose (or other UML/MSC tool) - Refine the SBAC frameworkPerformanceMake the
framework more opaque - Implementation in a COTS environment where
components arent fully trusted
36Summary
- AOSD modularizes cross-cutting concerns
- Created Reference monitor using AspectJ that was
completely modular - Dynamic Implementation of SBAC using AOSD and
AspectJ
37Questions
38AOSD Technologies
- 5 Implementations
- Multidimensional Separation of Concerns
- Traversal Specifications
- Composition Filters
- Class Introduction
- Join Point Interception
AspectJ
39Join 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
40Join Points
Join Point
public void setx(int a) ..
Bar.setx(5)
Foo
Bar
41Pointcuts
- 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/libra
ry that return a Foobar Object
42Advice
- This is the base-language code that has been
attached to a particular pointcut or set of
pointcuts - 3 types
- Before
- After
- Around
43Class Introduction in AspectJ
- Given
- public class Cheque
- private int value
- and in another module
- public aspect ModifiedCheque
- public int Cheque.getValue()
- return value
-
44Aspects
- 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.
45Sample 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
46Class Introduction
- Allows the addition of methods, attributes and
interfaces to an existing class without
subclassing or editing existing code - Violates traditional encapsulation methods
47Compiler 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"
48AOSD (continued)
- Use of Interface Introduction
- Used pointcuts and method introduction to obtain
context of some user interface method calls.
//serverStatus scenario public void
HQManager.SserverStatus() public abstract void
HQLocal.SserverStatus() pointcut
SserverStatus(HQServerStatusForm
form) execution(public HashMap
HQServerStatusForm.getStatus())
this(form) before(HQServerStatusForm form)
SserverStatus(form) form.hqLocal.SserverStatus()
49Join 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.
50Security Policy Implementation
- Resultant policy is a set of Message Sequence
Charts - I used both high-level and low-level MSCs
51Method MatrixFirst Example Cheque Scenario
M Method pointcut C Constructor
pointcut Bold text indicates actor class
Caller\Receiver DrafterClass SupervisorClass Cheque Cheque Mailing Machine ChequeRegistry ChequeSignature Envelope StampRepository
DrafterClass M
SupervisorClass M M M CM
Cheque
ChequeMailingMachine M CM M
ChequeRegistry M M MC M
ChequeSignature
Envelope
StampRepository
52Method Matrix (continued)
DrafterClass Permitted SupervisorClass Permitted ChequeMailingMachine Permitted Permitted
createCheque(ChequeData) any getNextChequeData() any processCheques() any any
nextEditCheque() any attachSignature(int) any addCheque(int) SupervisorClass SupervisorClass SupervisorClass
removeNextEdit() SupervisorClass rejectClaim() any
editCheque(int) SupervisorClass editChequeToEdit(int) any
editUpdate(ChequeData) any
addCheque(int) ChequeRegistry
getTasks() getTasks() getTasks()
getNextInvoice() getChequeMailer() getStamper()
addInvoice(OcrDocument) SendChequeToPostOffce()
getInvoiceList() getRegistry()
getSupervisor()
isChequesToEdit()
setChequesToEdit(boolean)
53public privileged aspect A_ChequeScenarioMonitor
Scenario upperScenario PermissionTable
permissionTable DrafterClass drafter SupervisorC
lass supervisor ChequeMailingMachine
mailer ChequeRegistry registry PrimitiveScenario
scenario / This ReferenceMonitor has been
designed for the ChequeContainerClass
environment. If this is to be used again in
another system then the class that provides the
seeds for the scenarios would have to be
changed. _at_precondition The container class is
of type ChequeContainerClass / public
A_ChequeScenarioMonitor() / This pointcut
is used to determine the top-level scenario
transition / pointcut startScenario()
execution(public void ChequeBeanLogic.ejbCreate())
//these are the combined (Inner and Agent)class
pointcuts pointcut callChequeRegistry() call(
ChequeRegistry.(..)) (within(DrafterClass)wi
thin(SupervisorClass)within(ChequeMailingMachine
)) pointcut callSupervisorClass() call(
SupervisorClass.(..)) within(ChequeRegistry)
pointcut callDrafterClass() call(
DrafterClass.(..)) (within(ChequeRegistry)wi
thin(SupervisorClass)) pointcut
callChequeMailingMachine() call(
ChequeMailingMachine.(..)) (within(SupervisorC
lass)) pointcut callChequeSignature() call(
ChequeSignature.(..)) within(SupervisorClass)
pointcut callEnvelope() call(
Envelope.(..))within(ChequeMailingMachine) poi
ntcut callStampRepository() call(
StampRepository.(..))within(ChequeMailingMachin
e) pointcut scenarioCallPC() // group all the
call Pointcuts together callDrafterClass()
callSupervisorClass() callChequeRegistry()
callChequeMailingMachine() callChequeSignature()
callEnvelope() callStampRepository() //
Constructor Pointcuts pointcut constructorCalls()
call(public ChequeSignature.new(business.Supervis
orClass)) within(SupervisorClass) call(public
Envelope.new()) within(ChequeMailingMachine)
//Agent class pointcuts pointcut
agentDrafterClass() execution( public int
DrafterClass.createCheque(ChequeData))
execution( public ChequeData
DrafterClass.nextEditCheque()) pointcut
agentSupervisorClass() execution(public
ChequeData SupervisorClass.getNextChequeData())
execution(public void SupervisorClass.attachSignat
ure(int)) execution(public void
SupervisorClass.rejectClaim()) execution(public
void editChequeToEdit(int)) execution(public
void editUpdate(ChequeData)) pointcut
agentChequeMailingMachine() execution(public
StringBuffer ChequeMailingMachine.processCheques()
) execution(private StringBuffer
ChequeMailingMachine.printCheque(ChequeData,
Envelope)) execution( private void
ChequeMailingMachine.getStamp(ChequeData,
Envelope)) execution( private void
ChequeMailingMachine.getAddress(ChequeData,
Envelope))
pointcut scenarioAgentPC() agentDrafterClass()
agentSupervisorClass()agentChequeMailingMachi
ne()constructorCalls() / This advice is
a supplemental to the constructor to this aspect.
It identifies the ChequeBeanLogic instance
and gets the 3 classes that are needed to
seed the first scenario The Drafter
The Supervisor The Cheque Mailing Machine
/ after() startScenario() JoinPoint jpoint
thisJoinPoint drafter ((ChequeBeanLogic)jpoin
t.getTarget()).getDrafter() supervisor
((ChequeBeanLogic)jpoint.getTarget()).getSuperviso
r() mailer ((ChequeBeanLogic)jpoint.getTarget()
).getMailer() registry ((ChequeBeanLogic)jpoint
.getTarget()).getChequeRegistry() //create a
new permissionTable and seed it up with the first
scenario. upperScenario new S_NewTask(drafter,
supervisor, registry, null) permissionTable new
PermissionTable(upperScenario) //end around
startScenario and secondary constructor/scenario
seeder before() scenarioCallPC()
scenarioAgentPC() scenario permissionTable.perm
it(thisJoinPoint) if (scenario null)
StringBuffer errorMsg new StringBuffer("permis
siondenied") errorMsg.append(thisJoinPoint.toStri
ng()) System.out.println("error "
errorMsg) throw new RuntimeException(errorMsg.toS
tring()) //end before scenario calls() //set
the recently created object to a reference in the
scenario that was used. after()
returning(Object object) constructorCalls()
if (scenario ! null) scenario.setNewObject(o
bject) //Compiler Errors pointcut
constructorError() call(public
business..new(..)) !constructorCalls()
//discard the constructors that are part of
scenarios, they're already covered //these are
the exceptions to the rule !within(ejb.) //ejb
needs to create seeder classes !(call( public
Cheque.new(..)) within(ChequeRegistry)) //
only ChequeRegistry can make new Cheque
objects !(call(public ChequeData.new(..)))
//anybody can create a ChequeData
object !(call(public ChequeSignature.new(..))
within(Cheque)) // Cheque needs to create a
signature declare error constructorError() "S
ecurity Violation, constructor not
permitted" //end aspect A_ChequeScenarioMonitor
Code Generated from the Method Matrix
54Reference Monitor Aspect CodeSecond Example
Military Certificate Authority Server
public privileged aspect AHQManagerMonitor
pointcut initializationCalls() execution(pub
lic void HQForm.new()) pointcut
otherCalls() execution(public SessionContext
HQManager.getCtx())//this is needed by the
scenarios execution(public HQManager.requestCe
rtificate(..))//container manages the security
to this method as it is used by
SAAJ execution(public HQManager.permit(..))//
eliminate recursion... pointcut
managerintercept(HQManager manager) execution(p
ublic HQManager.(..)) this(manager)
!cflow(initializationCalls()) !otherCalls()
before(HQManager manager)
managerintercept(manager) Scenario scenario
manager.permit(thisJoinPoint)//check for
validity if (scenario null) //if null, then
permission denied throw exception StringBuffe
r errorMsg new StringBuffer("permissiondenied")
errorMsg.append(thisJoinPoint.toString())
System.out.println("error " errorMsg) throw
new RuntimeException(errorMsg.toString())
55J2EE
- Not the easiest technology/specification to work
with. - Multiple stubs and interfaces made it difficult
to implement SBAC and weave the reference monitor
code. - I was able to use some of the native security
features which saved some time and effort - Takes a bit of time to set up a J2EE application
server and database
56(No Transcript)
57Orthogonal Design Requirements
58Superimposition of Multiple Abstraction Models
59Multidimensional Decomposition
60Tyranny of Decomposition
- the tyranny of the dominant decomposition is
the single most significant cause of the failure,
to date, to achieve many of the expected benefits
of separation of concerns. - Ossher and Tarr
- -HyperJ User Manual, 2001
61Principle of Obliviousness
- The Principle of Obliviousness allows programmers
to make quantified programmatic assertions over
programs written by programmer oblivious to such
assertions. - Filman Friedman
- AOP is Quantification and Obliviousness
62Cross-cutting Concerns
- A concern that cuts across the modularity of a
software system. - Symptoms include
- Scattering Code related to a single concern is
spread across several modules - Tangling Code unrelated to the primary concern
of a module is mixed in. - Interface Pollution The interface requirements
of several clients are combined into a single
interface for a module.
63Some Benefits of AOSD
- Better separation of concerns
- Increased Comprehensibility
- Source code reduction
- Decomposition of modules previously considered
monolithic - More adaptable and easier to reuse
- Simpler System evolution
- The increased modularity of AOSD systems mean
that fewer modules are affected when another
module is altered. - Programmer specialization through application
transparency - Some concerns, such as security, can be better
implemented
Source Elrad and Coady
64SBAC uses Objects
65Permission Table
- Hashtable that contains a collection of
permissions - Each permission hash value based on
- Caller Object instance hash
- Receiver object instance hash
- Method name
- Parameter types
- Match permission hash to equivalent join point
hash