JAVA SECURITY

Security is, perhaps, the most important and necessary assurance requirement to consider when deploying a system. Because computing systems assume more and more widespread business and mission-critical functionality each day, the cost associated with a breach of security is also increasing. Furthermore, because security problems are human-induced problems, the range of possible problems is as limitless as the human mind. Security, thus, becomes a crucial problem to solve.

The Basic Security Model

Figure Security depicts the basic security model that results from security problems and assurance-provisioning mechanisms. At the top of the diagram, a resource provider is shown offering some security-critical data or application resources. Such resources are security-critical because a malicious being, such as the hacker depicted at the bottom of the diagram, can corrupt, reference (that is, access), replace, delay access to, or deny access to such resources.

Figure Security : The basic security model.

A security service provider depicted on the left side of the diagram attempts to protect such resources from attack by providing protection services such as integrity, confidentiality, authorization and access, identity, authenticity, availability, non repudiation, and auditing-protection services. Such services attempt to thwart the hacker's best efforts.
The right side of the diagram shows the beneficiary of the security services. These services include the following:

§ Integrity Verification: The beneficiary has some verification that the data or application is accurate.
§ Confidentiality Preservation: The beneficiary has some assurance that confidentiality of the data or application has been preserved.
§ Authorization/Access Permission: Properly authorized permission to access security-critical data, application, or other resource has been provided.
§ Identity Verification: The beneficiary has some verification that the identity associated with the data or application source is who they say they are.
§ Authenticity Permission: Properly authenticated permission to access some data, application, or other resource has been provided.
§ Availability of Service: The beneficiary has access to the data, application, or other resource when it expects to have access.
§ Nonrepudiation Evidence: The beneficiary has some evidence regarding from whom the data or application comes or has some evidence that an intended receiver actually received data sent to it.
§ Auditing Evidence: The beneficiary has some evidence of security-critical operations that take place in the system.

Java and Security

Java is a language for the Web and is used to design Web pages. The first Web pages created using Java contained just images and text. However, this was an advancement from the traditional way of presenting information. You had access to a large repository of data that could be accessed through the hyperlinks on a page. The only drawback was that for executable programs, you had to refer to the server. The Web interface was so designed that you filled up data in a page and the data was transmitted to the server where it was acted on by an executable program. There were animations or puzzles that made a Web page more exciting; however, they could not be successful if they were placed on the server for execution. Moreover, if the concerned program was placed on the server, there was a long time interval between the submission of a customer query and the result of the query being displayed on the Web page. Wouldn't it be much easier and require less overhead if executable programs could be placed on the Web page itself? However, here comes the security factor. If programs are placed on Web pages, there is a risk of viruses being downloaded when you load the specified Web page in the browser or execute the program on your computer. Second, if the program was created using a specific platform that is not supported by your system, the main benefit of the Web being platform-independent whereby you can run programs on any client is lost.

AOP – Aspect Oriented Programming

AOP is a philosophy that is related to style of programming, first introduced by Gregor Kickzales in 1996. Like structured programming and Object-Oriented programming introduced a new approach for designing programs and a set of guidelines to make more readable and reusable code.

Aspect-oriented programming (AOP) better separates concerns than previous methodologies, thereby providing modularization of crosscutting concerns.

A concern is a particular goal, concept, or area of interest. In technology terms, a typical software system comprises several core and system-level concerns. For example, ATM processing system's core concern would process payments, while its system-level concerns would handle logging, transaction integrity, authentication, security, performance, and so on. To understand the spirit of AOP, you must understand the following issues:

Concerns Separation: referring the Law of Demeter, a project's efficiency increases if all the concerns are well modularized and if you only have to speak to your direct friends to make a modification of the program (this is a very old principle and the OOP gives some answers).

Crosscutting Concerns: in a complex system, there are always some concerns that are not easily modularized, especially common-interest concerns that, by essence, are used by several modules (i.e. several modules use/share a well-known service of a module -- such as a logging or a persistence service).

Dependencies inversion: the best way to avoid crosscutting is to NOT use the well-known services that crosscut. This is possible by reversing the dependencies (i.e. the well-known service shall use the other modules instead of the contrary). This dependency inversion is implemented by aspects.

Existing Frameworks
Probably the most mature and fully featured framework available today is AspectJ. While AspectJ sets the standard that most frameworks follow, the architects took the unusual step of adding new keywords to the Java language in their implementation. Though the new syntax isn't too difficult to learn, it does mean that you will have to change your compiler, and potentially reconfigure your editor, in order to use the new syntax. In a large team this may not be feasible, as the whole team could be affected. The modification to the language also increases the learning curve for teams looking to introduce AOP into existing projects.
What we need is a framework that can be easily introduced without severely impacting the existing development and build process. There are several frameworks that fit the bill, such as JBoss AOP, Nanning, and Aspectwerkz (AW). For this article, I've chosen Aspectwerkz because it is probably the easiest framework to learn and integrate into your existing projects.
Aspectwerkz, created by Jonas Boner and Alexandre Vasseur, remains one of the quickest and most fully featured AOP frameworks available. While it may not boast all of the features of AspectJ, it is sufficiently complete to be of great use to most developers in many situations.
One of the most interesting features of Aspectwerkz is its ability to run in two different modes: online and offline. In online mode, AW is hooked into the low-level classloading mechanism part of the JVM, allowing it to intercept all classloading calls and transform the bytecode on the fly. AW provides many options to hook in, and a wrapper script can be used as a replacement for the bin/java command to automatically detect and set a working configuration depending on the Java version and JVM capabilities. This mode holds many benefits to developers, as it can be hooked into any classloader and weave classes at classload time, which means that your class files are not modified manually, but deployed as usual. However, it does require additional configuration of your application server, which may not be possible in some situations.
In offline mode, two phases are required to generate your classes. The first phase is the standard compilation using the javac tool that we all know and love. (In fact, most of us love it so much that we replaced it with an Ant task years ago.) The second phase is where things get interesting, we run the AWcompiler in offline mode and point it to the newly created class files. The compiler will then modify the bytecode of the classes to include your advice at the correct point-cuts, as defined in an XML file. The benefit of using the offline mode is that the classes will run in any JVM from version 1.3 and up. This is the mode that I will use in this article, as it requires no modifications to Tomcat and could be applied to most existing projects with only slight modification to the build process.