Overview

The case study analyzes a Web-based business application portal that hosts a set of merchant services from multiple business provider sources and provides member rewards redemption services. Figure 14-1 shows the conceptual representation of the Web-based business portal (eRewards). In a typical scenario, a subscriber logs in to the Web-based business portal to check his or her membership award balance and then submits a request to an affiliate content provider (a trading partner of the service provider) to redeem points and obtain a gift.

Figure 14-1. Conceptual model of the Web-based business portal (eRewards)

The portal permits access to users from Web browsers accessible via Internet or intranet-based enterprise applications from trusted business corporations. To verify user identity, the portal relies on an external Identity Provider that provides user authentication functionality. Thus, the portal does not need to invest resources into the building of its own identity management infrastructure.

The eRewards Membership Service stores personal subscriber information and preferences in user profiles. It also keeps an account balance of the membership award points and tracks any redemption for merchandise. The eRewards Catalog Service provides a list of merchandise offered to subscribers in the Warehouse Database. Subscribers can browse through the catalog of merchandise, select specific items, and add them to the in-basket for membership award redemption. Upon user confirmation, the eRewards Order Management Service will process the order that was placed in the in-basket. It will verify the membership award account balance to see if the subscriber has sufficient points to redeem the merchandise. Eligible merchandise information will be forwarded to the affiliate trading partners for order fulfillment via the Merchant Service.

The eRewards portal adopts J2EE technology to build business applications. Both the Catalog Service and the Order Management Service are implemented using Java-based Web services technologies. The integration with external partners will be done by way of XML Web services. The trading partners use Web services to enable interoperability and to overcome integration issues related to platforms and technologies, such as C++ and Microsoft-based applications.

Understanding the Security Challenges

The security challenges surrounding the Web portal lie in the complexity of security requirements and in establishing a unified security model between J2EE applications and Web services. The J2EE security model defines transport-level security using HTTPS and role-based access control to protect the business data exchanged and the business components. In a Web portal scenario, this security model is not adequate, because the security does not guarantee the security of the processes or the business data outside of the HTTPS session and user-based access control. This issue is even more complex when Web applications are distributed across different machines and there are many server-to-server processes. Thus designing end-to-end security for the eRewards portal is not trivial. A rigorous process that uses a well-defined methodology must be followed. This process includes gathering high-level requirements, implementing and testing the code, production deployment, and its final retirement. There are also other environment- and user-specific security factors that need to be considered and incorporated into the end-to-end security design. For example, each logical tier has its own associated risk in terms of development, deployment, and production. For example, there are risks involved in configuring the Web server plug-in to support the application server, building a custom login module to adopt a security provider, and in implementing the logging for capturing events and supporting security audit. Compliance and regulatory requirements such as the Sarbanes-Oxley Act, GLB Act, EU directives, and Patriot Act also define and add various security requirements in terms of auditing business transactions. In addition, they mandate traceability of business transactions for the detection of any suspicious activities or potential security threats. Refer to Chapters 9 and 10 [CSP] for details.

More importantly, security considerations differ widely from application to application. For example, Web services using SOAP messaging have security risks that are very different than those faced by a traditional Web application. The fact that SOAP messaging is language- and platform-neutral also makes it difficult to generalize security protection mechanisms or to implement generic security protection mechanisms that work on all platforms. Safeguarding synchronous or asynchronous Web services usually requires using Security tokens, XML signatures, XML Encryption, and enforcing access control for sensitive data in the SOAP messages. Security also becomes more complicated if the SOAP messages are routed to multiple intermediaries in a workflow or among external trading partners, where each of the nodes or servers exposes different levels of security risks and exposures. Refer to Chapters 6, "Web Services SecurityStandards and Technologies," and Chapter 11, "Securing Web ServicesDesign Strategies and Best Practices," for details about Web services security and related patterns.

Exchanging identity credentials across security domains adds security risks and complexity in business communication among service providers. The services must also facilitate unified sign-on, global logout, and common mechanisms for identity registration, revocation, and termination. In addition to that, the identity infrastructure must protect the identity information against identity theft, spoofing, and man-in-the-middle attacks. Refer to Chapters 7, "Identity ManagementStandards and Technologies," and Chapter 12, "Securing the IdentityDesign Strategies and Best Practices," for details about identity management and related patterns.

Assumptions

First, we need to make some assumptions about our choice of platforms, client and server infrastructure options, and communication protocols in order to set the boundaries and constraints to the business application system environment. We also need to provide some context for the security requirements before we proceed with the case study. These requirements include:

• The eRewards online portal is accessible from a Web browser.

• We will address all business functionalities of the eRewards portal using J2EE platform-based application components.

• We will use synchronous and asynchronous protocols for invoking Web services via RPC and document-style Web services, respectively. Using Web services provides a standard interface for exposing business services previously implemented in Java (or .NET). The eRewards online portal has made prior arrangements with its trading partners by exchanging WSDL and XML schemas for representing the XML-based business document and by agreeing on the business data semantics. For external SOAP messaging, both the eRewards online portaland its back-end integration with all trading partnersagree to sign and encrypt the XML messages.

• The identity management solution is provided by a third-party Identity Provider using a standards-based infrastructure using standards such as Liberty Alliance and SAML. This enables us to provide single sign-on access with different security domains over the Internet.

• User authentication is performed by a trusted Liberty-enabled security provider infrastructure that supports form-based authentication for J2EE over HTTPS as well as SSL client certificates (assuming that they were previously distributed via the eRewards online portal during the initial user or partner registration).