Scurit des applications adaptables construites base de composants - PowerPoint PPT Presentation

1 / 34
About This Presentation
Title:

Scurit des applications adaptables construites base de composants

Description:

S curit des applications construites base de composants adaptables ... Lasagne (University of Leuven) JAC (LIP6 / LIFL) Noah (Rainbow, I3S) ... cf. RNTL ARCAD ... – PowerPoint PPT presentation

Number of Views:27
Avg rating:3.0/5.0
Slides: 35
Provided by: michelr2
Category:

less

Transcript and Presenter's Notes

Title: Scurit des applications adaptables construites base de composants


1
Sé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

2
Plan
  • Introduction
  • Software Interaction (ISL Noah)
  • Problem Analysis
  • Access control
  • Adaptation control
  • Security components and AOP
  • Adaptation testing
  • Security Architecture
  • Conclusion

3
Introduction
  • 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

4
Introduction
  • 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é

5
Overview
  • Introduction
  • Software Interaction (ISL Noah)
  • Problem Analysis
  • Access control
  • Adaptation control
  • Security components and AOP
  • Adaptation testing
  • Security Architecture
  • Conclusion

6
Interaction 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

7
noah 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
8
noah server
a program ISL.RegisterPattern ("Persistance
", aFile)
Interaction Service
Patterns Persistance
registerPattern
Interactions
addMeeting getName
Agenda1
Database2
Security1
9
noah 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
10
noah 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
11
noah 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
12
noah 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
13
noah 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
14
Interaction 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

15
Overview
  • Introduction
  • Software Interaction (ISL Noah)
  • Problem Analysis
  • Access Control
  • Adaptation control
  • Security components and AOP
  • Adaptation testing
  • Security Architecture
  • Conclusion

16
Access 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
17
Access 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

18
Adaptation 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
19
Adaptation 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

20
Adaptation 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

21
Adaptation 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

22
Security 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

23
Security 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

24
Example
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
25
Adaptation 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

26
Adaptation 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

27
Adaptation 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

28
Example
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
29
Adaptation 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 ?
30
Overview
  • Introduction
  • Software Interaction (ISL Noah)
  • Problem Analysis
  • Access control
  • Adaptation control
  • Security components and AOP
  • Adaptation testing
  • Security Architecture
  • Conclusion

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

32
Interaction 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
33
Overview
  • Introduction
  • Software Interaction (ISL Noah)
  • Problem Analysis
  • Access control
  • Adaptation control
  • Classic security aspects
  • Adaptation testing
  • Security Architecture
  • Conclusion

34
Conclusion
  • 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

35
Bibliography
  • 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.

36
Sé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
Write a Comment
User Comments (0)
About PowerShow.com