Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management

Several security considerations pertain to the Business tier, most of which will be discussed alongside the security patterns that address them. One of them is whether or not your Business tier will be colocated with your Web tier. This can affect which of the patterns you use and the performance overhead related to those patterns. While it is generally a good idea to design for a remote Business tier in order to support scalability, the performance benefit and reduced complexity of a colocated design often outweigh the scalability concerns. If a distributed approach is required, there is an issue with propagating the security context from the Web tier to the Business tier. Propagation of the security context must also be addressed by applications that pass data across to other security-aware components, including J2EE connectors and message-oriented middleware via Java Message Service (JMS).

Auditing is a key security requirement for mission-critical applications as well as a general requirement for financial applications. The J2EE 1.4 specifications, while mentioning auditing, does not specify requirements for auditing [SPEC]. Thus, there is no standard approach to auditing prescribed in the specification; auditing must therefore be addressed by developers.

The Business tier contains the bulk of business processing logic. It will often contain large amounts of mature business functionalities as components or helper classeslegacy code from earlier versions of the application, framework code from internal projects, or even open source libraries. This code is usually reused across classes, and it is therefore a challenge to safeguard them. The J2EE platform facilitates a container-managed security mechanism, but it does not address code accessed in different security contexts and based on the data passed to it, or "instance-based" access control, as it refers to it.