Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management
| 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. Security Pattern Template
To facilitate using the security patterns, we adopted a pattern template that consists of the following:
In the following sections, we will present the security patterns catalog and discuss each pattern and its logical tier. We will use sample scenarios and describe how these security patterns relate to each other and together contribute to the end-to-end security of an application. Security Patterns Catalog
In this section we introduce the security design patterns that facilitate securing J2EE-based applications, Web services, identity management, and service provisioning technologies. We will identify the patterns based on their logical tier representations, such as Web Tier, Business Tier, Web Services Tier, Identity Tier, and Service Provisioning. Web Tier Security Patterns
Table 8-7 shows a list of security patterns that are available in the Web Tier.
Business Tier Security Patterns
Table 8-8 shows a list of security patterns that are available in the Business Tier.
Web Services Tier Security Patterns
Table 8-9 shows a list of security patterns that are available in the Web Services Tier.
Security Patterns for Identity Management and Service Provisioning
Table 8-10 shows a list of security patterns available for the Identity Tier and Secure Service Provisioning.
Security Patterns and their Relationships
Security patterns can seem very complex before we know the role and context of how they are related to each other, how they are relevant to the scenario, and how to apply them end-to-end in a typical application design process. Figure 8-4 depicts how all the security patterns just presented work together in the Web Tier (interacting with the clients), the Business Tier (encapsulating business logic and related processes), the Web Services Tier (integrating with internal or external application infrastructure), and the Identity Tier (for signing-on the authenticated identity with identity infrastructure providers). Figure 8-4. Security patterns and their relationships
Applying Security Patterns
Let's consider a Web-based business portal as an example. The portal hosts business services from multiple business partner resources and provides member rewards redemption services. In a typical scenario, a subscriber logs in to the member rewards provider portal to check his membership award balance and submits a request to an affiliate content provider (a trading partner of the service provider) to redeem points and obtain a gift. Web Tier
The subscriber uses a Web browser to sign on to the rewards portal. The portal initiates a secure communication channel between the client browser and the Web server using the Secure Pipe pattern. The Secure Pipe establishes the transport-layer security between the client and server using secure handshake protocols (such as SSL or TLS), which provide an encrypted data exchange and digital signatures for guaranteed message integrity. Once the secure communication channel is established, the Front Controller pattern is used to process application requests (refer to http://java.sun.com/blueprints/patterns/FrontController.html for details). The Front Controller uses a Secure Base Action pattern that attempts to validate the session. Finding that the session information does not exist, the Secure Base Action uses the Authentication Enforcer pattern to authenticate the subscriber. The Authentication Enforcer prompts the subscriber for his user credentials. Upon successful authentication of the user credentials by the Authentication Enforcer, the Secure Base Action pattern uses the Secure Session Manager pattern to create a secure session for that user. It then applies the Authorization Enforcer pattern to perform access control on the request. Based on the user credentials and the relevant user provisioning information, it creates a secure session to access the required membership functions. During this process, the application uses the Secure Logger pattern to make use of the application logging infrastructure and initiates logging of all the user requests and responses by recording the sensitive business information and transactions, including success or failure attempts. Figure 8-5 depicts the scenario with a sequence diagram showing the participants in the Web Tier. Figure 8-5. Web Tier security patterns sequence diagram
In Figure 8-5, the actors denote the security patterns used. The Service Requester (or client) sends a request to initiate business services in the online portal. The Secure Pipe secures the service request in the transport layer. The Secure Base Action validates the session and uses the Authentication Enforcer to authenticate the session. The Authentication Enforcer will in turn request user credentials from the service requester and log the authentication result in the Secure Logger. Upon successful authentication, the Secure Base Action will create a secure session under the Secure Session Manager. It will also use the Authorization Enforcer to authorize the request and use the Intercepting Validator to validate the parameters in the request. Upon successful authorization processing, the Secure Base Action will log the events using the Secure Logger. Business Tier
Under the secure session, a Container Managed Security pattern may be used to delegate authentication and authorization handling of the requests to the application server container. Policy can then be applied declaratively, in an XML deployment descriptor, or programmatically, using the container's J2EE security APIs. In our example, the business portal architects and designers require a more dynamic policy framework for the Business Tier and choose not to use container managed security due to the relative static nature of the deployment descriptors. Instead they use a combination of Business Tier patterns to provide security in the back-end business portal services. Once the request has been processed in the Web Tier, the application invokes the relevant Business Tier services. These services are fronted using the Secure Service Façade pattern. This pattern can be augmented by the Container Managed Security pattern and is used for authenticating, authorizing, and auditing requests from the Web Tier. Anticipating a large user volume through the business portal, its Web Tier and Business Tier are placed on separate machines (horizontally scaling) in order to enable high-scalability. Since the Business Tier lives in a different application server instance, authentication and authorization must be enforced on the Business Tier via security context propagation. This may seem redundant, but were it not done this way, there would be a significant security risk. The Secure Service Façade represents the functional interface to the back-end application services. This may include a service to inquire about the membership award balance and the submission of the reward redemption request. These may be business functions to which the subscriber is not entitled. The Secure Service Façade will use the Policy Delegate pattern to determine and govern the business-related security policies for the services to which the requester is entitled. When a request is first made to the Secure Service Façade, it will use the Dynamic Service Management pattern to load and manage the Policy Delegate class and any security-related supporting classes. The Dynamic Service Management pattern allows the application to maintain up-to-date policy capabilities by providing the ability to dynamically load new classes at runtime. In addition, it provides JMX management interfaces to the Policy Delegate for management and monitoring of policy operations. Once the Policy Delegate is loaded, it can provide authentication and authorization of requests. When the customer requests their rewards balance, the Policy Delegate authenticates and then authorizes the request. It then uses the Secure Session Object pattern to create a session object such as an SSO (Single Sign-on) token that can then be used in subsequent service calls or requests to verify the identity of the requester. The Secure Service Façade provides business and security auditing capabilities by using the Audit Interceptor pattern. Upon invocation, it notifies the Audit Interceptor of the requesting service. The Audit Interceptor then determines if, when, and how to log the request. Different types of requests may be logged in different locations or through different mechanisms. For the membership award balance service, the Audit Interceptor disregards the balance inquiries and generates an audit entry message that gets logged each time a redemption request is made. Since confidential material is passed via the Secure Service Façade and the back-end services, it is necessary to provide a means for securing data, such as account numbers, balances, and credit card information, which must be prevented from disclosure in log files and audit entries. The Secure Service Façade uses the Obfuscated Transfer Object pattern to obscure business data from potential unauthorized interception and intentional or unintentional access without authorization. In this case, our customer's credit card number, account number, and balance amount are obfuscated so that they will not show up in any logs or audit entries. Figure 8-6 depicts a sequence diagram with some details about the scenario in the Business Tier. Figure 8-6. Business Tier security patterns sequence diagram
In Figure 8-6, the actors denote the security patterns used. Typically, once the service request is processed by the Web Tier security patterns, a Business Delegate pattern (refer to http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html for details) will be used to invoke Business Tier objects. The Business Delegate will create a service session using the Secure Service Façade (either local or remote synchronous invocation). The Secure Service Façade will instruct the Audit Interceptor to initiate the auditing process either synchronously or asynchronously. It will also load the Dynamic Service Management pattern for forceful instrumentation of management and monitoring process for business components. The Dynamic Service Management creates an instance of the Policy Delegate. The Secure Service Façade will start processing the request and invoke the Policy Delegate functions to process the request with the relevant policies defined for the objects or the service requester. It creates an instance of a Secure Session Object for the online portal transactions. The Secure Service Façade will invoke the business object to process business data in the service request. This may involve accessing business information related to the membership reward balance or requesting reward redemption services, in our sample scenario. To protect the business data in the transfer object, the business object can create instances of Obfuscated Transfer Object for delivery. Upon completion of the service request, the Secure Service Façade instructs the Audit Interceptor to capture and verify application-related events. Web Services Tier
To communicate with the content providers, the service provider portal acts as a Web Services requester using a SOAP/XML-based Web services backbone to send membership award catalog/redemption requests to service providers hosted via Web services. The Web servicesbased service provider intercepts the service request from the member portal using the Message Interceptor Gateway pattern. The SOAP service request (using RPC-style messaging or the request-reply model) is verified and validated for message-level security credentials and other information by applying the Message Inspector pattern. Then the underlying services apply the Secure Message Router pattern that securely routes the message to the appropriate service provider or recipients. Upon successful message verification and validation using the Message Inspector pattern, the response message will be routed back to the intending client application. If asynchronous messaging intermediaries (using document-style messaging) initiate the SOAP messages, the Message Interceptor Gateway pattern at each intermediary will process these SOAP messages and apply similar techniques. This process may also involve forwarding the request to an identity provider infrastructure for verification of the authenticity of the credentials. Figure 8-7 depicts a sequence diagram with some details about the scenario for Web services. Figure 8-7. Web Services Tier security patterns sequence diagram
In Figure 8-7, the actors denote the security patterns used. The Service Requester sends a request to invoke business services for the membership award catalog or redemption requests with other content providers. The Secure Pipe secures the service request. The Message Interceptor Gateway intercepts the SOAP message and uses the Message Inspector to verify and validate the security elements in the SOAP message. The Message Inspector confirms with the Message Interceptor Gateway that the message is validated (or not validated). Upon successful validation, the Message Interceptor Gateway forwards the SOAP message to the Secure Message Router, which will send the SOAP message to the final service endpoints provided by the Service Provider. The Service Provider will process the service request and return the result of the membership award request to the Service Requester via the Secure Pipe. Identity Tier
The member portal currently has the capability to allow subscribers to sign on with other underlying services, including the business applications hosted by the service provider or the remote business services provided by the content provider (trading partners). To establish identity and grant access to users to other business services to which they are entitled, the portal uses protocols based on SAML and Liberty Alliance specifications. Using the Assertion Builder pattern, the application creates a SAML authentication assertion for each business service that the subscriber chooses to invoke from the Authorization Activator pattern. It then encapsulates the user credentials in the security token in the SAML assertion using the Credential Tokenizer pattern. Because the customer loyalty system runs on the legacy back-end systems, the SSO Delegator pattern can be applied to integrate with the legacy back-end EIS system to provide the single sign-on access. This also facilitates global logout capability. Using the Password Synchronizer as a supporting infrastructure function, the application runs secure service provisioning to synchronize user accounts across service providers. It complements the single sign-on security functionality provided by the SSO Delegator pattern and the Assertion Builder pattern. The subscriber inquires about the account balance of his or her membership award. Figure 8-8 depicts a sequence diagram with some details about the scenario in the Identity Tier. Figure 8-8. Identity Tier security patterns sequence diagram
In Figure 8-8, the actors denote the security patterns used. Before the subscriber can use different remote membership reward services, his or her user account and password need to be registered first, using the Password Synchronizer. Once the subscriber signs on to the Web portal, he or she initiates a single sign-on request using the Single Sign-on (SSO) Delegator to the Web portal services and the associated service providers. The SSO Delegator will initiate remote security services. In order to process requests from the subscriber under the single sign-on environment, the service provider requires a SAML assertion (for example, a SAML authentication assertion). The SSO Delegator will then create a SAML assertion statement using the Assertion Builder, which will use the Credential Tokenizer to digitally sign the SAML assertion statement with the user credentials. Upon completion, the Assertion Builder will return the SAML assertion statement to the SSO Delegator, which will forward the SAML assertion statement to the service provider. After the subscriber has finished the membership reward request, he decides to log out from the online portal. He issues a global logout request to the SSO Delegator, which will issue the logout request to the service providers. Upon completion, the SSO Delegator notifies the service requester of the global logout result. Patterns-Driven Security Design
As we discussed in the above example, a security design methodology is essential to any security-conscious service or application. Part of that methodology is adopting a patterns-driven security design process for addressing security requirements throughout the software development life cycle. This security design process starts in the security architecture phase and continues into the security design phase. Figure 8-9 presents a patterns-driven security design process. Figure 8-9. Patterns-driven security design
In Figure 8-9, in the architecture phase, the architects identify potential security patterns that can be used to satisfy the application-specific security requirements and rationalize the mitigated risks and trade-offs. Based on those inputs, the security design process will be carried out. The security designers perform factor analysis, tier analysis, trust models, threat profiling. They then create security policies that realize and validate the security use cases, architecture, and the identified patterns. During the design process, if there exists a security pattern that corresponds to the security use case requirements and it is architecturally significant, it can be incorporated into the security design. If there is no security pattern available, a new design approach must be taken. It can then be considered for reuse. If it is found to be reused enough, it can be classified as a pattern for inclusion into the Security Pattern Catalog. In the build and integration portions of the development life cycle, architects and designers apply the relevant security patterns to the application design that satisfy the security use cases. They choose to use their preferred security framework tools to implement the application using the security patterns. Prior to the deployment process, testers evaluate the application to ensure no security requirements or risk areas were overlooked. If a gap is identified that requires a change to the design, architects can revisit the security patterns to see if any additional security patterns or protection mechanisms are necessary. White and black box testing is an essential security measure that must be performed prior to deploying an application. In summary, the security architecture and design process can be broken down into the following steps:
By applying this design process within a structured methodology, architects should be able to complete a secure architecture design using security patterns and derive a secure application architecture addressing the known risks and vulnerabilities. They should also be able to maintain a customized security pattern catalog based on past design and implementation experience or known design patterns. Security Design Processes
In this section, we will take a look at each of the design processes in detail as part of the security design. Factor Analysis
The objective of end-to-end application security is to provide reliable and secure protection mechanisms in business applications that can support authentication, authorization, data integrity, data privacy (encryption), non-repudiation (digital signature), single sign-on (for better efficiency and cost-effective security administration), monitoring and audit control, and protection from various security threats or attacks. The related security attacks can be malicious code attacks, Denial of Service (DoS)/Distributed DoS attacks, dictionary attack, replay attacks, session hijacking, buffer overflow attacks, unauthorized intrusion, content-level attacks, session hijacking, identity spoofing, identity theft, and so on. In an end-to-end security perspective, the security design will vary by a number of application-, platform-, and environment-specific requirements and factors, including the following. Infrastructure
Web Tier
Business Tier
Web Services Tier
Identity Tier
Quality of Services
Relating the Factor Analysis to apply Security Patterns. The security factor analysis is a good practice to use to identify the important application-specific and environment-specific constraints of the target applications and the target clients in relation to the overall security requirements. This will also help with locating the appropriate security patterns that can be used to address the business problems. For example, in a Web-services security design scenario, we address the application- and environment-specific security requirements and constraints by representing the following security patterns:
Applying to the Media and Devices. The security factors will be different when applied to different media or client devices. Different media and client devices, ranging from a Web browser, Java card, J2ME phones, and a rich client to legacy systems, have different memory footprints. Some of them may have more memory capacity to store the key pairs, or some of them have less memory to perform required security checking. For instance, Web browsers are able to store the certificates keys and provide a flexible way to download signed Java applets, establish client-certificate-based authentication, and use SSL communication. J2ME based mobile phones and client devices operate on a lesser memory footprint and lesser processing speed. It is harder to use encryption and signature mechanisms and to perform complex cryptographic processing with these phones and devices due to their memory capacity and environment constraints. A possible security artifact for the factor analysis is to produce a summary of the security factors based on the application-specific, platform-specific security requirements and the technology constraints in the security requirements document. This can be a separate appendix or a dedicated section that highlights the key areas of security requirements. The factor analysis provides an important input to the security architecture document. From the factor analysis, security architects and developers can justify which security design patterns or security design decisions should be used. Tier Analysis
Tier analysis refers to the analysis of the security protection mechanisms and design strategies based on the business applications residing in different logical architecture tiers. In particular, it identifies the intra-tier communication requirements and dependencies. For instance, architects can use the HTTPS protocol to secure the data transport for applications residing in the Web Tier, but the same security protection mechanism will not work for applications residing in the Business Tier or in the Integration Tier. Similarly, the security protection mechanisms for asynchronous Web services will not work for synchronous Web services due to the difference in the RPC-style service invocation and document-style messaging architecture. The security design strategies and patterns discussed in this book are grouped by tiers to reflect what security protection mechanisms are relevant for each logical architecture tier. A possible security artifact for the tier analysis is to produce a Tier matrix of security features by architecture tiers and by application layers. This matrix identifies the key security capability and design elements and their relation to different architecture tiers and application layers. During the security review, security architects and developers can evaluate the appropriateness and reliability-availability-scalability of the security design based on the tier matrix. Threat Profiling
Threat profiling denotes profiling of architecture and application configurations for potential security weaknesses. It helps to reveal the new or existing security loopholes and the weaknesses of an application or service. Thus, it enumerates the potential risks involved and how to protect the solutions built and deployed using them. This will involve defining and reinforcing security deployment and infrastructure management policies dealing with updating and implementing security mechanisms for the application security infrastructure on an ongoing basis. It can be applied to the newly designed application systems, existing applications, or legacy system environments. A possible security artifact for threat profiling identifies and categorizes the types of threats, potential security vulnerabilities, or exposures that can attack the application systems. A use-casedriven data flow analysis can also be used to trace the potential risks. For example, a threat profile may identify and list the threats and vulnerabilities as follows:
In addition, it would discuss the security considerations and risk management techniques for all the identified loopholes and flaws. Trust Model
A trust model is the backbone of the security design. It provides mechanisms that establish a central authority of trust among the components of the security architecture and that verify the identity of participating user entities and their credentials, such as name, password, certificates, and so forth. In simpler terms, a trust-modeling process is defined as follows:
A trust model may contain a variety of systems infrastructure, business application, and security products. From a security design perspective, a trust model allows test-driving the patterns used, imposing a unique set of constraints, and determining the type and level of threat profiling required. Significant effort must go into the analysis preceding creation of the trust model to ensure that the trust model can be implemented and sufficiently tested. A trust model must be constructed to match business-specific requirements, because no generic trust model can be assumed to apply to all business or security requirements and scenarios. Let's take a server-side SSL example in which we assume that an SSL session is initiated between a Web browser and a server. The Web browser determines the identity of the server by testing the credentials embedded in the SSL session by means of its underlying PKI. The testing of credentials proves a "one-way trust model" relationship; that is, the Web browser has some level of confidence that the server is who it claims to be. However, the server has no information for testing the Web browser. Essentially, the server is forced to trust the Web-browserreturned content after initiating its SSL session. Two possible security artifacts from the trust model can be produced. First, the analysis of the trust model usually specifies the security requirements and system dependencies for authentication and authorization in the security requirements specification. This provides the basic design consideration for authentication and authorization and provides input to the definition of system use cases for authentication and authorization. Second, the trust model will identify the security risks associated with the trust relationship. These form an important component in the overall risk document. For an example of a trust model, refer to [Liberty1] and [XACML2]. Policy Design
Security policies are a set of rules and practices that regulate how an application or service provides services to protect its resources. The security policies must be incorporated into the security design in order to define how information may be accessed, what pre-conditions for access must be met, and by whom access can be permitted. In a typical security design artifact, security policies are presented in the form of rules and conditions that use the words must, may, and should. These rules and conditions are enforced on the application or service during the design phase by a security authority by defining the rights and privileges with respect to accessing an application resource or conducting operations. Security policies applied to an application or service can be categorized as the following six types:
In addition, in some cases we need to design and apply target application environment and business-specific policies such as:
The security policy artifacts must capture these policy requirements and define the roles and responsibilities of the stakeholders who are responsible for implementing and enforcing them. It is also important to incorporate updates based on the changes in the organization and the application environment. Classification
Classification is a process of categorizing and designating data or processes according to an organization's sensitivity to its loss or disclosure. In an application or service, not all data has the same value to the requesting entity or to the business. Some data, such as trade-secrets, legal information, strategic military information, and so on, may be more sensitive or valuable than other data in terms of making business decisions. Classification is primarily adopted in information-sensitive applications or services in order to prevent the unauthorized disclosure of information and the failure of confidentiality and integrity. The classification of data or processes in an application or service is typically represented as classes with five levels ranging from the lowest level of sensitivity to the highest. The least sensitive level is 1, and the most sensitive is 5.
In a classified information system, all data has an owner and the owner is responsible for defining the sensitivity of the data depending on the organizational policies. If the owner is not sure about the sensitivity level, then the information must be classified as "3 - Confidential." The owner is also responsible for security of the data as per the organization security policy pertaining to the classification and for defining who can access the data. Classification also depends on organizational requirements related to information confidentiality. Organizations must define their classification terms and definitions. Security Labeling
Security labels represent the sensitivity level of data or processes. They denote the type of classification assigned. During runtime access, the labels are verified and validated in accordance with an organization's security policy. To adopt classification and labeling of data processes, it is necessary to choose a highly secure operating system (for example, Trusted Solaris Operating system) that offers labeling of data and processes based on discretionary and mandatory access-control policies throughout the operating system, including all users, files, directories, processes, services, and applications. The label, once assigned, cannot be changed other than by an owner or authorized person in the classification hierarchy with higher privileges. Classification and labeling requirements must be identified during the design phase. Classification and labeling must be adopted when an application or service is required to manage highly sensitive data or processes and the business or organization dictates classification requirements for its information with higher confidentiality. Application Security Assessment Model
Before architects and developers decide on and adopt any security design strategies or patterns, they usually perform an assessment of the application security architecture and any security mechanisms in use. Typically, external security consultants or specialized security architects review the overall security requirements and the current security design in use. Based on their assessment, they will recommend a list of suggested security mechanisms to meet their application security goals as short-term and long-term implementations. The assessment checklist has five columns in total. The first two columns enumerate the security services and the security mechanisms that provide them. The next three are checkboxes denoting if the mechanism is suggested for the architecture (that is, recommended for adoption based on best practices), if it is implemented in the current design, and/or whether it is planned for implementation in the future. Let's consider an application architecture that delivers a Web-based business-to-consumer portal that integrates a variety of back-end applications. The application security architecture adopts a basic authentication using username and password for authenticating the user, authorizes the user as a customer or administrator to perform further operations, and captures all events and actions using a logging mechanism for accountability. The back-end applications running on heterogeneous platforms make use of a shared security context to provide single sign-on access and to participate in portal-initiated transactions. Table 8-11 shows a simple assessment list for an examplea Web-based application architecture that has adopted a simple authentication using username and password mechanisms. The application is found to not be sufficient to address the security requirements because it is experiencing denial of service attacks using fake requests. After assessment, it is suggested to incorporate client-certificatebased mutual authentication to verify the originating source and to restrict forged requests from further processing. In terms of authorization mechanisms, the application architecture currently allows granting access based on user groups; the assessment suggests granting access based on roles, such as Web administrator, system administrator, and business manager.
|
Категории