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

This section illustrates the design process for the security use cases and applies the security architecture and those identified security design patterns. UML-style sequence diagrams are used to denote the flow of events and how each logical component interacts with specific security patterns. The security service design discussed here should be vendor-agnostic, and can be implemented in practically any language on any platform. We refer to J2EE-specific terminology because our security use cases and system constraints mandated the use of a J2EE environment, but those should not be misinterpreted as a necessary part of the security design.

Policy Design

Prior to the design elaboration phase, we need to document our policy design. In terms of security, the policy design must provide rules defining appropriate and inappropriate behavior, who and what to trust, level of control, communication requirements, procedures, and associated tools to support the security infrastructure. To do this as part of eRewards portal security architecture, we need to document the following security policy artifacts:

• User registration, revocation, and termination policy

• Role-based access control policy

• PKI management policy

• Service provider trust policy

• Data encryption and signature verification policy

• Service provider assessment policy

• Service Audit and traceability policy

• Proactive and Reactive risk-assessment policy

• Information disclosure and sensitivity policy

• Password selection and maintenance policy

• Information classification and labeling policy

• DMZ Environment access policy

• Application administration policy

• Host and network administration policy

• Application failure notice policy

• Service failure, continuity, and recovery policy

These policies serve as principal guidelines during implementation and deployment. They also contribute to the regulatory compliance requirements specific to the type of business handled by the eRewards portal. Sarbanes-Oxley (SOX) is one example of those business-related regulatory requirements.

Policy design is a tedious undertaking, and a full explanation could consume a chapter in and of itself. In this chapter, we are not able to bore down to the details of the above artifacts. The sample artifacts for policy design are available at http://www.coresecuritypatterns.com. Refer to Chapter 8, "The Alchemy of Security Design: Methodology, Patterns, and Reality Checks," for more information about Policy Design.

Factor Analysis

To begin construction of a security design, we must perform a factor analysis to identify the current system infrastructure-specific constraints and requirements. These constraints and requirements will drive the design decisions as we move forward. Forthcoming activities such as detailed security design and implementation will be based heavily on the analysis done here.

Infrastructure

• Target Platform: We need to establish the criteria for the host environment selection to provide a secure and reliable environment to run our Web portal applications. The key aspects to consider include operating systems, compatibility with applications/technologies, maintainability, security features, and deployment requirements. We need to identify the known security risks, preconditions, and vulnerabilities associated with the selected platform, OS, and software. To host our Web portal, we choose to use Trusted Solaris 8 as the OS environment for bastion hosts and for all the target hosts running the application server instances.

• Number of Access Points: We anticipate that our peak usage for the upcoming year will be around 1 million users from different geographic locations and time zones. So we need to facilitate a dedicated infrastructure to support different time zones. The access points should be geographically separated but colocated in the same network. The host infrastructure should provide fault-tolerance and failover capabilities in case of a service failure at one location.

• Network Perimeter Security: To design the network security and to control inter-tier traffic flows, we need to identify the routing/firewall appliances, multilayer Ethernet switches, and load-balancing devices. We choose to separate the Web tier and application server tier with a separate firewall. We choose to adopt a horizontally scalable solution including multiple server platforms running at different locations hosting many instances of the Web server at the Web tier and multiple server instances in the application server tier. The network design is composed of segregated networks, implemented physically using VLANs configured by network switches. We choose to use Foundry switches and Netscreen firewall devices. The internal network used the 10.0.0.0 private IP space for better security and portability advantages. Although several networks reside on a single active core switch, network traffic is segregated and secured using static routes, access control lists (ACLs), and VLANs. The trust zones are created using a Netscreen firewall and they map directly to the VLANs. The Netscreen firewall performs the Layer 3 routing. This configuration directs all traffic, resulting in firewall protection between each service tier.

Web Tier

• Authentication Requirements: Based on anticipated clients, we will support form-based authentication for our Web users and client certificate-based mutual authentication for our trading partners. All hosts are identified and trusted using peer authentication. All unauthorized connections from untrusted and IP addresses will be dropped.

• Client Devices or Platform Used: Our interactive clients will be Internet users who are using a variety of browsers on a variety of platforms. We therefore want to avoid any platform- or browser-specific code. We want to avoid or limit as much as possible the use of JavaScript. We also want to avoid requiring use of client-side mobile devices without browser support. Our trading partners will be connecting by way of server-to-server communication through trusted host authentication. The client devices and platforms are not a concern because the communication is all by way of standardized protocols that are device/platform-independent.

• Web Agent: The Web servers running on bastion hosts will make use of a Web agent to verify all incoming and outgoing Web requests for session tokens. Upon identification of fake or forged requests using a legitimate identity, the Web agent will log the request, initiate a request to the Identity Provider to revoke the user, and also send a notification to the administrator to audit those fake requests. This helps to identify and foil DoS and man-in-the-middle attacks on the Web tier.

Business Tier

• Data Obfuscation: To protect sensitive information such as credit card numbers, we need to obfuscate appropriate data in the Business tier. This allows us to log, audit, and transmit data without revealing sensitive information.

• Auditing: Due to the auditing requirements specified in the policy design, we need to audit our service transactions. Because the auditing requirements are expansive, this capability should be provided as part of the Business tier framework and not implemented on a service-by-service basis.

Web Services Tier

• Restricting Direct Access to Endpoints: The Web services communication with service providers makes use of the HTTP and HTTP/SSL protocols and standard ports of the firewall. This lacks support for providing protection against XML-based message attacks and content-layer vulnerabilities such as buffer overflow, malicious data injection, and virus attachments. We will introduce Message Interceptor Gateway and Message Inspector pattern-based mechanisms for enforcing XML-based security mechanisms and access control policies to the exposed Web service endpoints and WSDL descriptions.

Security Infrastructure

Based on the identified system requirements, we will evolve a tentative security infrastructure showing the security infrastructure, including application services, hosts, and network topology. Figure 14-8 shows a logical representation of the security infrastructure setup for our Web portal.

Security InfrastructureDetailed components

Figure 14-9 further elaborates on the security infrastructure with the physical representation of network security appliances, including switches, firewall, and load-balancer appliances. It also shows how the network topology is segregated physically by network switches as VLANs and how the Web server, application server, and back-end application traffic multiplexed on one VLAN.

Tier Analysis

A tier analysis becomes necessary because there are tier-specific factors and issues that will influence our design implementation. This analysis will then serve as the final analysis step in our design process.

Web Tier

The decision was made early on to use an external Identity Provider for identity management and authentication. Because authentication will be done externally, we will need to secure the communication channel with the external Identity Provider using a Secure Pipe pattern. The portal will also need to collect the user credentials (username and password) from the client. To do so, we will need to use the Secure Pipe there as well in order to prevent the password being sniffed. We will implement the Secure Pipe using SSL hardware accelerator-based device mechanisms installed on the bastion hosts that run the Web servers. This will provide us with better SSL performance.

We chose to use the Authentication Enforcer pattern to represent the form-based authentication process in the Web tier. In our threat profile modeling, we determine that a hacker may try to guess a user's password. To prevent a hacker's success, we will configure our external Identity Provider to make use of strong password policies with minimum lengths and a mixture of alpha-numeric characters that make guessing impractical. We will also mandate account lockouts after a certain number of incorrect attempts.

One of the business requirements of the application is to provide the user with a form for reward selection. To prevent attackers from crashing the system by sending junk data in the request, we will use an Intercepting Validator pattern to scrub the data when it is received. We will also use a Secure Logger pattern to securely log all incoming requests for security monitoring and auditing. This will allow us to detect malicious activity and take preventive measures.

Business Tier

On the Business tier, we will address auditing and data obfuscation. We have identified the Audit Interceptor and Obfuscated Transfer Object patterns to address these factors. On the Business tier, we are only concerned with business-level auditing. We will not have sufficient insight into the incoming requests to do much security auditing. We can audit some business-level security audit events such as profile modification, but in general, security auditing will not be necessary on the Business tier. We will use an Intercepting Session Façade strategy that will provide us with an easy way to incorporate auditing into our Business tier without impacting our business object developers. This will reduce risk and provide a means to add or modify auditing requirements in parallel to other development.

We also must address data obfuscation on the Business tier. On this tier, that means obscuring application-layer data sent between business services. Our Business tier resides in a trusted environment, so we are not going to address securing data within the application, only obscuring sensitive information written to logs or sent from our Business tier outside our environment to our trading partners. We will use two strategies for data obfuscation. Internally, we will use the Obfuscated Transfer Object pattern. Because this is a protected tier and we are not concerned with host-level intrusions for this issue, we will use the Masked List strategy, which will provide data obfuscation for sensitive data written to a log or otherwise output.

Web Services Tier

To facilitate communication with service providers with a standardized infrastructure and to address the authentication and authorization requirements such as representation of credentials and message formats, we use the Secure Message Router pattern. Adopting this pattern eliminates point-to-point security intermediaries and makes use of a Liberty agent for enabling SSO, global logout, identity registration, and termination.

To address the message-level security requirements of the service providers and to support non-disclosure of message contents to unintended recipients, we will use element-level encryption and signatures. This will be accomplished by using a message configurator to facilitate configuration of messages applying XML Encryption and XML Signature.

Identity Tier

We elected to use an external Identity Provider for managing user identities and performing authentication and authorization for the Web portal and the participating trusted service providers. To meet our identity-management requirements and avoid the common pitfall of vendor lock-in, we will choose a vendor that provides a Liberty II protocol-based single sign-on and global logout mechanisms. Through the use of SAML assertions and a Liberty II protocol, we will deliver a vendor-neutral identity infrastructure and provide an industry-standard interface for identity federation and enabling SSO with service providers.

Trust Model

With the use of a trusted external Identity Provider, our trust modeling becomes quite straightforward. The trust model in this case is simply based on the vendor's product implementation, which allows establishing trusted relationships between the Web portal and service providers. The Web portal and the service providers trust the SAML assertions issued by the external Identity Provider for authentication and authorization decisions. The portal and service providers make use of Liberty-enabled agents to communicate with the Identity Provider.

Threat Profiling

For this case study, we will not perform exhaustive threat profiling. We will take a simple attack tree and look at two branches. Based on our use case scenario, we will assume that the goal (that is, the root node of the tree) is to gain an unearned reward from our partner service. One branch of the attack tree impacts the Web tier and the other impacts the Web Services tier.

The first branch involves an attacker trying to gain access to a legitimate user's account. From there, the attacker can modify the user's address information and order rewards for that user that will get shipped to the attacker. To do this, the attacker can use two approaches:

• Guess the user's password.

• Use a network-based packet sniffing tool to obtain the user's password.

• The second branch deals with an attacker trying to plagiarize a Web service request to the service provider. The two nodes under this goal in the branch are:

• Spoof a message from scratch.

• Alter a legitimate message en route.

Figure 14-10 is a diagram of the attack tree based on our modeling of this simple profile.

Security Design

The first step in our security design is to flesh out our patterns based on the analyses. As part of the architecture, we identified a set of initial security patterns to be used. We can now go back and validate that those patterns fit or choose others as necessary. We will then begin data modeling and create our business and data access objects and services.

Relating the Analyses to the Security Patterns

The security analyses we performed previously were necessary to identify the important security elements of the application in relation to the security requirements. This will also help with locating the appropriate security patterns that can be used to address the business problems. For example:

• Secure the transport layer (Secure Pipe pattern).

• Verify and validate the SOAP messages for message-level security, payload verification, virus attachments, fake or forged messages (Message Inspector and Message Interceptor Gateway patterns).

• Centralize, coordinate, and validate the Web requests (Secure Base Action pattern).

• Establish the identity policies before making business requests (Assertion Builder pattern).

• Protect the Web tier from denial of service or brute force fake request attacks (Intercepting Web Agent pattern).

• Validate Web requests and responses (Intercepting Validator pattern).

• Enabling Liberty SSO and applying message-level security for sending messages to service providers (Secure Message Router pattern).

• Obfuscate business information between objects (Obfuscated Transfer Object pattern).

• Log and timestamp all Web requests from a particular identity (Secure Logger pattern).

• Audit all service requests and responses (Audit Interceptor pattern).

Data Modeling and Objects

Now that the patterns have been established, the designer can set the stage for creating the application-level security design. The first step in this process is to perform data modeling tasks. Data modeling represents the relationship and dependencies of business data and objects in the application design. It is essential to abstract what business data should be accessible (for access rights control), cached (for example, for data look-up), or stored in the database (for traceability and reporting). From a security perspective of data privacy, we would also like to know whether the entire business data contents or a subset of it should be accessible by the service requester. This is particularly important when considering whether the data objects should encapsulate the entire membership record or not.

The following section describes the list of business data objects that we will use in the application design and the related data classes. Because this chapter is a case study of the security design, not the functional application design, this section will discuss the security implications of these data objects and classes only.

Business Data Objects

Several business data objects can be encapsulated, including the in-basket for the catalog service (for example, a list of the product items selected), product details, purchase order (a "manifest" or collection of the merchandise ordered), and membership record (personal information about the subscriber and the current membership award balance).

For data access, we have decided to use Java Data Objects (JDO). The JDO API is a standards-based interface for modeling business data and abstracting the data for persistence. It is a useful technology for implementing business data objects in a functional application architecture design. Refer to http://java.sun.com/products/jdo/index.jsp for details.

Data Class

Figure 14-11 depicts a class diagram of the classes represented in the eRewards portal application. The controller servlet uses the order management servlet, the membership servlet, and the catalog servlet. Each of these servlets has its corresponding helper class. Some of the methods or attributes are implementation-specific, and some are added to support specific security requirements. For example, the controller servlet has two methods that are specific to supporting single sign-on functions: redirectLogin (as used in the user login use case) and verifySSOToken (which is used for verifying the security token that is used by the Identity Provider for single sign-on).

Service Design

For our service design, we have elected to focus on four major services:

• User Login Service

• Catalog Service

• Order Management Service

• Order Fulfillment Service

These services represent the main services within the application. We will not address every possible service for the case study because there may be many auxiliary services in a good service-oriented architecture. These are the main services that will allow us to demonstrate the security process sufficiently.

User Login Service

The user login service allows a user to sign on to the eRewards portal and makes use of the external Identity Provider for user authentication and single sign-on. Client refers to the subscriber who wants to sign on to the online portal. IdentityProvider refers to the external Identity Provider who provides the user authentication service. The user login service is important in supporting the security requirements of authentication, identity protection, and single sign-on. Figure 14-12 depicts the detailed process between Client and IdentityProvider.

• Client initiates login.

• The online portal directs the user to the ControllerServlet, which redirects the service request from Client to SecureBaseAction.

• SecureBaseAction processes the login request and invokes the user authentication service using AuthenticationEnforcer.

• AuthenticationEnforcer prompts Client to obtain user credentials for user authentication.

• AuthenticationEnforcer sends user credentials to LibertyAgent for authentication.

• LibertyAgent sends user credentials to IdentityProvider for authentication.

• Upon successful (or unsuccessful) authentication, IdentityProvider returns status code to the service requester. LibertyAgent passes down the status code to ControllerServlet, which will respond to Client.

Catalog Service

The user browses the online catalog to select product items or merchandise for which rewards will be redeemed. The online catalog aggregates merchandise information from various sources, including external partners and service providers. It is essential that the Web servers and the application servers are secure and that the security service introduced here is able to protect the client-to-server or server-to-server session and business transactions associated with the catalog service. In other words, the security patterns here should be able to support authorization, traceability, data privacy or confidentiality, availability, data integrity, and non-repudiation.

Figure 14-13a and Figure 14-13b depict the detailed process of how security is used to protect the user while invoking the catalog service. Client refers to the subscriber who wants to sign on to the eRewards portal.

• Client sends a request to view the product catalog from the Web portal upon successful authentication and authorization.

• FrontController processes the request and dispatches Client to the Catalog page.

• The Catalog invokes CatalogAction to retrieve the data.

• CatalogAction first delegates to the SecureBaseAction for security processing.

• The SecureBaseAction invokes the verifySSOToken method on the AuthenticationEnforcer.

• The AuthenticationEnforcer verifies the SSOToken for assuring single sign-on.

• The SecureBaseAction then invokes SecureLogger to log the request.

• The SecureLogger writes the message out to a flat file log.

• The CatalogAction then invokes the SecureServiceFaçade on the Business tier to request the product details from the CatalogService.

• The SecureSessionFaçade invokes the getCatalog method on the CatalogBO.

• The CatalogBO, in turn, sends the request message to the MessageInterceptorGateway.

• The MessageInterceptorGateway makes use of MessageInspector to verify the message for authentication and authorization assertions and message-level security mechanisms.

• The MessageInspector authenticates and authorizes the request using the IdentityProvider.

• Once validated, the MessageInterceptorGateway then invokes getProductDetails on the CatalogService.

• The CatalogService retrieves and returns the product details.

• The product details are returned to the CatalogAction.

• The Catalog then gets the data from the CatalogAction and displays it to the user.

Order Management Service

Upon completion of merchandise selection in the catalog service, the user confirms placing an order with the order management service. The order management service also verifies that the user has a sufficient membership award balance before executing the order. Because the order management service involves retrieving personal information, it is essential that the security service introduced here is able to protect the client-to-server or server-to-server session and business transactions associated with the order management service. In other words, the security patterns here should be able to support authorization, traceability, data privacy or confidentiality, availability, data integrity, and non-repudiation.

Figure 14-14 depicts the detailed process of how security is used to protect the user while processing an order. Client refers to the subscriber who wants to sign on to the online portal.

• Client initiates placing an order.

• ControllerServlet places an order with OrderManagementServlet.

• OrderManagementServlet forwards request to SecureSessionFaçade.

• SecureSessionFaçade uses OrderManagementHandler to invoke order management service.

• OrderManagementHandler initiates remote order management service from OrderManagementService.

• OrderManagementService gets membership record status from MembershipServlet.

• OrderManagementService verifies membership award status for eligibility before processing the order placement.

• Upon successful (or unsuccessful) verification, MembershipServlet returns status, membership award balance, and personal information (for example, delivery address).

• OrderManagementServlet processes the order if the status returned is positive.

• ControllerServlet logs the order management service request in the audit log.

Figure 14-15 depicts the details of processing the membership award record.

• OrderManagementService gets membership record status from MembershipServlet.

• MembershipServlet forwards request to SecureSessionFaçade.

• SecureSessionFaçade delegates the request to MembershipHandler to initiate remote membership Web service.

• MembershipHandler gets redemption points from MembershipService.

• MembershipService returns status and membership record to the service requester. Membershiphandler passes down the record to OrderManagementService.

Order Fulfillment Service

Upon completion of processing the order placement and membership balance verification, the online portal will proceed to send order details to external partners for order fulfillment. Because the order fulfillment service involves sending product details and personal information to external systems, it is essential that the security service introduced here is able to protect the server-to-server session and business transactions associated with the order fulfillment service. In other words, the security patterns here should be able to support authorization, traceability, data privacy or confidentiality, availability, data integrity, and non-repudiation.

Figure 14-16 depicts the detailed process of how security is applied to protect the user while fulfilling an order. Client refers to the subscriber who wants to sign on to the online portal. PartnerMerchantService represents the external system that handles order fulfillment requests.

• Client initiates order fulfillment service after confirming the order details with the recipient and the delivery address.

• ControllerServlet initiates order fulfillment service from OrderManagementService.

• OrderManagementService sends order fulfillment message in document-style SOAP messaging to SecureMessageRouter.

• SecureMessageRouter defines the message destination endpoint and its message-level security mechanisms.

• SecureMessageRouter routes order fulfillment messages to PartnerMerchantService.

• PartnerMerchantService verifies the message routing information, credentials, and transaction type.

• MessageInspector examines and verifies the message for data integrity and non-repudiation.

• Upon completion of security checking, PartnerMerchantService updates the back-end system with order fulfillment details.

• PartnerMerchantService sends an acknowledgement to SecureMessageRouter.

• SecureMessageRouter logs the order fulfillment events to the audit log for traceability.

• Upon completion of order fulfillment processing, SecureMessageRouter returns status to the service requester, including ControllerServlet and Client.

These are our core services. Now that we have created the sequence diagrams and fleshed out the design details, we can turn them over to the developers for implementation.