|
||
|
Core Security Patterns: Best Practices & Strategies for J2EE, Web Services, & Identity Management |
||
 By Christopher Steel, Ramesh Nagappan, and Ray Lai Published by Prentice Hall ISBN: 0131463071 Buy Now! Published:October, 2005 Pages:1088 |
|
|
Trade-Off Analysis (TOA)
The purpose of trade-off analysis is to improve the quality of security architecture with explicit, efficient, and rational decisions. TOA provides stakeholders with a systematic way of improving and validating the security architecture with its use of multiple security criteria, options, alternatives, and recommendations. In the security architecture discipline, it helps to weigh choices of security features against potential threats or vulnerabilities. This assists in justifying a financial case or identifying alternative options.A typical TOA artifact contains all of the security architecture criteria and safeguard options and alternatives. It will also include an Effect Matrix, where the security options/alternatives are represented in columns and security criteria are represented in rows. The cells have two values: the top value indicates the magnitude of impact on a scale from –10 to 10, and the bottom value indicates the relative importance of that security criterion on a scale from +1 to +10. Table 8–2 illustrates an example Effect Matrix.
Thus, TOA is a ranking index for making architectural security decisions with clear assumptions and for addressing associated uncertainties.
Security Patterns
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 J2EEbased 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.
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.
Table 8–3 Existing Security Patterns Supporting the Web Tier
| Pattern 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-toserver 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 multithreaded, 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 |
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.
Table 8–4 Existing Security Patterns Supporting the Business Tier
| Pattern 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 | |
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.
Table 8–5 Existing Security Patterns Supporting the Integration Tier
| Pattern 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 Services
| Pattern 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; Comparatorchecked 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; Comparatorchecked Fault Tolerant System | |
| Comparatorchecked 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 |
Security Patterns for J2EE, Web Services, Identity Management, and Service Provisioning
There are new security patterns specific to delivering end-to-end security in J2EE applications, Web services, identity management, and service provisioning. These security patterns differ from existing security design patterns in that they address the end-to-end security requirements of an application by mitigating security risks at the functional and deployment level, securing business objects and data across logical tiers, securing communications, and protecting the application from unauthorized internal and external threats and vulnerabilities.A simple taxonomy by logical architecture tiers are made here: Web Tier, Business Tier, Web Services Tier, and Identity Tier. Ideally, these patterns and others like them will be maintained in a patterns catalog that will be consulted during the security architecture activity in order to feed patterns into the security design. Through many versions of the application and across applications, these patterns will continue to grow and their implementation will be refined.
These patterns are usually structured and represented using a standard pattern template that allows expressing a solution for solving a common or recurring problem. The template captures all the elements of a pattern and describes its motivation, issues, strategies, technology, applicable scenarios, solutions, and examples.
Excerpt continued on Page 4
About the author
|
Christopher Steel, CISSP, ISSAP, is the President and CEO of FortMoon Consulting and was recently the Chief Architect on the U.S. Treasury's Pay.gov project. He has over fifteen years' experience in distributed enterprise computing with a strong focus on application security, patterns, and methodologies. He presents regularly at local and industry conferences on security-related topics.
Ramesh Nagappan is a Java Technology Architect at Sun Microsystems. With extensive industry experience, he specializes in Java distributed computing and security architectures for mission-critical applications. Previously he coauthored three best-selling books on J2EE, EAI, and Web Services. He is an active contributor to open source applications and industry-standard initiatives, and frequently speaks at industry conferences related to Java, XML, and Security. Ray Lai, Principal Engineer at Sun Microsystems, has developed and architected enterprise applications and Web services solutions for leading multinational companies ranging from HSBC and Visa to American Express and DHL. He is author of /J2EE Platform Web Services/ (Prentice Hall, 2004). |
