A comparison of two approaches for achieving flexible and adaptive security middleware
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
Citations
63 citations
36 citations
18 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....
[...]
18 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]....
[...]
18 citations
Cites methods from "A comparison of two approaches for ..."
...With the advent of the era of big data, LinkedIn designed and developed Kafka [9]to cope with the higher requirements for throughput of explosive log data....
[...]
References
2,969 citations
375 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....
[...]
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....
[...]
308 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....
[...]
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....
[...]
Related Papers (5)
Frequently Asked Questions (2)
Q2. What are the future works in "A comparison of two approaches for achieving flexible and adaptive security middleware" ?
In future work, the authors want to study other qualities of the composition mechanisms, such as security and performance.