scispace - formally typeset

Proceedings ArticleDOI

A comparison of two approaches for achieving flexible and adaptive security middleware

02 Dec 2008-pp 19-24

TL;DR: A bus-based architecture for integrating security middleware services is proposed and a qualitative comparison of the flexibility of the approach with an alternative AO-middleware-based approach is presented.

AbstractOpen and dynamic business environments require flexible middleware that can be customized, adapted and reconfigured dynamically to face the changing environment and requirements. In this respect, the mechanism for composing middleware services with application code has an important impact on the kinds of adaptations that can be supported. This paper studies this problem in the context of security middleware. A bus-based architecture for integrating security middleware services is proposed and a qualitative comparison of the flexibility of the approach with an alternative AO-middleware-based approach is presented.

Summary (4 min read)

1. INTRODUCTION

  • Security enforcement is one of the many services that are offered by these middleware platforms.
  • Instead, it is desirable to have a highly customizable security architecture that can enforce policies for many different applications.
  • We analyze the differences between the above approach for flexible security and an approach that is based on AO middleware.the authors.the authors.

2.1 Case study: a Personal Content Management System.

  • The server component is a facade towards the system that processes incoming requests from the client.
  • This metadata can be extracted from the documents or it can be user-generated in the form of tags and it is used for quickly finding back documents.
  • Therefore, the system has the following high level security requirements: Users should be authenticated.

2.2 Supporting Adaptation of Security Middleware Services

  • The main reason for performing adaptations to middleware security services is to deal with changes in the environment.
  • The two most important changes are changes in the security requirements of the applications (eg. a new threat is identified) and changes in the application itself (eg. a new component is introduced).
  • Instead, it must be possible to reconfigure the middleware dynamically while the application is running.
  • In the rest of the paper, the authors make the distinction between a security service and a security component.
  • S3 Compose/recompose a deployed security component with one or more application components.

3. FLEXIBLE SECURITY ON THE SECURITY SERVICE BUS

  • The authors approach, which is called the Security Service Bus (SSB), relies on a communication bus for providing flexible composition between application components and security components and mutually between security components.
  • The authors briefly discuss their architecture and they illustrate how it supports the adaptation scenarios from Section 2.2.

3.1 Architecture

  • In the bottom side of the figure, three remote security components are shown that realize the security requirements for the PeCMan system.
  • The Authentication (ACN) component is used to verify user credentials, the PDP is used as an authorization policy engine that evaluates access requests and returns access decisions, and the Secure Logger provides auditing functionality.
  • In order to correctly cover the security requirements, these components need to be placed in a composition with the application components and with each other.
  • The authors use a simple component model for representing the various parts of the security enforcement infrastructure.
  • There are two classes of components: security components and application bindings.

Security Components.

  • The security functionality is offered by security components.
  • Security components have a well-defined security interface that specifies its core security functionality.
  • For the PDP, it contains operations for making authorization decisions given certain contextual information.
  • In a central registry service, the SSB keeps track of all security components that are registered and it can invoke their functionality when it is needed.
  • The security components themselves can use the SSB for obtaining applicationlevel context information from application components.

Application Bindings.

  • Application components are bound to the SSB by means of adapter components that are called application bindings.
  • The application binding has two responsibilities: it processes, transforms and enforces decisions for invocations that are intercepted by the middleware and it provides an attribute function that can be invoked by security components to obtain policy information.
  • When a security-relevant event happens in the application component, the interceptor blocks and requests the SSB for an access decision for the event.
  • The SSB uses a data model for representing policies and policy evaluation requests that is compatible with many state-of-the-art policy technologies.
  • The data model defines subjects, resources and their actions, and it defines which actions can be performed by a subject on a resource.

Security Contracts.

  • Besides having a general interface for performing security logic, components on the SSB can be enriched by security contracts.
  • Each security contract explicitly states the types of events or requests that the particular component will exchange on the SSB.
  • In the provided part, the provided functionality is listed.
  • Contracts are expressed in terms of the data model.

Composing Security Services with Applications.

  • The composition of application components with security components happens at two levels.
  • The application component and its binding are composed with each other by means of interception , and the application bindings are composed with security components by means of the SSB .
  • The SSB keeps track of all interfaces and contracts in the registry service.
  • When messages are forwarded to the SSB, it automatically mediates the messages to one or more components that expect the message, according to their contract and it sends the response(s) back.

Domains.

  • The broadcast domain for messages is constrained by placing each component in a domain hierarchy.
  • There is one domain hierarchy per type of contract.
  • Within each domain, there are membership constraints on the components that can join or leave the domain.
  • These constraints guarantee that the SSB can always validly route requests and responses.
  • Constraints for authorization and attribute contracts require that there is always a single provider of a given attribute type or authorization decision.

3.2 Supporting Adaptation

  • The core flexibility mechanism of their approach is the bus architecture, which allows decisions about which component receives which request to be delayed until runtime.
  • The authors illustrate how their architecture supports flexibility by illustrating how the adaptation scenarios from Section 2.2 can be realized.
  • S3 Composition of a security component with other security components or with application bindings is automatically realized based on a combination of contract specification and domain membership.
  • First, a new component is deployed that implements the same interface than the original component and that holds a contract that is equal or more general than the contract of the original component.
  • In their framework, the contents of the contracts depend on the policies that are deployed within the security components.

4. COMPARISON WITH AO MIDDLEWARE BASED COMPOSITION

  • Many middleware platforms offer AO support not only as a programming model, but also as a middleware customization mechanism.
  • The AO-based customization of these popular platforms is a likely candidate for the integration of custom security enforcement with applications.
  • In this section the authors analyze the integration of security enforcement using AO middleware and they compare the differences with their approach with respect to the adaptation scenarios.
  • First, the AO model must support dynamic weaving to allow runtime deployment/undeployment of aspects.
  • Many popular AOP systems such as JBoss and Spring support these features.

4.1 AO-based Composition

  • There are two levels of components that need to be composed with each other .
  • If the PeCMan service has the operations updateDocument, getDocument and getDocumentMetadata, the application binding can have a Document type with read and write operations.
  • The second kind of composition that can be performed is the composition between the application binding and the security components.
  • Other security components can be bound by including the relevant application joinpoints in the composition for that security component.
  • Nevertheless, the authors believe that in most cases, the approach mentioned above is sufficient.

4.2 Supporting Adaptation

  • The authors revisit the adaptation scenarios for the case of AO composition.
  • S3 (Re-)Composition of a security aspect with other security components or with application components is realized by setting or changing the pointcut of the security aspect for that component.
  • By weaving the security aspects to these proxy components, security policies can be enforced.
  • S6 AO-based composition of security enforcement does not take into account the effectively required information from the policies.
  • If the new policy needs new applicationlevel attributes, the policy evaluating component still needs to invoke the application binding directly.

4.3 Comparison

  • The authors compare how well the adaptation scenarios can be supported in both approaches.
  • The composition of the binding with the security components (S3(SS)) is more flexible and easier to change at runtime using the SSB approach (although this depends on the runtime changes that are possible on the AO middleware), and it makes it also easier to reason about the compositions.
  • The conclusions from this comparison are twofold.
  • First, for the composition between application components and their bindings, AO is the more powerful alternative over middleware-level interception.
  • Simple AO platforms often lack flexibility, but when the platform is powerful enough to support runtime programmatic changes to the composition, the AO-based approach is the more powerful option.

6. CONCLUSION

  • In this paper the authors have studied the impact of two mechanisms for achieving flexible composition of middleware services with the applications in the context of security.
  • Based on a comparison of both approaches in which the authors analyzed their support for a set of common adaptation scenarios, they conclude that both approaches are complementary.
  • The con- ciseness of the AO-based approach makes it more appropriate at the application side of the composition, whereas the large runtime flexibility of the bus-based approach make it more appropriate at the security component side.
  • Furthermore, the authors want to make the comparison quantitative by comparing concrete implementations of both approaches.

Did you find this useful? Give us your feedback

...read more

Content maybe subject to copyright    Report

A Comparison of Two Approaches for Achieving Flexible
and Adaptive Security Middleware
Tom Goovaerts Bart De Win Wouter Joosen
{tom.goovaerts, bart.dewin, wouter.joosen}@cs.kuleuven.be
DistriNet Research Group
Department of Computer Science, Katholieke Universiteit Leuven
Celestijnenenlaan 200A
3001-B Leuven, Belgium
ABSTRACT
Open and dynamic business environments require flexible
middleware that can be customized, adapted and reconfig-
ured dynamically to face the changing environment and re-
quirements. In this respect, the mechanism for composing
middleware services with application code has an important
impact on the kinds of adaptations that can be supported.
This paper studies this problem in the context of security
middleware. A bus-based architecture for integrating secu-
rity middleware services is proposed and a qualitative com-
parison of the flexibility of the approach with an alternative
AO-middleware-based approach is presented.
Categories and Subject Descriptors
C.2.4 [Computer-Communication Networks]: Distributed
Systems—Distributed Applications; D.2.11 [Software En-
gineering]: Software Architectures; K.6.5 [Management
of Computing and Information Systems]: Security and
Protection
General Terms
Security, Design
Keywords
Composition, Middleware, Security Service Bus, Messaging,
Aspect-Oriented Programming
1. INTRODUCTION
It is common practice to implement distributed enterprise
applications on container-based middleware platforms such
as Java EE or .NET. Security enforcement is one of the
many services that are offered by these middleware plat-
forms. However, due to the increasingly dynamic nature
of typical modern enterprise settings, it must be possible
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
MidSec ’08 December 1-5, 2008 Leuven, Belgium
Copyright 2008 ACM 978-1-60558-363-1/08/12 ...$5.00.
to customize and adapt the security mechanisms, even at
runtime. Vendors of middleware platforms strive to make
their systems easy to configure and applicable to many dif-
ferent application domains at the same time. A consequence
thereof is that the default security enforcement mechanisms
of these systems are often too simple to use in practice.
The one size fits all model of middleware security in which
the vendor provides a single black box security service for
all possible environments is not (or no longer) feasible. Ob-
viously, resorting to rebuilding security enforcement from
scratch as part of the application is both insecure and costly
at the same time. Instead, it is desirable to have a highly
customizable security architecture that can enforce policies
for many different applications. In this respect, an impor-
tant challenge is how to compose the enforcement architec-
ture with the applications in a flexible and adaptable way.
During the past decade of middleware research, techniques
such as reflection [7], message interception [10] and compo-
nent based development [4] have been used to make mid-
dleware more customizable and adaptable. More recently,
enterprise middleware platforms such as JBoss and Spring
have incorporated aspect-oriented techniques to achieve the
same goal.
This paper studies the kinds of adaptations that can be
supported by these flexibility mechanisms in the context of
security middleware. The contributions of this paper are
twofold:
1. We propose an architecture that uses a combination of
message interception and a contract-enhanced message
bus as a method for offering flexible security support.
2. We analyze the differences between the above approach
for flexible security and an approach that is based on
AO middleware.
Section 2 motivates the need for flexibility by discussing
a case study and a set of adaptation scenarios. In Section 3,
our architecture is briefly discussed. Section 4 investigates
the advantages and disadvantages of our approach with re-
spect to an AO middleware-based approach. Section 5 dis-
cusses related work and Section 6 concludes the paper.
2. MOTIVATION
In this section, we motivate the need for adaptation and
we identify the kinds of adaptations that are analyzed in
this work.
19

2.1 Case study: a Personal Content Manage-
ment System.
Nowadays, people acquire gigabytes of personal digital
content (documents, pictures, videos, ...) and store it on
many different locations (on desktops, hard disks, online
services, ...). As the amount of content increases, its man-
agement and organization becomes very hard, which makes
it a time consuming task to find specific content. More-
over, users want to be able to easily share their content with
other users. The PeCMan project [6] aims at developing
a platform that offers users a uniform interface for manag-
ing (reading, modifying, searching, storing, ...) and sharing
their personal content that is scattered over various devices.
A deployment view of the PeCMan architecture is shown
in Figure 1. The architecture follows a client-server pattern.
The user interacts with the system via a client component
(either a web client, a full desktop client or a client on a
smartphone), via which he/she can add, remove, tag, mod-
ify or search for documents. The server component is a
facade towards the system that processes incoming requests
from the client. The Metadata Repository component is
responsible for storing the metadata of documents. This
metadata can be extracted from the documents or it can be
user-generated in the form of tags and it is used for quickly
finding back documents. The server-side components are
deployed on an enterprise middleware platform.
PeCMan App Server
Client
PeCMan
Client
PeCMan
Server
Metadata
Service
3rd party server
3rd Party
Service
Client
PeCMan
Client
3rd party server
3rd Party
Service
3rd party server
3rd Party
Service
Middleware
Figure 1: Deployment view of the PeCMan architec-
ture. The dashed arrows represent dependencies.
A core feature of the system is that it is open and exten-
sible by service providers that can enhance the core system
with value-added services such as online storage, web pub-
lishing, face recognition or social network integration. It is
the intention to use existing popular online services such as
flickr, Youtube or Riya that fall outside of the control of the
provider of the PeCMan service.
The PeCMan system is a multi-user system and it allows
users to share their content with each other. Therefore, the
system has the following high level security requirements:
Users should be authenticated.
Because of privacy reasons, access control for docu-
ments is required. The authorization policy can be
influenced by an administrator or by the user itself.
Authorization decisions can depend on attributes of a
user or on metadata of the documents.
Security-sensitive events should be audited.
2.2 Supporting Adaptation of Security Mid-
dleware Services
The main reason for performing adaptations to middle-
ware security services is to deal with changes in the environ-
ment. The two most important changes are changes in the
security requirements of the applications (eg. a new threat
is identified) and changes in the application itself (eg. a new
component is introduced). In a highly dynamic system such
as PeCMan that is frequently extended with third party ser-
vices, both of these classes of changes occur relatively often.
Moreover, it is no longer sufficient to merely support these
adaptations at configuration or deployment time. Instead, it
must be possible to reconfigure the middleware dynamically
while the application is running.
In the rest of the paper, we make the distinction between
a security service and a security component. By security
service, we denote the presence of a certain security feature.
A security service is implemented by a one or more security
components, which are the software components that pro-
vide the service at runtime. The following scenarios are the
adaptations that are discussed in this paper:
S1 Change a local parameter of a security component (eg.
the encryption method for an audit service).
S2 Introduce new security functionality (eg. add a secure
logging component).
S3 Compose/recompose a deployed security component with
one or more application components. Application com-
ponents depend on the security component but the se-
curity component can also depend on the application
component(s) (eg. for context-based access control).
S4 Replace a security component with another one (eg. re-
place authorization decision engine with a different
one).
S5 Compose a security component with a (new) third-party
component that is deployed elsewhere.
S6 Change a security policy. Since the security policy ex-
plicitly depends on application-level concepts, a change
in a security policy can require adaptations to the com-
position of security with the applications.
3. FLEXIBLE SECURITY ON THE SECU-
RITY SERVICE BUS
Our approach, which is called the Security Service Bus
(SSB), relies on a communication bus for providing flexible
composition between application components and security
components and mutually between security components. In
this section, we briefly discuss our architecture and we illus-
trate how it supports the adaptation scenarios from Section
2.2. For a broader discussion of the SSB, we refer to [5].
3.1 Architecture
Figure 2 gives an overview of our architecture. In the bot-
tom side of the figure, three remote security components are
shown that realize the security requirements for the PeC-
Man system. The Authentication (ACN) component is used
to verify user credentials, the PDP is used as an autho-
rization policy engine that evaluates access requests and re-
turns access decisions, and the Secure Logger provides au-
diting functionality. Each of these components is deployed
20

on a separate host. In order to correctly cover the secu-
rity requirements, these components need to be placed in a
composition with the application components and with each
other.
3.1.1 Component Model
We use a simple component model for representing the
various parts of the security enforcement infrastructure. There
are two classes of components: security components and ap-
plication bindings. We discuss each of them in this section.
Security Components.
The security functionality is offered by security compo-
nents. Security components are reusable modules that can
be invoked, managed and composed with applications and
with each other. Security components have a well-defined
security interface that specifies its core security functional-
ity. For instance, for the PDP, it contains operations for
making authorization decisions given certain contextual in-
formation. Furthermore, a security component contains a
management interface that specifies operations that can be
invoked to configure and manage the security components,
such as loading a certain policy or enabling/disabling the
service. In a central registry service, the SSB keeps track of
all security components that are registered and it can invoke
their functionality when it is needed. The security compo-
nents themselves can use the SSB for obtaining application-
level context information from application components.
Application Bindings.
Application components are bound to the SSB by means
of adapter components that are called application bindings.
The application binding has two responsibilities: it pro-
cesses, transforms and enforces decisions for invocations that
are intercepted by the middleware and it provides an at-
tribute function that can be invoked by security compo-
nents to obtain policy information. When a security-relevant
event happens in the application component, the interceptor
blocks and requests the SSB for an access decision for the
event. This is illustrated in Figure 3. Likewise, whenever a
security component needs a particular piece of context infor-
mation, the SSB mediates the request and ensures that the
application binding that offers the information is queried.
The SSB uses a data model for representing policies and
policy evaluation requests that is compatible with many
state-of-the-art policy technologies. Application Bindings
translate concrete application requests into requests in terms
of the abstract data model. The data model defines subjects,
resources and their actions, and it defines which actions can
be performed by a subject on a resource.
3.1.2 Composition
Security Contracts.
Besides having a general interface for performing security
logic, components on the SSB can be enriched by security
contracts. Each security contract explicitly states the types
of events or requests that the particular component will ex-
change on the SSB. In the required part of the contract, the
required functionality of the SSB is listed. In the provided
part, the provided functionality is listed. Contracts are ex-
pressed in terms of the data model. Currently, there are
two types of contracts: authorization contracts between en-
c:Application
Component
Middleware
Interceptor
t.X()
cb:Application
Binding
handle(t.X())
SSB
azn
request(t'.X'())
pdp: Security
Component
azn request(t'.X'())
lookup
receiver
decision
decision
decision
block/proceed
Figure 3: Sequence diagram for the enforcement of
an access decision.
forcement points and PDPs and attribute contracts between
PDPs and attribute functions. An example of a simple se-
curity contract for the Metadata Service Binding is shown
below:
SecurityContract MetadataService {
AttributeContract {
provided {
Document.owner;
Document.sensitivity;
}
}
AuthorizationContract {
required {
Document.read;
Document.write;
}
}
}
This contract states that the Metadata Service provides the
Document.owner and the Document.sensitivity attributes
as sources for policy evaluation and that the service requires
policy decisions for the abstract read and write actions.
Composing Security Services with Applications.
The composition of application components with security
components happens at two levels. The application compo-
nent and its binding are composed with each other by means
of interception (the solid arrows in Figure 2), and the ap-
plication bindings are composed with security components
by means of the SSB (the dashed arrows in Figure 2). The
SSB keeps track of all interfaces and contracts in the registry
service. When messages are forwarded to the SSB, it auto-
matically mediates the messages to one or more components
that expect the message, according to their contract and it
sends the response(s) back.
Domains.
The broadcast domain for messages is constrained by plac-
ing each component in a domain hierarchy. There is one
domain hierarchy per type of contract. Within each do-
main, there are membership constraints on the components
that can join or leave the domain. These constraints guar-
antee that the SSB can always validly route requests and
responses. Constraints for authorization and attribute con-
tracts require that there is always a single provider of a
given attribute type or authorization decision. If there is
no provider within a domain, it is possible to make a com-
21

SSB
Authentication Server Audit Server Policy Server
ACN
Component
PDP
Secure
Logger
PeCMan App Server
Client
PeCMan
Client
PeCMan
Server
Metadata
Service
3rd party server
3rd Party
Service
Client
PeCMan
Client
3rd party server
3rd Party
Service
3rd party server
3rd Party
Service
PeCMan
Server
Binding
Metadata
Service
Binding
3PS
Binding
3PS
Binding
3PS
Binding
c
c
cc
Figure 2: SSB-based Composition of the Application with Security Components.
ponent in the parent or in a child domain responsible for
certain requests.
3.2 Supporting Adaptation
The core flexibility mechanism of our approach is the bus
architecture, which allows decisions about which component
receives which request to be delayed until runtime. In this
section, we illustrate how our architecture supports flexibil-
ity by illustrating how the adaptation scenarios from Section
2.2 can be realized.
S1 Changing local parameters is straightforward by directly
invoking an operation on a security component.
S2 To support a new class of security components, an imple-
mentation of the component has to be deployed on the
SSB. When additional guarantees on the composition
are to be supported for the new class of components,
a new class of security contracts has to be developed.
S3 Composition of a security component with other secu-
rity components or with application bindings is auto-
matically realized based on a combination of contract
specification and domain membership. An item from
the provided part of the contract causes the service
to receive messages from all services that specify that
they require that item, under the domain constraint.
Composition with application components depends on
the application binding. Making changes to this com-
ponent is costly, but still remains significantly more
straightforward than changing the application code it-
self because only public interfaces of the application
components are used.
S4 Replacing an existing security component with a differ-
ent one is performed at runtime in three steps. First, a
new component is deployed that implements the same
interface than the original component and that holds
a contract that is equal or more general than the con-
tract of the original component. Second, the original
component is deactivated, and finally, the new compo-
nent is activated. Due to the fact that the contract
is more general than the original one, the new com-
ponent is able to provide at least the same required
functionality as the old one.
S5 Requests to and from external services are processed and
policed by deploying an application binding that inter-
cepts traffic to and from the remote components.
S6 In our framework, the contents of the contracts depend
on the policies that are deployed within the security
components. Therefore, a policy change causes a change
in the contract. Whenever the change in the contract
is allowed according to the domain rules, our frame-
work guarantees that the new policy will be correctly
evaluated. Our architecture can be integrated with
the policy specification tool to help the policy specifier
reason about whether the policy he/she is specifying
can be evaluated in practice.
4. COMPARISON WITH AO MIDDLEWARE
BASED COMPOSITION
Many middleware platforms offer AO support not only as
a programming model, but also as a middleware customiza-
tion mechanism. The AO-based customization of these pop-
ular platforms is a likely candidate for the integration of
custom security enforcement with applications. In this sec-
tion we analyze the integration of security enforcement using
AO middleware and we compare the differences with our ap-
proach with respect to the adaptation scenarios.
The features of the AO middleware directly influence the
kinds of adaptations that can be supported. More specifi-
cally, the dynamic runtime adaptations to the composition
of the security enforcement components we focus on, require
two important features. First, the AO model must support
dynamic weaving to allow runtime deployment/undeployment
of aspects. Second, it must be possible for software to change
aspect compositions at runtime. Many popular AOP sys-
tems such as JBoss and Spring support these features.
4.1 AO-based Composition
There are two levels of components that need to be com-
posed with each other (see Figure 4). First, the application
22

components need to be mapped to their bindings. Second,
the bindings need to be composed with the security com-
ponents. Both of these compositions can be implemented
using AO middleware.
Security
Service
App
Component
App
Binding
AO
AO
direct
Figure 4: Composing Security Components with
Application Components Using AO Middleware.
The application bindings represent the abstract data model
as interfaces in one of the supported middleware languages.
For instance, if the PeCMan service has the operations up-
dateDocument(document), getDocument(document) and get-
DocumentMetadata(document), the application binding can
have a Document type with read() and write() operations.
AO-based composition can then map the application-level
operations on the abstract operations in the binding.
The second kind of composition that can be performed is
the composition between the application binding and the se-
curity components. On AO middleware, this can be realized
by defining an AO-based composition between these com-
ponents in which an invocation to the appropriate security
operation is inserted before the execution of the security-
sensitive operation on the binding. For instance, before the
invocation of read() and write() operations, an invocation
to the checkPermission operation of the authorization com-
ponent is inserted. The pointcut of the aspectual composi-
tion controls when security functionality is invoked. Other
security components can be bound by including the relevant
application joinpoints in the composition for that security
component.
We have illustrated one possible AO-based composition
approach for integrating security components. However,
in more advanced scenarios, such as when mappings get
more complex or when application bindings need to main-
tain state, it might be better to introduce new adaptation
aspects between the composition. Nevertheless, we believe
that in most cases, the approach mentioned above is suffi-
cient.
4.2 Supporting Adaptation
In this section, we revisit the adaptation scenarios for the
case of AO composition.
S1 Adapting local parameters of security components is per-
formed similarly to our approach by invoking an oper-
ation on the security component.
S2 To support a new class of security components, a new se-
curity component implementation should be provided.
S3 (Re-)Composition of a security aspect with other secu-
rity components or with application components is re-
alized by setting or changing the pointcut of the secu-
rity aspect for that component. The kinds of compo-
sitions that can be performed depend on the joinpoint
model of the AO middleware. Due to the very pow-
erful composition model of AOP, it is hard to control
or restrict which security component can be composed
with which application component.
Table 1: Summary of Flexibility Support for Both
Approaches. Legend: support for adaptations is well
(+), neutral (0), bad () or bad when a new contract
type needs to e defined (NC:-).
S1 S2 S3(AB) S3(SS) S4 S5 S6
SSB +
+
NC:-
- + + + +
AO + + + 0 0 + -
S4 Replacing an existing security component by one that
adheres to the same interface is done by undeploying
the composition for the original component and replac-
ing it with an advice for the new component that has
the same pointcut(s) as the original aspect.
S5 Since external services fall outside of the control of the
policy enforcing party, proxy components for the ex-
ternal services are needed. If these proxies are not
explicitly part of the application, they typically exist
internally at the middleware level as an endpoint for
the communication protocol. By weaving the security
aspects to these proxy components, security policies
can be enforced.
S6 AO-based composition of security enforcement does not
take into account the effectively required information
from the policies. Therefore, it is hard to support pol-
icy changes. If the new policy needs new application-
level attributes, the policy evaluating component still
needs to invoke the application binding directly.
4.3 Comparison
In this section, we compare how well the adaptation sce-
narios can be supported in both approaches. Table 1 sum-
marizes this. The most straightforward adaptions S1 and
S2 are supported well in both approaches. However, when
a new contract type needs to be defined on the SSB, sub-
stantial manual effort is needed, with the gain of having
additional guarantees on compositions with the new class of
security components. Changes to the composition between
the application component with its binding (S3(AB)) are
harder to support using the SSB approach. In the best case,
only the message interceptions need to be reconfigured, but
it is also possible that the binding component itself has to
be changed. The composition of the binding with the se-
curity components (S3(SS)) is more flexible and easier to
change at runtime using the SSB approach (although this
depends on the runtime changes that are possible on the
AO middleware), and it makes it also easier to reason about
the compositions. The replacement of a security compo-
nent (S4) is possible in both approaches, but in typical AO
middleware platforms, it still requires manual intervention.
Intercepting traffic towards external services (S5) is easy us-
ing interception, but the translation to the abstract policy
model limits its flexibility. In the AO approach, this can
only be supported when there is a local proxy for the remote
component. The security contracts ensure that changes in a
security policy (S6) are easier to support using the SSB.
The conclusions from this comparison are twofold. First,
for the composition between application components and
their bindings, AO is the more powerful alternative over
middleware-level interception. Simple AO platforms often
23

Citations
More filters

Patent
23 Nov 2010
Abstract: Method for providing access to private digital content owned by an owner and installed on a content server, wherein a content manager server has a number of clients potentially interested in the private content, the method comprising the following steps performed at a content management server being informed that the owner has installed private content on a content server; obtaining a delegate token from the content server; receiving a query for the private digital content from a client of the number of clients of the content management server; providing said client with a token using the delegate token enabling the client to access the private content.

63 citations


Proceedings ArticleDOI
17 Nov 2009
TL;DR: An adaptive and evolving security (AES), and an adaptive trust management (ATM) approach to such autonomic messaging middleware systems, an approach that learns, anticipates, evolves and adapts to a changing environment at run-time in the face of changing threats.
Abstract: With the increase in society's dependence on IT communication systems, the need for dependable, trustable, robust and secure adaptive systems becomes ever more acute. Modern autonomic message-oriented middleware platforms have stringent requirements for self-healing, adapting, evolving, fault-tolerance, security and active vulnerability assessment, especially when the internal working model of a system and the environmental influences on the system are uncertain during run-time. In this paper we present an adaptive and evolving security (AES), and an adaptive trust management (ATM) approach to such autonomic messaging middleware systems, an approach that learns, anticipates, evolves and adapts to a changing environment at run-time in the face of changing threats. The methodology used in this research is partly analytical and partly experimental. This involves analysis of how the principles of AES and ATM can be applied to the environment resulting in the development of theoretical models which are then tested in practice by prototyping.

34 citations


Proceedings ArticleDOI
15 Nov 2009
TL;DR: This developed system supports a messaging infrastructure which enables adaptive functions and assurance against security vulnerabilities and erroneous input vulnerabilities to improve the reliability, robustness and dependability of business critical infrastructures.
Abstract: Current business critical systems have stringent requirements for the significant and measurable increase in the end-to-end intelligence, security, scalability, self-adaptation and resilience. Existing state of the art messaging systems achieve arbitrary resilience by a brute-force approach. Self-healing is either rudimentary or non-existent. In this study we present a robust, secure, self-adaptive and resilient messaging middleware that provides solutions to overcome limitations in robustness, resilience, evolvability, self-adaptability, scalability, and assurance against security threats and erroneous input during run-time in the face of changing threats. This developed system supports a messaging infrastructure which enables adaptive functions and assurance against security vulnerabilities and erroneous input vulnerabilities to improve the reliability, robustness and dependability of business critical infrastructures. The methodology used in this research is partly analytical and partly experimental. We develop the core novel functionalities theoretically and validate them practically by prototyping.

17 citations


Cites background from "A comparison of two approaches for ..."

  • ...That is, security in an autonomic computing environment [14], adaptive security in complex information systems [26], adaptable security manager for real-time transactions [17], dynamic authentication for high-performance networked applications [25], threat-adaptive security policy [27], self-contained object for secure information distribution systems [13], adaptive trust negotiation and access control [22], a bioinspired self-protecting organic message-oriented middleware [21], a bus-based architecture for integrating security middleware services [31], and virtualized trusted computing platform for adaptive security enforcement of web services interactions [32]....

    [...]


01 Jan 2010
TL;DR: A self-healing and secure adaptive messaging middleware that provides solutions to overcome limitations in robustness, resilience, self-adaptability, scalability, and assurance against security threats and erroneous input during run-time in the face of changing threats.
Abstract: Current business-critical systems have stringent requirements for the significant and measurable increase in the end-to-end intelligence, security, scalability, self-adaptation and resilience. Existing state-of-the-art messaging systems achieve arbitrary resilience by a brute-force approach. Selfhealing is either rudimentary or non-existent. In this study we present a self-healing and secure adaptive messaging middleware that provides solutions to overcome limitations in robustness, resilience, self-adaptability, scalability, and assurance against security threats and erroneous input during run-time in the face of changing threats. This developed system supports a messaging infrastructure which enables adaptive functions and assurance against security vulnerabilities and erroneous input vulnerabilities to improve the reliability, robustness and dependability of business-critical infrastructures. It provides autonomous adjustments of the run-time configuration of the system in order to preserve and maintain optimal and uninterrupted operation, improvement of the strength of security and degree of trust in the system, and improvement of the assessability and verifiability of the trustworthiness of the system. The methodology used in this research is partly analytical and partly experimental. We develop the new core functionalities theoretically and validate them practically by prototyping.

15 citations


Additional excerpts

  • ...Table I describes the key functionalities of MOMs, the limitations of existing MOM Systems, and the GEMOM advances as comparison as shown in the table below....

    [...]


Proceedings ArticleDOI
Sun Ying1
06 May 2011
TL;DR: The paper briefly introduced the structure of security middleware system, and prospected some valuable applications and summarized and illustrated the hot spots in detail, including the implementation methods of parallel securitymiddleware and vulnerability monitoring middleware.
Abstract: Nowadays, with the awareness of information security, the security middleware technology is spread among an expanding number of people. On one hand, the security middleware can provide users with simple, understandable and safe information security technologies. On the other hand, it can exert positive effect on setting up a series of standardized and common interface for manufactures, so that the products from different vendors can be used compatibly. The paper firstly briefly introduced the structure of security middleware system, and on this basis, prospected some valuable applications. In addition, summarized and illustrated the hot spots in detail, including the implementation methods of parallel security middleware and vulnerability monitoring middleware. Finally, according to these significant applications, proposed some meaningful prospects related to research directions.

6 citations


References
More filters

Journal ArticleDOI
TL;DR: It is shown that a combination of rippling and the use of meta-variables as a least-commitment device can provide novelty in induction rule construction techniques that can introduce novel recursive structures.
Abstract: We describe novel computational techniques for constructing induction rules for deductive synthesis proofs. Deductive synthesis holds out the promise of automated construction of correct computer programs from specifications of their desired behaviour. Synthesis of programs with iteration or recursion requires inductive proof, but standard techniques for the construction of appropriate induction rules are restricted to recycling the recursive structure of the specifications. What is needed is induction rule construction techniques that can introduce novel recursive structures. We show that a combination of rippling and the use of meta-variables as a least-commitment device can provide such novelty.

2,967 citations


Journal ArticleDOI
TL;DR: It's flexible and reconfigurable yet simple for programmers to use, notably for building dynamic distributed applications operating on the Net.
Abstract: It's flexible and reconfigurable yet simple for programmers to use, notably for building dynamic distributed applications operating on the Net.

372 citations


"A comparison of two approaches for ..." refers methods in this paper

  • ...During the past decade of middleware research, techniques such as reflection [7], message interception [10] and component based development [4] have been used to make middleware more customizable and adaptable....

    [...]


Proceedings ArticleDOI
17 Mar 2003
TL;DR: CAESAR is proposed, a model for aspect-oriented programming with a higher-level module concept on top of JPI, which enables reuse and componentization of aspects, allows us to use aspects polymorphically, and introduces a novel concept for dynamic aspect deployment.
Abstract: Join point interception (JPI), is considered an important cornerstone of aspect-oriented languages. However, we claim that JPI alone does not suffice for a modular structuring of aspects. We propose CAESAR, a model for aspect-oriented programming with a higher-level module concept on top of JPI, which enables reuse and componentization of aspects, allows us to use aspects polymorphically, and introduces a novel concept for dynamic aspect deployment.

324 citations


"A comparison of two approaches for ..." refers background in this paper

  • ...In Caesar, the dependencies are made explicit via provided and expected interfaces in an Aspect Collaboration Interface (ACI)....

    [...]

  • ...In Caesar [9] and Jasco [12], for instance, the dependencies between aspects can be described based on component technology....

    [...]


Proceedings ArticleDOI
17 Mar 2003
TL;DR: A new "aspect-enabled" component model, which contains build-in traps that enable to interfere with the normal execution of a component, is proposed that is backward-compatible with the Java Beans component model.
Abstract: In this paper we introduce a novel aspect oriented implementation language, called JAsCo. JAsCo is tailored for component based development and the Java Beans component model in particular. The JAsCo language introduces two concepts: aspect beans and connectors. An aspect bean describes behavior that interferes with the execution of a component by using a special kind of inner class, called a hook. The specification of a hook is context independent and therefore reusable. A connector on the other hand, is used for deploying one or more hooks within a specific context. To implement the JAsCo language, we propose a new "aspect-enabled' component model, which contains build-in traps that enable to interfere with the normal execution of a component. The JAsCo component model is backward-compatible with the Java Beans component model. Furthermore, the JAsCo component model allows very flexible aspect application, adaptation and removal at run-time. The necessary tool support for the JAsCo approach has been implemented. In addition, we present a performance assessment of our current implementation.

307 citations


"A comparison of two approaches for ..." refers background in this paper

  • ...In Jasco, this is more implicit, but it can be supported via systematic construction [1]....

    [...]

  • ...Jasco: an aspect-oriented approach tailored for component based software development. pages 21–29, 2003....

    [...]

  • ...In Caesar [9] and Jasco [12], for instance, the dependencies between aspects can be described based on component technology....

    [...]


Proceedings ArticleDOI
16 Jun 2003
TL;DR: This paper focuses on two major architectural parts of JBoss: its middleware component model, based on the JMX model, and its meta-level architecture for generalized EJBs, which requires a novel class loading model, which JBoss implements.
Abstract: JBoss is an extensible, reflective, and dynamically reconfigurable Java application server. It includes a set of components that implement the J2EE specification, but its scope goes well beyond J2EE. JBoss is open-ended middleware, in the sense that users can extend middleware services by dynamically deploying new components into a running server. We believe that no other application server currently offers such a degree of extensibility. This paper focuses on two major architectural parts of JBoss: its middleware component model, based on the JMX model, and its meta-level architecture for generalized EJBs. The former requires a novel class loading model, which JBoss implements. The latter includes a powerful and flexible remote method invocation model, based on dynamic proxies, and relies on systematic usage of interceptors as aspect-oriented programming artifacts.

190 citations


"A comparison of two approaches for ..." refers methods in this paper

  • ...During the past decade of middleware research, techniques such as reflection [7], message interception [10] and component based development [4] have been used to make middleware more customizable and adaptable....

    [...]


Frequently Asked Questions (2)
Q1. What are the contributions mentioned in the paper "A comparison of two approaches for achieving flexible and adaptive security middleware" ?

This paper studies this problem in the context of security middleware. A bus-based architecture for integrating security middleware services is proposed and a qualitative comparison of the flexibility of the approach with an alternative AO-middleware-based approach is presented. 

In future work, the authors want to study other qualities of the composition mechanisms, such as security and performance.