Use Case Scenarios

The following sections briefly discuss the business and security requirements of the eRewards portal followed by some detailed use cases represented by UML diagrams. We could devote a whole chapter to the requirements gathering processes and the creation of the architecture based on risk analysis, but because this book is focused more on security patterns, we have abbreviated the business requirements to highlight the importance of security in the portal.

Using use cases to analyze business requirements can help reduce the difficulty of building the application architecture and can help us to identify the required security features. Because the case study focuses on applying end-to-end security design techniques in different tiers, it will use a "micro-architecture" approach [CJP2], using appropriate security design patterns that were discussed in earlier chapters to illustrate the security design best practices (instead of the J2EE application design itself).

Choosing the Right Methodology

To get started on our eRewards portal case study, we must first identify a process methodology that gets us through the software development life cycle and meets both the business and security goals we set forth earlier. To accomplish our goals and to meet our deadlines while delivering a secure system, we chose to use the Secure UP as described in Chapter 8, "The Alchemy of Security Design: Methodology, Patterns, and Reality Checks." Doing so allows us to take advantage of the leading industry-recognized software development process and to extend it in order to ensure that our nonfunctional goals of security, reliability, and management are met.

Referring to the activity diagram (Figure 8-3) in Chapter 8, "The Alchemy of Security DesignMethodology, Patterns, and Reality Checks," we see that our first activity is to have a business analyst who defines the business and security requirements. Creating this definition is part of the business modeling and security requirements disciplines.

Identifying the Requirements

Let's assume that our business analysts have met with the business owners and derived the requirements for our eRewards portal. These would be broken out into business requirements and nonfunctional requirements, such as security, manageability, reliability, performance, high availability, and so forth. These functional and nonfunctional requirements are grouped into related sets of use cases for development and are tracked using a requirements management tool (for example, DOORS, RequisitePro, or another tool).

At a high level, the eRewards portal should be able to allow user self-registration by way of using a trusted Identity Provider. Upon successful registration, the portal subscribers (also referred to as users) can check their current account information, including their membership award point balance and the history of transactions. They can also update their personal information or access membership services. The portal also provides a selected list of merchandise for membership award redemption. It delivers an online product catalog system from a service provider hosted by the online portal. Subscribers can redeem merchandise by browsing the online product catalog, selecting the catalog product items, and placing the order in the online shopping cart. The internal order management system will fetch product details from the shopping cart and the corresponding item price by product ID and then retrieve the membership award status to see if the subscriber has sufficient membership award points to redeem for the merchandise. In the future, the eRewards portal will also allow the subscriber to purchase merchandise by credit card if the subscriber does not have enough membership award points for redemption.

The majority of the merchandise is supplied by trading partners by way of specialized merchant services. The eRewards online catalog maintains merchandise information and product details by taking a nightly offline data feed from the external trading partners. Fulfilling an order will require sending the delivery order from the internal order management system to the external systems of the trading partners. The order management system will send the subscriber's name, delivery address, and the merchandise details electronically in a secure manner. The order fulfillment system will also track the delivery status of the shipment.

Because the eRewards portal is intended to be available to subscribers around the clock, it has a high-availability service-level requirement of 99.99%. This suggests that the application servers running both the membership service and the merchant service should be almost "non-stop." Designing around merchant services operated by external trading partners (service providers) can be challenging, because the online portal does not have direct control over their availability. As an interim measure, the online portal requires notification of service exceptions if the external merchant service is not available. However, there is currently no service-level agreement (SLA) between the external trading partners and the eRewards portal about availability or the turnaround time for any service notification.

Identifying the Security Requirements

As mentioned earlier, we are focusing only on the security requirements of the portalnot the other nonfunctional requirements. End-to-end security is essential for the eRewards portal because security risks or threats do not come from a single source. Securing the Web server for the eRewards portal does not necessarily mean that the entire portal is secure. This is because business functions for membership services and merchant services do not come from a single server; they are distributed in different servers and different security domains. Each security domain has different fabrics or substrates of security elements that require specific security design considerations or security risk mitigation measures. A monolithic security model of using HTTPS or using traditional host security-hardening techniques will not be sufficient to handle a mixture of J2EE applications and Web services.

Security should never be an afterthought whose importance goes unnoticed until something unpleasant happens or a security loophole is reported. Security requirements are the key drivers for the reliability and availability of the business services provided by the online portal. These include authentication, authorization, traceability, data privacy or confidentiality, availability, data integrity, and non-repudiation.

The business-level security requirements gathered for the eRewards portal also include the following:

• Identity Protection. The Identity Provider infrastructure should be able to provide access management for authentication of valid subscribers to the portal. The Identity protection entails a variety of key management security protection mechanisms or risk mitigations that both secure the storage of key pairs (for example, the use of the Hardware Security Module (HSM) or a smart card device to store the private and public keys) and authenticate user identity (for example, the use of strong user authentication mechanisms such as smart cards, biometrics devices, or dynamic passwords) in a secure manner. Thus, the portal should be able to both accommodate various strong user authentication mechanisms on an as-needed basis and support key management operations for securing identity information.

• Securing Web Servers and Application Servers. The portal should provide security for the infrastructure hosting the Web servers and application servers. The hosting server infrastructure must make use of a trustworthy operating system and other required services.

• Secure Client-to-Server Connection. The portal should be able to secure the session and business data exchanged between the client and the server, using HTTP/SSL transport, for example. It should also make sure that the client is authenticated before establishing the user session.

• Secure Server-to-Server Connection. The portal should be able to secure the session and the business data exchanged with the service providers. Invoking Web services from external trading partners requires routing XML messages across different intermediaries or multiple processing nodes. Each external intermediary or trading partner node processing the business transaction or participating in the workflow should be secure. However, hosting servers should be able to authenticate each server before establishing the business data exchange.

• Secure Transactions. The portal should be able to support data privacy and confidentiality by securing the business transactions with encryption. Business transactions should be logged for traceability and audit control.

• Message Level Protection. Web services XML messages over a public network in clear text can be easily intercepted and tampered with. The XML messaging should make use of encryption and signature mechanisms that protect the data exchanged between the processing nodes. The message-level protection must ensure data integrity and non-repudiation of all business transactions.

• Single Sign-on. The portal should be able to provide single sign-on to merchant services hosted by external trading partners. Thus, subscribers can provide user credentials to log in once, and they can then access both membership services and merchant services without re-login multiple times. In addition to single sign-on, the portal must facilitate a common mechanism for identity registration, revocation, and termination.

• Security Considerations for High Availability. No matter how secure and sophisticated the application infrastructure is, a DoS attack can cripple the online portal by making it unavailable for services. Thus, the portal should adopt appropriate preventive (such as load balancing, packet filtering, virus checking, failover, or backup) and service continuity measures that can defend against DoS attacks or other potential security breaches.

• Security Risk Mitigation. There should be a plan for identifying different security threats and the associated risk mitigation. Based on the security threat analysis, security architects can determine if additional security mitigation measures are necessary to cover any gaps in the security requirements or design elements.

• Service Continuity and Recovery. There should be an infrastructure plan that ensures the capability of delivering the services in the event of a security breach or human error. If such an event occurs, the Web portal infrastructure must have a recovery strategy for the worst-case scenario and must provide mechanisms for recovery from the event. Such mechanisms may even stop the event from occurring in the first place.

System Constraints

Based on our requirements, there are system constraints that may impact the security design. One main constraint is the identity management infrastructure. The eRewards portal has a previous investment in an identity management vendor solution and currently uses a trusted external Identity Provider. Thus, there will be no need to build or customize any single sign-on security solution.

Many Web services in the portal are created by exposing home-grown J2EE, .NET, and legacy applications as Web services. There may be no security built into these home-grown or legacy applications. Thus, there should be separate security considerations made for them during the design process.

Security Use Cases

Use cases are the end artifact of the requirements discipline. The use cases address one or more business requirements, defining the details of how those requirements must be implemented. Once a use case is complete, analysis and design for that functionality can begin. The following section presents some of the security use cases relevant to our eRewards portal case study. These use cases serve as the basis for defining the security design for our portal scenario. Typically, each use case would be defined in one or more documents, using a standard template. For our present purposes, we will skip an elaborate template and briefly summarize, using a use case diagram.

Use Case Diagram

Based on our business requirements, we have constructed our security use case diagram as shown in Figure 14-2.

Figure 14-2. Security use cases for the eRewards portal

In Figure 14-2, Client, a subscriber to the eRewards portal (OnlinePortal), needs to initiate and obtain secure login access to the portal. Upon successful authentication and authorization from the Identity Provider, Client can select different business services available from the portal. In this case study, Client intends to redeem merchandise (gifts offered by the portal and/or their affiliated merchants) using his or her membership award points. First, Client browses through the online catalog and selects the merchandise. Upon confirmation of his or her merchandise selection, Client chooses to redeem the merchandise by deducting membership award points from the available membership award balance. The portal retrieves the membership award balance and determines whether Client is eligible to redeem the merchandise. If Client is eligible to redeem the merchandise, the portal will place an order with the supplier merchant (TradingPartner) and issue an order to fulfill the order according to the pre-registered home address of the subscriber (Client).

In this scenario, we primarily focus on the security-related use cases such as User login, Secure Catalog service, Secure order placement, and Secure order fulfillment.

• The User login use case refers to the user authentication process using an external Identity Provider.

• The Secure catalog service use case refers to the security mechanisms used to secure the catalog service. The portal catalog service component accesses a Web service provided by a partner service provider. Secure catalog service requires that the invocation of remote Web services is secure and that there is fully capable traceability that ensures there has been no unauthorized access to the catalog service and that supports audit trail or compliance reporting. Additionally, Client should not need to re-login to the catalog service, even though this is a remote Web service.

• The Secure order placement use case refers to the security mechanisms used to secure the order management process. The order management back-office function is currently implemented in J2EE. The J2EE component requires that the Client be authorized to invoke the order management functions. It is also necessary that this should reuse the logging infrastructure for traceability.

• The Secure order fulfillment use case refers to the security mechanisms used to secure the order fulfillment process. The order fulfillment is done by integrating external trading partners (TradingPartner) using document-style Web services. It is extremely important to authenticate with the external trading partners before routing XML messages in the Web Services tier. To address the risk of message interception or tampering, the XML messages should be secured by data encryption and digital signature for data integrity and confidentiality purposes.

Actors

The following Actors are the key entities that interact with the security use cases such as secure catalog service and secure order fulfillment. Here is a short description of each of the Actors:

Client	The subscriber to the online portal.
Online Portal	Also referred to as eRewards portal, a Web portal application that provides personalized access and a point of entry to multiple business services.
Trading Partner	A service provider organization that provides a business service to the service requester (Client).

eRewards PortalLogical View

Based on the use cases, let's take a look now at what we have as a conceptual model of our Web-based business portal. Figure 14-3 illustrates the logical representation of the Web-based business portal.

Figure 14-3. Logical View of eRewards portal

In Figure 14-4, we see our three main services in the portal. They connect to the merchant service at our trading partner and use an external Identity Provider for identity management. All of the transactional data is stored in our warehouse database.

Figure 14-4. eRewards portal: high-level application architecture

System Environment

We assume the eRewards portal and the service providers work together as a medium-scale business application hosted using heterogeneous platforms including Solaris, Linux, and Microsoft Windows. The portal runs on a J2EE 1.4-compliant application server that also provides support for RPC and document-style Web services. No vendor-specific application server extension features will be used. The portal and the underlying service providers make use of an external trusted Identity Provider for authentication, authorization, single sign-on, and identity management services.