| Good application design is often rooted in appropriate security design strategies and leverages proven best practices using design patterns. Design strategies determine which application security tactics or design patterns should be used for particular application security scenarios and constraints. Security patterns are an abstraction of business problems that address a variety of security requirements and provide a solution to the problem. They can be architectural patterns that depict how a security problem can be resolved architecturally (or conceptually), or they can be defensive design strategies upon which quality security protection code can later be built. This section will note the existing security patterns available in the industry today and then introduce a new set of security patterns that are specific to J2EE-based applications, Web services, identity management, and service provisioning. These new security patterns will be further elaborated in the following chapters of this book. Understanding Existing Security Patterns There are a few known enterprise or information security patterns available on the Web. Most of them address generic information security issues related to the infrastructure of application security. Some of them are adapted from the Gang of Four [GoF] design patterns. They focus on security solutions dealing with the infrastructure or quality of services (for example, how to make the security service highly available), and are used as enterprise security design strategies. They do not delve into the feature and functional characteristics of using a security technology or how such technology can be incorporated to represent an end-to-end security model. These known security patterns are summarized in the sections that follow. Table 8-3 through Table 8-6 outlines them. Table 8-3. Existing Security Patterns Supporting the Web TierPattern Name | Standards and Technologies | Description | Related Patterns |
|---|
Secure Communication | HTTPS; SSL (TLS), IPsec | This pattern describes the use of a secure data transport layer for client-to-server and server-to-server communication. Reference: [YoderBarcalow1997], p. 24; [OpenGroup], p. 27 | Protected System; Login Tunnel; Secure Access Layer | Secure Association | SSL (TLS); Cryptographic standards supported by JSSE, JCE, and JGSS | This pattern shows how to make secure interactions between two entities; for example, protecting the session between the browser and Web server using SSL or TLS, and secure e-mail using encryption and proxies. Secure Communication pattern is more specific to encrypting the communication channel between the client and server. Typically, HTTPS is a means of implementing the pattern. Secure Association pattern is broader, and covers any secure interaction, including the session between the browser and Web server via HTTPS. Reference: [OpenGroup], p. 32. | Secure Communication | Single Access Point | HTTPS; SSL (TLS) | This pattern enforces a single point of entry to the business services and applications that provides a login prompt or login page. It is usually implemented by forms-based authentication and Secure Socket Layer (SSL) with J2EE declarative security. Reference: [Berry], pp. 203-204; [YoderBarcalow1997], p. 4; [WassermannBetty], p. 18 | Protected System | Check Point | JAAS | This pattern centralizes the authentication and authorization process logic to a "checkpoint" entity. It assumes using JAAS to implement the checkpointed system. Reference: [Berry], p. 204; [Monzillo]; [YoderBarcalow1997], p. 7; [OpenGroup], p. 47; [WassermannBetty], p. 27 | Authentication Gateway; Self Registration; Checkpointed System | Session | | Secure applications need to track global information throughout the application life cycle. This pattern identifies session information (for example, HTTP session variables, RPC call information, service requester details in the JMS or the SOAP messages) that needs to be maintained for security tracking. This pattern differs from the Singleton pattern in that the session information needs to be maintained and shared in a multi-threaded, multi-user, or distributed environment. Reference: [YoderBarcalow1997], p. 14; [Amos], p. 3 | Authenticated Session; User's Environment; Namespace; Threaded-based Singleton; Localized Globals | Security Provider | | This pattern describes what a client should operate to perform authentication against the identity service provider for authentication or authorization assertion. It is part of the single sign-on process for enterprise identity management. Reference: [Romanosky2002], p. 11 | Authoritative Source of Data; Enterprise Access Management; Enterprise Identity Management |
Table 8-4. Existing Security Patterns Supporting the Business TierPattern Name | Standards and Technologies | Description | Related Patterns |
|---|
Role | J2EE declarative security features | This pattern shows the disassociation of a specific user from their privileges by using roles. J2EE declarative security allows such role-based access control to be defined and managed in the ejb-jar.xml and Web.xml deployment descriptors. Reference: [Berry], p. 205; [Monzillo]; [YoderBarcalow1997], p. 11 | Class-scoped Authorization | Subject Descriptor | J2EE Security Access Controller | This pattern allows access to the security attributes of a subject or principal via the operations. It corresponds to the javax.security.auth.Subject and java.security.Principal classes in JAAS. This pattern can be used to check rights or credentials. The Full View with Errors and Limited View patterns refer to the access rights of the application functionality, not to the subject or principal. Reference: [OpenGroup], p. 22 | PEP | Security Context | J2EE Security Access Controller | This pattern provides a container for access to security attributes, such as effective user ID and group ID. In the context of J2EE technology, this pattern refers to the class AccessControlContext that provides a check permission API. Reference: [OpenGroup], p. 40 | | Full View with Errors | | This pattern provides a full view to users with errors incurred, including exceptions when necessary. Reference: [YoderBarcalow1997], p. 17 | | Limited View | | This pattern allows users to see what they can access. Reference: [YoderBarcalow1997], p. 19; [Amos], p. 4 | Client Input Filter | Security Event Logging | JMX; Java API for Logging | This pattern is related to the capture and tracking of security-related events for logging and audit trail. Logged information can be used for risk assessment or analysis. A variant of this pattern is the Risk Analysis pattern, which relates the overall security risk to the sum of security threat, the cost of protecting the resources or losing the resources, and the vulnerability. Once the overall security risk is determined, then the priority will be allocated to protect resources appropriately. Reference: [Romanosky2001], p. 8; [Romanosky2002], p. 4; [Amos], p. 4; [Berry], p. 205 | Risk Assessment and Management; Risk Analysis |
Table 8-5. Existing Security Patterns Supporting the Integration TierPattern Name | Standards and Technologies | Description | Related Patterns |
|---|
Authoritative Source of Data | | This pattern verifies the data source for authenticity and data integrity. Reference: [Romanosky2001], p. 5; [Romanosky2002], p. 2; [Berry], p. 206 | | Third-Party Communication | | This pattern helps identify the risks of the third-party relationship and applies relevant security protection measures for the third-party communication. Reference: [Romanosky2001], p. 10; [Romanosky2002], p. 6 | Enterprise Partner Communication |
Table 8-6. Existing Security Patterns for Infrastructure Quality of ServicesPattern Name | Standards and Technologies | Description | Related Patterns |
|---|
Load Balancing PEP | | This pattern shows how to make horizontal scalable authentication components using load balancer and multiple instances of Policy Enforcement Points (PEPs). Reference: [OpenGroup], p. 18 | Load Balancer; PEP; Subject Descriptor | Clustered PEP | | This pattern makes highly available authentication components over clustered Web containers. Reference: [OpenGroup], p. 46 | Recoverable Component; Hot Standby; Cold Standby; Comparator-checked Fault Tolerant System | Layered Security | | This pattern configures multiple checkpoints. Reference: [Romanosky2001], p. 7 | Check Point; Authentication Gateway; Self Registration; Checkpointed System | Cold Standby | | This pattern describes how to structure a security system or service to resume service after a system failure. The Cold Standby pattern typically consists of one active Recoverable Component and at least one standby Recoverable Component. The Cold Standby pattern differs from the Clustered PEP pattern in that the latter primarily provides an authentication service as a Policy Enforcement Point, while the former may be any security service (including PEP). Reference: [OpenGroup], p. 49 | Disaster Recovery; Recoverable Component; Hot Standby; Cold Standby; Comparator-checked Fault Tolerant System | Comparator-checked Fault Tolerant System | | This pattern structures a system that enables the detection of independent failure of any component. It requires a fault-detecting mechanism to be in place to report or detect any system fault for a security system, for example, polling the state of the security device periodically, or checking the heartbeat of the Secure Service Proxy, Secure Daemon, or similar intermediaries. Reference: [OpenGroup], p. 51 | Tandem System | Journaled Component | | This pattern specifies how to capture changes to a security component's state for future system state recovery. Reference: [OpenGroup], p. 53 | | Hot Standby | | This pattern describes how to structure a security system or service to provide highly available security services, or to protect system integrity from system failure. This is usually done by synchronizing state updates to the replica or back-up security components without temporary loss of security services in case of full or partial system failure. Reference: [OpenGroup], p. 55 | Synchronized Distributed System; Replicated Transaction |
Web Tier Table 8-3 shows a list of known security patterns that support the Web Tier, which represents the components responsible for the presentation logic and delivery. The Web Tier accepts the client requests and handles access control to business service components. The security patterns shown in the table enable securing the client-to-server or server-to-server communication in the infrastructure as well as the application. Business Tier Table 8-4 shows a list of known security patterns that support the security services in the Business Tier. The Business Tier represents the business data and business logic. Integration Tier Table 8-5 shows a list of security patterns that facilitate integration with external data sources. Infrastructure and Quality of Services Table 8-6 shows a list of security patterns that describe enabling infrastructure capabilities and QoS requirements, such as availability, reliability, and scalability. As you may be aware by now, the focus and scope of existing security patterns are mostly limited to the infrastructure level, and they do not address the core application-specific security issues and their associated challenges. Nor do they attempt to adopt the core security services such as authentication, authorization, auditing, confidentiality, non-repudiation, and other requirements mandated by enterprise-scale applications and Web services. |