Adopting a Security Framework

Most architects and developers adopt a security framework in order to build secure applications because it abstracts the complexity from many underlying security components and is built on proven best practices. The term security framework sometimes refers to a set of tools or mechanisms meant for designing and building secure applications. The J2EE platform security architecture builds on J2SE Security including Java Authentication and Authorization Service, Java Cryptography Architecture, and Java Crypto Services APIs (refer to Chapters 3 through 5 for details), do architects and developers really need a security framework in order to build secure Web applications? This section analyzes the logical components of a vendor-independent security framework that are common to many vendor products for building secure Web applications using J2EE-based applications and Web services.

Why do some architects and developers still want a security framework while there are Java API mechanisms? Different Java security APIs are designed to address specific or related problems; they do not necessarily intend to cover all aspects of application security. In addition, the Java security APIs define a large variety of classes and methods but provide no overall instructions about which subset to use in a particular application. An end-to-end security framework for building J2EE-based applications and Web services should be able to simplify the security code development complexity using an abstraction security layer instead of calling individual security components respectively. This should shorten the development life cycle and ease any debugging effort for numerous security components. It should encompass existing J2EE security components in order to meet the security requirements of authentication, authorization, traceability, data confidentiality, availability, data integrity, and non-repudiation. The security framework should also ensure messaging and transaction security across architecture tiers or layers instead of providing security for a stand-alone application or on a stand-alone host. More importantly, it should provide a structured approach to coding the messaging and transaction security using security patterns and best practices. Thus, a security framework is essential for building secure applications.

There are security framework software products available today that can provide security for J2EE-based applications and Web services. But this does not mean that we can choose one silver bullet to deliver end-to-end security that addresses all risks and vulnerabilities. Nevertheless, they are usually product-specific and may not provide a platform-independent structured methodology to build end-to-end application security. Thus, some architects and developers still prefer to pick a vendor-independent security framework first to address their security requirements rather than choosing a vendor-specific software product. Some enterprises that have a large IT development team may desire home-grown or custom-made security framework components based on open-source products and/or security vendor products. One possible reason is that they want to avoid vendor lock-in by proprietary security extension features, which may lead to compatibility issues with security standards or potential security risks if these security features are later exploited. Additionally, a customized security framework can be more agile in addressing specific security requirements or legacy system integration requirements, particularly when developers need to support both proprietary and open standards security specifications simultaneously during the transition. Most of these security framework software products or home-grown security frameworks share some similarities. Figure 8-10 depicts a generic logical security framework available from an application security infrastructure provider.

Figure 8-10. Logical security framework of an application security provider

Application Security Provider

The Application Security Provider infrastructure consists of single-system application security components that address security functions of organizational security requirements. They do this in terms of security infrastructure services and identity and policy management services. Let's take a look at the key components offered by an application security infrastructure provider.

Security Infrastructure Services

Security Services. This denotes a set of common security services that are reusable by many applications and system infrastructures. They include authentication, authorization, monitoring, auditing, WS-Security, and so forth. Authentication refers to the verification of the user identity and credentials using a mixture of security mechanisms. Authorization refers to the entitlement that allows a service requester to access resources as per the predefined security policies and access rights. Monitoring refers to the capability to observe and manage application-level security events or exceptions, especially suspicious security activities. Auditing refers to the capability to trace and track application events and exceptions for security auditing or troubleshooting. Web Services Security refers to the security functions required for protection of XML Web services messagesfrom message creation, routing, and message acknowledgement to the execution of SOAP-based service requests and responses. Key management denotes how key pairs are generated, maintained, or retrieved for authentication or producing digital signatures. Public Key Infrastructure is an example of key management service. Privacy denotes the management of personal or sensitive data by applying data policies to protect them from unauthorized access.

Protocols. The protocols denote the security protocols that are commonly used for security processing (for example, Online Certificate Status Protocol, or OCSP, for verifying user credentials with a Validation Authority in real-time), or securing the user session in the data transport layer with the server (for example, HTTPS).

Handlers. The handlers refer to the interface that interacts with each Java object or component for the access of the common security services or to the service provisioning layer (that ensures appropriate resources are allocated to each service request). Thus, developers can access any of the security services by making use of components such as JSP/Servlets, EJB, RMI/IIOP, SAAJ, or JAX-RPC calls.

Service Provisioning. This denotes the capability to provision and manage the resources to each authenticated service requester that has the proper access rights and security policies to access the resources. It implies that the resources are available and secure to each service requester and are properly provisioned according to the predefined security policies within a single system or the enterprise. This can be incremental (per usage), segmented (per usage), or transactional (per message or call), depending on the security infrastructure set-up or application system configuration.

Identity and Policy Management Services

Identity Management. This refers to the ability to define and manage user credentials and attributes, and to administer user identity by asserting the user credentials or attributes to the system resources. Single sign-on is a key objective of identity management. Typically, identity management includes a variety of authentication and authorization support mechanisms, including LDAP-based directory server and various security tokens such as user ID and password, Java card, and so forth.

Policy Management. This refers to the ability to define and manage user roles and security policies, and to execute security policies within a single system or across different security domains. It also allows administrators to map the users, groups, roles, and security policies to the protected system resources. In some implementations, they offer a policy management rule engine that facilitates security policy administration and execution.

Although there are vendor implementation differences among application security providers, architects and developers should choose a security framework that adheres to the J2EE security standards and open standards. It should also be able to easily migrate to the new security standards when available (for example, migrating legacy XML-based Security implementation to OASIS's WS-Security). Some common questions to consider are:

• Do they use proprietary implementation or security-standardsbased implementations?

• Are they imposing a vendor-specific architecture, which may restrict the flexibility to apply security patterns and best practices?

• Does the security framework include a structured design methodology to secure applications right from the development phase?

More importantly, the chosen security framework should be flexible and follow security design best practices and patterns, and the vendor product architecture should not dictate how architects and developers tailor the security design. Instead, the framework should make use of the architecturally significant security use cases. A good security framework should enable building vendor-independent security solutions that adopt standards-based technologies, structured security methodology, security patterns, and industry best practices.