Title: Scurit des applications adaptables construites base de composants
1Sécurité des applications adaptablesconstruites
à base de composants
Sécurité des applications construites à base de
composants adaptables
- Michel RIVEILL
- (travail réalisé par K. Boudaoud et M. Rits)
- http//rainbow.essi.fr
- Laboratoire I3S
2Plan
- Introduction
- Software Interaction (ISL Noah)
- Problem Analysis
- Access control
- Adaptation control
- Security components and AOP
- Adaptation testing
- Security Architecture
- Conclusion
3Introduction
- Component-based applications
- Reduction of time-to-market
- Higher re-use
-
- Why is adaptability important?
- Changing execution environment
- Ubiquitous computing
- Intensive use of computer networks
- Collaborative work
-
- Existing commercial component platforms are not
adaptable - EJB, .NET, CCM
4Introduction
- Adaptable platforms exist in research community
- Aspect Oriented Programming (AOP)
- Examples
- Lasagne (University of Leuven)
- JAC (LIP6 / LIFL)
- Noah (Rainbow, I3S)
- cf. RNTL ARCAD
- Security for adaptable components
- New research domain
- cf. ACI Sécurité
5Overview
- Introduction
- Software Interaction (ISL Noah)
- Problem Analysis
- Access control
- Adaptation control
- Security components and AOP
- Adaptation testing
- Security Architecture
- Conclusion
6Interaction Service
- Interaction schemes
- Programming language independent
- ISL (Interaction Specification Language)
- Declarative programming with rules
- Notifying message -gt action
- Can be created and deleted during execution
- Interactions instances of schemes
- Only control interfaces of the objects/components
- Can be imposed and removed during execution
7noah server
a ISL file interaction persistance(Agenda
agenda, Database database)
agenda.addMeeting (String title) -gt
agenda._call owner
agenda.getOwner() if
(database.store (owner, agenda) error)
then exception "database error"
endif
Interaction Service
Patterns
Interactions
addMeeting getName
Agenda1
Database2
Security1
8noah server
a program ISL.RegisterPattern ("Persistance
", aFile)
Interaction Service
Patterns Persistance
registerPattern
Interactions
addMeeting getName
Agenda1
Database2
Security1
9noah server
a program ISL.RegisterPattern ("Persistance",
aFile) ISL.Instantiate (Persistance", a
genda1, database2)
Interaction Service
Patterns Persistance
Interactions
instantiate
persistance(agenda1,database2)
Persistance1
addMeeting getName
Agenda1
Database2
Security1
10noah server
a program ISL.RegisterPattern ("Persistance",
aFile) ISL.Instantiate ("Persistance", a
genda1, database2)
Interaction Service
Patterns Persistance
Interactions
Persistance1
addMeeting getName
addRule
Agenda1
Database2
Security1
11noah server
interaction security (Agenda agenda, Security
security) agenda.addMeeting(String title)
-gt if (security.Check(_call))
then agenda._call else exception
unauthorized user" endif
Interaction Service
Patterns Persistance Security
registerPattern
Interactions
instantiate
security(agenda1,security1)
Persistance1 Security1
addMeeting getName
addRule
Agenda1
Database2
Security1
12noah server
- interaction persistancesecurity (Agenda agenda,
- Database database, Security security)
- agenda.addMeeting(java.lang.String title)
- -gt if (security.check(_call))
- then
- agenda._call
- owner agenda.getOwner()
- if (database.store (owner, agenda)
- error)
- then
- exception "database error"
- endif
- else
- exception "unauthorized user"
- endif
- agenda.getName -gt
Interaction Service
Patterns Persistance Security
registerPattern
Interactions
instantiate
security(agenda1,security1)
Persistance1 Security1
addMeeting getName
addRule
Agenda1
Database2
Security1
13noah server
a program ISL.RegisterPattern ("Persistance
", aFile) ISL.Instantiate ("Persistanc
e", agenda1, database2)
agenda1.addMeeting ("meeting description")
Interaction Service
Patterns Persistance Security
Interactions
Persistance1 Security1
if (security1.check("reified agenda1.AddMeeting
call)) then agenda1.addMeeting ("meeting
description" owner
agenda1.getOwner() if database2.store (owner,
agenda1) error then exception
"database error" endif else
exception "unauthorized user" endif
addMeeting getName
Agenda1
Database2
Database3
addMeeting getName
Agenda7
Security1
addMeeting getName
Agenda3
14Interaction Service
- ISL Syntax
- Sequential operator ()
- Parallel operator (//)
- Method invocation operator (.)
- Assignation operator ()
- Wait operator (_W, W is a label)
- Conditional operator (if then else)
- Error handling operator (try catch)
- Exception operator (exception)
- Delegation operator
- Implementation
- http//noah.essi.fr
- Java object, JavaRMI, EJB (Jonas), .Net (official
rotor), Fractal (Julia) - Jade replicated component for high avaibility
or disconnection - Les contraintes
- Pas deffet de bord dans un opérateur
conditionnel - Pas dordre dans un opérateur parallele
- La délégation ne se compose pas
15Overview
- Introduction
- Software Interaction (ISL Noah)
- Problem Analysis
- Access Control
- Adaptation control
- Security components and AOP
- Adaptation testing
- Security Architecture
- Conclusion
16Access Control
Application Adapter
Component Provider
Application Assembler
Application Deployer
Associate roles with users
Specify roles
Deployment time
Programmatic security
addMeeting getName
Agenda1
Database2
addMeeting getName
Agenda7
Security1
17Access control
- Actors
- Component provider
- Provider of the components code
- Component deployer
- Person who instantiates the component
- Adaptation provider
- Writes the rules for the adaptation
- Adaptation deployer
- Instantiates adaptation on specific objects
- Principal
- Person who executes the application
18Adaptation Control
- Different people (adaptation deployers) can adapt
a component - Problem who may adapt what ?
- Example
interaction example (Agenda agenda, Agenda team,
Database database) agenda.addMeeting(String
title) ? delegate team.addMeeting(title)
owner agenda.getOwner() if
database.store(owner, agenda)
"error" then exception "database
error endif
addMeeting getOwner
team
store
addMeeting getOwner
agenda
Database2
19Adaptation Control
- Which methods do we allow to be adapted, by whom
- agenda.addMeeting -gt
- Not everyone is allowed to change this method
- Method can be extremely important dont
change it - Which other components can be used in the
adaptation - team, database, agenda
- Which operators of the adaptation language (ISL)
do we allow - delegate replaces original method
- exception what happens if not handled
appropriately
- interaction example (Agenda agenda, Agenda team,
Database database) -
- agenda.addMeeting (String title) ?
- delegate team.addMeeting (title)
- owner agenda.getOwner()
- if database.store
- (owner, agenda) "error"
- then
- exception "database error"
- endif
20Adaptation Control
- New kind of access control
- Classic approach person who executes application
(principal) - Now access control for person who wants to adapt
application - Remark adaptation accepted users dont
have necessarily all permissions - Problem analysis
- Who will give permissions
- Provider assembler deployer
- Identities associated with permissions
- Adaptation provider deployer
21Adaptation Control
- What kind of permissions
- Security people only positive (adaptability )
- Adaptability people prefer negative
(adaptability ) - Compromise positive negative
- Highly adaptable components, with minor security
problems - Security sensitive components
- Where will we guard the permissions
- In the object
- Has to be foreseen in advance
- Outside the object, in metadata
- Can be handled transparently
22Security component and AOP
- Security through AOP De Win et al., Viega00
- Access control, authentication, encryption, etc.
- Benefits
- Adaptable security mechanisms
- Better focused efforts of the few security
experts - When adapting an application (with ISL)
- Security primitives are sometimes needed
- Authentication, encryption, etc.
- Adaptations can be made individually
- The people who make these adaptations belong to
the company, organization - Prevent them from introducing security flaws
- Second level of AOP
- Separate security aspects from adaptation code
- But without knowledge of adaptation code
23Security component and AOP
- Use interactions to add security aspects
- Security component with methods for
authentication, encryption, etc. - Security policy when to use these security
primitives - Example
- When sensitive data is sent to another server,
use SSL - When data is stored on a shared server, use
encryption -
- SecurityManager component will automatically add
security primitives with interactions
24Example
interaction notification(Object obj, Display
display) obj. -gt obj._call //
display.notify(_call)
display
obj
security
?
- interaction security (Display display, Security
security) - display.notify -gt try
-
security.authenticate(display) - cipher
security.encrypt(_call) -
display.notify(cipher) -
- catch
SecurityException - exception "Secure
session failed" -
-
Security Manager
Security policy If component on other server,
do -authentication -encryption
25Adaptation Testing
- Before software is used in practice
- Test if it works properly Howard02, Voas98
- Problems
- Can we trust that the person who adapts the
application does this correctly - Tests take time while testing, application can
be adapted - Solution
- Test if adaptation code follows certain rules
- Separation of concerns
- People analyze application and formulate
constraints - People make adaptations, that are controlled
- Problem how to specify rules
- We can not foresee all possible adaptations
- Adaptation code not known
26Adaptation Testing
- However
- It is possible to foresee some extensions
- More likely need for extensions when application
is executing - Adaptations can be added and removed more than
once - If an adaptation causes problems register
constraint - Control mechanism
- Before adaptation, no overhead to the execution
of the application - Gives feedback why adaptation was not accepted
27Adaptation Testing
- Example1
- Add meeting in different agendas
- Operation has to be atomic
- Constraint invocation of the same methods, with
the same arguments on different instances
of the same component atomic - Example2
- E-commerce application
- Integrate (new) payment component
- First check if enough money
- Atomicity
- Notify Earnings department
- Notify Bank in case of error
- Person who makes adaptation
- Possibly does not know all the constraints
- Possibly has implemented them incorrectly
28Example
interaction ecommerce(Service service, Display
display, Payment payment, Earnings earnings, Bank
bank) service.buy() -gt try
if payment.enoughMoney(_call)
then service._call //
payment.debit(_call) //
earnings.notify(_call) else
display.notEnoughMoney()
endif catch
DebitException
service.cancel(_call)
earnings.cancel(_call)
bank.notify(_call)
Service
Payment
Bank
Earnings
Portal
29Adaptation Testing
- Constraints
- Business logic
- Good coding in logical sense
- Classic security aspects
- Test them or just add them with interactions
- Adaptation control constraints
- Complement each other
Security, safety ?
30Overview
- Introduction
- Software Interaction (ISL Noah)
- Problem Analysis
- Access control
- Adaptation control
- Security components and AOP
- Adaptation testing
- Security Architecture
- Conclusion
31Security Architecture
- Establish identities
- Adaptation provider interaction schemes will
have to be signed - Adaptation deployer use authentication mechanism
in interaction service - How to introduce SecurityManager component
- make addRule method adaptable
- Rule will be checked before it will be imposed on
the object - Guard this information
- When permissions are retracted (or constraints
added), remove interaction rules that become
unpermitted - Remark security mechanism is adaptable
32Interaction Service
registerPattern
Patterns
interaction
instantiate (authentication)
Interactions
Object1.addRule -gt if SecMan.check()
then object1.addRule()
SecMan.inform() else
throw exception
addRule
Security primitives
Security Manager1
Method11
Authentication Encryption
Security primitives
Security Manager2
Method12
Authentication Encryption
Object1
Constraint11 Constraint12 Constraint13
Method41
Constraint21 Constraint22 Constraint23
ACL1
ACL4
Method42
Object2
Object3
Object4
ACL2
Server2
Server1
ACL3
33Overview
- Introduction
- Software Interaction (ISL Noah)
- Problem Analysis
- Access control
- Adaptation control
- Classic security aspects
- Adaptation testing
- Security Architecture
- Conclusion
34Conclusion
- Security for adaptable components
- Control mechanism
- Access control
- Adaptation control
- Separating security aspects from adaptation code
- Adaptation testing (constraints)
- Secure adaptation
- model checking
- type coherency
- No implementation
- its just for discussion, not for fun
35Bibliography
- De Win et al.
- B. De Win, F. Piessens, W. Joosen, and T.
Verhanneman, On the importance of the
separation-of-concerns principle in secure
software engineering. WAEPSSD, Boston, USA,
November 6-8, 2002. - B. De Win, B. Vanhaute, and B. De Decker,
Security Through Aspect-Oriented Programming.
Advances in Network and Distributed Systems
Security (De Decker, B. and Piessens, F. and
Smits, J. and Van Herreweghen, E., eds.), pp.
125-138, 2001. - Viega00
- J. Viega and D. Evans, Separation of concerns for
security. ICSE 2000 Workshop on Multi-Dimensional
Separation of Concerns in Software Engineering,
pages 126--129, Limerick, Ireland, June 2000. - Howard02
- Michael Howard and David LeBlanc, Writing Secure
Code. Microsoft Press, Redmond, 2002. - Voas98
- J. Voas, Defensive Approach to Testing Systems
that Contain COTS and Third-Party Functionality.
In the Proceedings AQUIS '98, Venice, April 1998.
36Sécurité
- Voir sur le site de Rennes (ACI Sécurité)
- Contrat dadaptation
- Pbs sur opérateurs de composition
- localement commutation / associativité
- pb sur lordonnancement-incompatibilité des
services - je suis sur liste rouge / pas présentation du
numéro - je suis sur liste rouge / je ne suis pas inscrit
dans lannuaire