This chapter is from the book
This chapter is from the book
This chapter is from the book
27.5 Related Work
We first consider alternative ways to add security to an application. Broadly speaking, one can distinguish between the use of component libraries for security and other work that focuses on the security binding.
Over the past few years, several security libraries have been developed to enable the implementation of application-specific security requirements. For example, Sun has released JCA/JCE with basic security primitives, JAAS [20] for authentication and authorization, and JSSE for secured network communication. Other examples include Pluggable Authentication Modules (PAM) [26] and GSS API [21]. We consider them as component libraries: They successfully capture the domain logic into separate modules, enabling flexible component selection and interchange. Unfortunately, the use of component libraries does not improve the control over the inherent crosscutting nature of security.
Ongoing research (e.g., Naccio [13], Ariel [24], and PolicyMaker [3]) addresses a declarative description of security properties for application software. Such security-specific language would be especially valuable to define the binding between application and security mechanisms. In this work, the core challenge is to create the right security abstractions once and for all. We have chosen to focus on a general-purpose aspect-oriented language, and we believe that security abstractions will remain an evolving challenge for the foreseeable future.
Next, we consider related work from a different angle by discussing alternative software engineering techniques to deal with crosscutting concerns. From the viewpoint of software architectures, several approaches have addressed increased independence between application logic and security logic.
By using a number of object-oriented design patterns [16], many security architectures try to be independent of an application structure. This can be achieved to some extent. Also, various security-specific patterns have been proposed [27]. The drawback of this approach is that the structure of the solution becomes more complex and harder to understand. This additional complexity is hard to accept in light of security validation requirements.
Meta-level architectures [4, 25, 29] enable the separate implementation of application and security functionality [1, 33]. They offer a complete reification of the execution of the application: The events of sending a message, starting the execution, or creating objects all get reified into first class entities. As the meta-program has control over these reified entities, it can affect the execution of the core application. In comparison to aspect-oriented programming, this mechanism is in many ways more powerful, but it is also a much heavier burden for the software engineer. Moreover, the development of meta-programs for security is more complex because the programmer is forced to think in terms of meta-entities only indirectly related to the application. Like security patterns, meta-level architectures complicate the security validation process.
Other approaches, such as the CORBA Security Service [2, 23], Microsoft .NET [22], JBoss [30], and others [9, 14, 15], use the basic idea of introducing an interceptor between clients and services, in order to perform access control, for example. They are similar to meta-level architectures in that they intervene in the communication between client and service, but the intervention is less generic (and as such more simplified): the interceptors are mere decorators to the services. In straightforward situations, they can be specified fairly easily, possibly through declarative description. However, when more and more application state needs to be taken into account, writing decorators becomes extremely hard.
Transformations in AspectJ happen on the level of source code, and similar results were achieved in AOSF [28, 32]. Other tools are available that work on the level of bytecode [5, 18]. This has the advantage that aspects can be added even when no source code is available for the application. The disadvantage is that on the level of bytecode, a lot of the application logic is already lost. Reconstructing this logic is hard, and producing correct descriptions of how a series of bytecodes has to be changed to implement authentication is even harder. Needless to say, validating and debugging the result will be challenging. We believe that with the current state-of-the-art, an approach that manipulates source code is important to enable the rapid evolution of various stages in the technology. This will be important in order to experiment with AOP environments of growing maturity, while capturing new requirements as experience grows.