| Figure 14-4 depicts the high-level application architecture for the eRewards portal. Because the focus of this case study is on building end-to-end security for the portal, we will not rationalize the details of how all the elements of the application architecture are derived. In a nutshell, the portal runs a J2EE 1.4-compliant application server using servlets and EJB components. The servlets make use of JAX-RPC or SAAJ handlers to invoke Web services provided by the service providers or external partners. The portal makes use of EJBs for processing orders. For identity management, the portal and the external trading partners have established a trusted relationship with service providers, making use of an external Liberty-enabled Identity Provider for user authentication, authorization, single sign-on, and identity management services. All server components of the portal and the service providers make use of a Liberty-enabled agent to communicate with the Identity Provider. Technology Elements The application architecture is represented using the following technology elements: Servlets are server-side MVC-style components that handle user presentation and control. EJBs are server-side components that encapsulate business logic to manipulate service requests, handle transaction processing, and retrieve or store business data in the database. JAX-RPC and SAAJ handlers integrate with service providers via XML Web services. Java Data Objects are an implementation of data access objects that retrieve or store business data in the database using JDBC connectivity.
Security Prerequisites Based on the application architecture, we need to define the following security prerequisites that will help us derive a conceptual security model. Network perimeter security has historically been a critical requirement in any security architecture. This layer has been the most commonly attacked. Practices such as using a multi-tier firewall for the DMZ, NAT-ed proxies, and packet filters all fit into the security architecture. Application infrastructure security represents safeguards and countermeasures for ensuring the security of enterprise applications, LDAP, and the database. Practices such as using HTTP/SSL to communicate with the application; limiting access to the application via authentication; and enabling role-based access control, digital signatures, and data encryption during transit must be addressed. Using a Web services-based infrastructure for integration with service providers and exchanging XML messages introduces a newer set of security challenges both at the message and communication layers. Adopting XML-based security mechanisms for message-level security and SSL/TLS for transport-level security must be considered. Identity protection is a key issue when securing applications and exchanging business data across multiple security domains and between trading partners. It becomes more complex when exchanging authentication and authorization information. Adopting single sign-on, global logout, common identity registration, revocation, and termination mechanisms must be considered using an external Identity Provider that establishes a chain of trust among all participating service providers. Host security is another crucial requirement. Adopting a trusted or hardened OS, applying the appropriate patches, and installing an intrusion detection system are the key factors to consider to ensure that the host environment is secured.
Conceptual Security Model We have enough information at this point to create a conceptual security model identifying the key security features that contribute to the end-to-end security of the eRewards portal. Creating a conceptual security model also entails defining some high-level components and technologies to fulfill our business security requirements. The following decisions here will help drive the design but are not set in stone, because there are several analyses yet to be performed. The major pieces of the conceptual model are: Protecting the Identity Information. The Identity Provider should be able to authenticate valid subscribers to the eRewards portal. Using PKI for protecting the identity information during transit and storage and using digital certificates for representing the identity is often considered as a recommended practice. Identity protection also entails secure storage of key pairs (for example, the use of Hardware Security Module (HSM) or a smart card device to store the private keys) and physical access control mechanisms such as biometric technologies. Thus, the portal should be able to provide support for different identity protection mechanisms and for adopting stronger authentication mechanisms. Securing Web Servers and Application Servers. Web servers and application servers may be the primary targets for security attacks or hacking. The portal should adopt and run on a hardened OS in the host application environment. A hardened OS ensures that all irrelevant and unused services that may be targets of threats are removed from the host environment. In addition, the Web servers and application servers must be securely deployed, with all default password configurations and sample applications completely removed. Secure Client-to-Server Connection. The portal should be able to secure the session and business data exchanged between the user client and the server by way of HTTP over SSL transport. Adopting a mutual authentication between the client and server before establishing the user session is recommended. Secure Server-to-Server Connection. The portal should be able to secure the Web services communication exchanged between the service providers. Establishing secure communication with external trading partners requires secure routing of XML messages. It is important to verify that the Web portal ensures transport-level data integrity and confidentiality during communication with service providers and other participating intermediaries. 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 should audit properly, but sensitive data should be obfuscated in the logging. Securing Messages. To communicate with service providers, the portal should adopt XML Web services using SOAP messages over HTTP/SSL. Although SSL ensures transport-level security, it does not facilitate message-level security that ensures that the message is received by only the intended recipient. Using message-level protection mechanisms such XML Signature and XML Encryption ensures message-level confidentiality and integrity during the Web services communication and also at the processing endpoints. This protection provides non-repudiation and trustworthy communication between the Web portal and the service providers. 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 login once and can access both membership services and merchant services without having to login multiple times. Secure Logging and Auditing. The portal must provide a full-fledged logging mechanism that captures and records all events with the corresponding identity as auditable trails. In addition to logging, the Web portal should provide an auditing mechanism to play back the recorded trails for forensic investigation. Security Considerations for High Availability, Service Continuity, and Recovery. No matter how secure and sophisticated the application infrastructure is, a denial-of-service attack can cripple the Web portal by making the portal offline and unavailable. Thus, the Web portal should adopt appropriate preventive measures (such as load balancing, fault-tolerance, failover recovery, and session persistence) that can help defend against a security breach and ensure further service continuity without disrupting legitimate user requests. 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. A cost/benefit analysis can then determine the legitimacy of the mitigation strategy.
|
