This work allows us to provide insights about future directions for MDS research and in-dustrial practice. A primary challenge is to reach a better level of maturity: this of course requires building tools, but also conducting more systematic industrial experimentation.
The latter is obviously difficult in such a critical software application domain. However, recent progress in MDE in theories and tooling, as well as the continuous interest from industry in modelling, may directly be of benefit to the development of MDS.
We noticed that most of the existing MDS approaches implement separation of security concerns from the business logic (SOC), even if for the approaches we surveyed this principle cannot be considered as following the AOM paradigm. By leveraging AOM, security concerns can be specified as aspect models that can be woven into the pri-mary (business logic) models. The AOM paradigm could thus be used to enhance the modularity of the security-critical systems and the reusability of the security models.
MDS has to deal with the business complexity, but also with the additional complexity of security concerns which are multiple in nature. An intuitive solution to this variety is for the software development methodology to reflect the heterogeneous nature of such systems with the goal of making their design simpler. From our evaluation we can de-duce that it is difficult to develop a general-purpose DSL intended to model all security concerns simultaneously. This is because different security properties may require dif-ferent interactions with the business models that are too complex to be modelled by a human using a single DSL. For easing the modelling task and allowing better verification possibilities, an interesting possibility is that each security concern is modelled using a specifically tailored DSL.
However, spreading security concerns over several models raises several crucial challenges in our opinion: First, it hinders the understanding of the overall system’s security by the experts since they need to deal with several models simultaneously. This drawback can however be balanced by the narrowed focus of those models. Second, it requires powerful composition operators for creating models that amalgamate all security aspects. This is crucial for later phases: whereas separate security models make it possible to analyse
security properties independently, the enforcement of those policies in the business part of the systems and code generation requires merging all security aspects before reaching platform code. Third, it complicates keeping all security models synchronised over com-mon information and poses additional challenges when tracking integrated verification results back to security information that is distributed over several models.
Towards addressing some of the challenges above, in Chapter 6 we propose an MDS approach based on a unified System of Security design Patterns that can support sys-tematically dealing with multiple security concerns simultaneously.
OSGi and Kevoree
C.1 OSGi (Equinox) as the target Adaptive Execution Plat-form
As shown in Figure 5.10, once we obtain the security-enforced architecture model from the previous steps, we have to reflect this security enforcement in the running system.
In case we use Equinox1 as the target execution platform, all components (business logic components and proxy components) are implemented as OSGi bundles (Spring Dynamic Modules) [202]. In OSGi service platforms, there are two ways to declare and bind services via interfaces (ports): declaring/binding exported services in Spring osgi-context.xml files, or in the source code by overriding the method start of BundleActivator class of OSGi bundle. Here we show the code for the sake of simplicity but in practice, the declaration of services and bindings can be configured in XML files which means no need to recompile code to change the bindings. Once the services are made available, they can be called from other services. For example, the code snippet in Listing C.1 shows how the deleteBorrowerAccountService of a proxy component of Role Director is bound to the exported service reference of the deleteBorrowerAccountService of the BorrowerAccountResource proxy component (lines 1-8). The lines 12-20 show that this Role Director can also access to consultPersonnelAccount of PersonnelAccountResource.
S e r v i c e R e f e r e n c e [ ] refIdeleteBorrowerAccount DIRECTOR = bundleContext . g e t S e r v i c e R e f e r e n c e s (
2 lms . proxy . i n t e r f a c e s . I d e l e t e B o r r o w e r A c c o u n t .c l a s s . getName ( ) , ” ( h o s t=BorrowerAccountResource ) ” ) ; 4 lms . proxy . i n t e r f a c e s . I d e l e t e B o r r o w e r A c c o u n t
serverIdeleteBorrowerAccount DIRECTOR = ( lms . proxy . i n t e r f a c e s . I d e l e t e B o r r o w e r A c c o u n t ) bundleContext
1http://www.eclipse.org/equinox/
163
. g e t S e r v i c e ( refIdeleteBorrowerAccount DIRECTOR [ 0 ] ) ; 6
myDIRECTORService
8 . s e t d e l e t e B o r r o w e r A c c o u n t S e r v i c e ( serverIdeleteBorrowerAccount DIRECTOR ) ;
10 . . .
12 S e r v i c e R e f e r e n c e [ ] refIconsultPersonnelAccount DIRECTOR = bundleContext . g e t S e r v i c e R e f e r e n c e s (
lms . proxy . i n t e r f a c e s . I c o n s u l t P e r s o n n e l A c c o u n t .c l a s s 14 . getName ( ) , ” ( h o s t=P e r s o n n e l A c c o u n t R e s o u r c e ) ” ) ;
lms . proxy . i n t e r f a c e s . I c o n s u l t P e r s o n n e l A c c o u n t
serverIconsultPersonnelAccount DIRECTOR = ( lms . proxy . i n t e r f a c e s . I c o n s u l t P e r s o n n e l A c c o u n t ) bundleContext
16 . g e t S e r v i c e ( refIconsultPersonnelAccount DIRECTOR [ 0 ] ) ;
18 myDIRECTORService
. s e t c o n s u l t P e r s o n n e l A c c o u n t S e r v i c e ( serverIconsultPersonnelAccount DIRECTOR ) ;
Listing C.1: Services and Bindings in the Director proxy component
As we mentioned before, all the proxy components are very light-weight components.
Every method of proxy components only contains the redirecting call to another service that (directly/indirectly) calls to the real method in the business logic. The code snip-pet in ListingC.2shows that a call to the deleteBorrowerAccount method (line 1) of a proxy component of Role Director actually is redirected to call the deleteBorrowerAc-count method (line 3) of the BorrowerAcdeleteBorrowerAc-countResource proxy component that already was made available previously (lines 1-8, Listing C.1). Similarly, the consultPerson-nelAccount method (line 7) contains a call to the consultPersonconsultPerson-nelAccount method (line 10) of the PersonnelAccountResource proxy component that already was made available previously (lines 12-20, ListingC.1).
1 p u b l i c v o i d d e l e t e B o r r o w e r A c c o u n t (
lms . bo . u s e r . BorrowerAccount borrowerAccount ) throws BSException { 3 d e l e t e B o r r o w e r A c c o u n t S e r v i c e . d e l e t e B o r r o w e r A c c o u n t ( borrowerAccount ) ;
} 5 . . .
7 p u b l i c lms . bo . u s e r . P e r s o n n e l A c c o u n t c o n s u l t P e r s o n n e l A c c o u n t ( lms . bo . u s e r . User p e r s o n n e l ) throws BSException { 9 r e t u r n c o n s u l t P e r s o n n e l A c c o u n t S e r v i c e
. c o n s u l t P e r s o n n e l A c c o u n t ( p e r s o n n e l ) ; 11 }
Listing C.2: Redirecting the method calls in the Director proxy component
Figure C.1: Bob is delegated by Bill 5 permissions, e.g. consult personnel account
The adaptation process is directed by a generated reconfiguration script that is specific for Equinox adaptive execution platform. The reconfiguration script is executed in order to reflect the change of the policy from the model level to the running system, e.g. a new delegation rule is active. Figure C.1 shows a new delegation rule has been enforced in the running system so that Bob (Secretary) is delegated the permission to consult personnel account by Bill (Director). This means after enforcing this delegation rule, there exists a connection from the port consultPersonnelAccount of the User proxy component Bob, via corresponding Role and Resource proxy components, to the real method consultPersonnelAccount in the business logic.