Security Patterns for J2EE, Web Services, Identity Management, and Service Provisioning


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:

  • Problem: Describes the security issues addressed by the pattern.

  • Forces: Describes the motivations and constraints that affect the security problem. Highlights the reasons for choosing the pattern and provides justification.

  • Solution: Describes the approach briefly and the associated mechanisms in detail.

  • Structure: Describes the basic structure of the solution using UML sequence diagrams and details the participants.

  • Strategies: Describes different ways a security pattern may be implemented and deployed.

  • Consequences: Describes the results of using the security pattern as a safeguard and control measure. It also describes the trade-offs.

  • Security Factors and Risks: Describes the factors and risks to be considered while applying the pattern.

  • Reality Checks: Describes a set of review items to identify the feasibility and practicality of the pattern.

  • Related Patterns: Lists other related patterns from the Security Patterns Catalog or from other related sources.

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.

Table 8-7. Web Tier Security Design Patterns

Pattern Name

Standards and Technologies

Description

Related Patterns

Authentication Enforcer

HTTPS; SSL/TLS; IPsec JAAS; JSSE; JCE; JGSS;

This pattern shows how a browser client should authenticate with the server. It creates a base Action class to handle authentication of HTTP requests.

Refer to Chapter 9, "Securing the Web Tier: Design Strategies and Best Practices," for details.

Context Object [CJP]; Intercepting Filter [CJP]

Authorization Enforcer

JACC JAAS; JSSE; JCE; JGSS;

This pattern creates a base Action class to handle authorization of HTTP requests.

Refer to Chapter 9 for details.

Context Object; Intercepting Filter [CJP]

Intercepting Validator

JSP Servlets

This pattern refers to secure mechanisms for validating parameters before invoking a transaction. Unchecked parameters may lead to buffer overrun, arbitrary command execution, and SQL injection attacks. The validation of application-specific parameters includes validating business data and characteristics such as data type (string, integer), format, length, range, null-value handling, and verifying for character-set, locale, patterns, context, and legal values.

Refer to Chapter 9 for details.

Message Inspector; Interceptor [POSA]

Secure Base Action

JSP; Servlets; and helper classes

The secure base action is a pattern for centralizing and coordinating security-related tasks within the Presentation Tier. It serves as the primary entry point into the Presentation Tier and should be extended, or used by a Front Controller. It coordinates use of the Authentication Enforcer, Authorization Enforcer, Secure Session Manager, Intercepting Validator, and Secure Logger to ensure cohesive security architecture throughout the Web Tier.

Refer to Chapter 9 for details.

FrontController [CJP]; Command[GoF]; Authentication Enforcer; Authorization Enforcer; Secure Logger; Intercepting Validator

Secure Logger

JMX; Java API for logging

This pattern defines how to capture the application-specific events and exceptions in a secure and reliable manner to support security auditing. It accommodates the different behavioral nature of HTTP servlets, EJBs, SOAP messages, and other middleware events.

Refer to Chapter 9 for details.

Abstract Factory Pattern[GoF]; Secure Pipe;

Secure Pipe

HTTPS; SSL/TLS; IPsec

This pattern shows how to secure the connection between the client and the server, or between servers when connecting between trading partners. In a complex distributed application environment, there will be a mixture of security requirements and constraints between clients, servers, and any intermediaries. Standardizing the connection between external parties using the same platform and security protection mechanism may not be viable.

It adds value by requiring mutual authentication and establishing confidentiality or non-repudiation between trading partners. This is particularly critical for B2B integration using Web services.

Refer to Chapter 9 for details.

Message Interceptor Gateway

Secure Service Proxy

Servlets JAX-RPC SAAJ

This pattern is intended to secure and control access to J2EE components exposed as Web services endpoints. It acts as a security proxy by providing a common interface to the underlying service provider components (for example, session EJBs, servlets, and so forth) and restricting direct access to the actual Web services provider components. The Secure Service Proxy pattern can be implemented as a Servlet or RPC handler for basic authentication of Web services components that do not use message-level security.

Refer to Chapter 9 for details.

Proxy [GoF] Intercepting Web Agent; Secure Message Router; Message Interceptor Gateway; Extract Adapter [Kerievsky]

Secure Session Manager

Servlets EJB

This pattern defines how to create a secure session by capturing session information. Use this in conjunction with Secure Pipe. This pattern describes the actions required to build a secure session between the client and the server, or between the servers. It includes the creation of session information in the HTTP or stateful EJB sessions and how to protect the sensitive business transaction information during the session.

The Session pattern is different from the Secure Session Manager pattern in that the former is generic for creating HTTP session information. The latter is much broader in scope and covers EJB sessions as well as server-to-server session information.

Context Object [CJP]

Intercepting Web Agent

Web server plug-in

This pattern helps protect Web applications through a Web Agent that intercepts requests at the Web Server and provides authentication, authorization, encryption, and auditing capabilities.

Refer to Chapter 9 for details.

Proxy [GoF]


Business Tier Security Patterns

Table 8-8 shows a list of security patterns that are available in the Business Tier.

Table 8-8. Business Tier Security Design Patterns

Pattern Name

Standards and Technologies

Description

Related Patterns

Audit Interceptor

Java API for Logging

The Secure Logger pattern provides instrumentation of the logging aspects in the front, and the Audit Interceptor pattern enables the administration and manages the logging and audit in the back-end.

Refer to Chapter 10, "Securing the Business TierDesign Strategies and Best Practices," for details.

Secure Logger Intercepting Filter [CJP]

Container Managed Security

EJB

This pattern describes how to declare security-related information for EJBs in a deployment descriptor.

Refer to Chapter 10 for details.

Secure Pipe

Dynamic Service Management

JMX

This pattern provides dynamically adjustable instrumentation of security components for monitoring and active management of business objects.

Refer to Chapter 10 for details.

Secure Pipe; Secure Message Router

Obfuscated Transfer Object

JCE

This pattern describes ways of protecting business data represented in transfer objects and passed within and between logical tiers.

Refer to Chapter 10 for details.

Transfer Object [CJP];

Policy Delegate

JACC
EJB
XACML

This pattern creates, manages, and administers security management policies governing how EJB tier objects are accessed and routed.

Refer to Chapter 10 for details.

Secure Base Action; Business Delegate [CJP]

Secure Service Façade

EJB

This pattern provides a session façade that can contain and centralize complex interactions between business components under a secure session. It provides dynamic and declarative security to back-end business objects in the service façade. It shields off foreign entities from performing illegal or unauthorized service invocation directly under a secure session.

Session information can be also captured and tracked in conjunction with the Secure Logger pattern.

Refer to Chapter 10 for details.

Secure Service Proxy; Session Façade [CJP]

Secure Session Object

EJB

This pattern defines ways to secure session information in EJBs facilitating distributed access and seamless propagation of security context.

Refer to Chapter 10 for details.

Transfer Object [CJP]; Session Façade[CJP]


Web Services Tier Security Patterns

Table 8-9 shows a list of security patterns that are available in the Web Services Tier.

Table 8-9. Web Services Tier Security Design Patterns

Pattern Name

Standards and Technologies

Description

Related Patterns

Message Inspector

XML Encryption; XML Signature; SAAJ; JAX-RPC; WS-Security; SAML; XKMS;

This pattern checks for and verifies the quality of XML message-level security mechanisms, such as XML Signature and XML Encryption in conjunction with a security token. The Message Inspector pattern also helps in verifying and validating applied security mechanisms in a SOAP message when processed by multiple intermediaries (actors). It supports a variety of signature formats and encryption technologies used by these intermediaries.

Refer to Chapter 11, "Securing Web ServicesDesign Strategies and Best Practices," for details.

Message Interceptor Gateway, Secure Message Router

Message Interceptor Gateway

JAX-RPC; SAAJ; WS-Security XML Signature; XML Encryption; SAML XACML WS-*

This pattern provides a single entry point and allows centralization of security enforcement for incoming and outgoing messages. The security tasks include creating, modifying, and administering security policies for sending and receiving SOAP messages. It helps to apply transport-level and message-level security mechanisms required for securely communicating with a Web services endpoint.

Refer to Chapter 11 for details.

Secure Access Point, Message Inspector, Secure Message Router

Secure Message Router

WSS-SMS XML Signature XML Encryption WS-Security Liberty Alliance SAML XKMS

This pattern facilitates secure XML communication with multiple partner endpoints that adopt message-level security and identity-federation mechanisms. It acts as a security intermediary component that applies message-level security mechanisms to deliver messages to multiple recipients where the intended recipient would be able to access only the required portion of the message and remaining message fragments are made confidential.

Refer to Chapter 11 for details.

Secure Access Point, Message Inspector, Message Interceptor Gateway


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.

Table 8-10. Security Patterns for Identity Tier and Service Provisioning

Pattern Name

Standards and Technologies

Description

Related Patterns

Assertion Builder

SAML; Liberty Alliance

This pattern defines how an identity assertion (for example, authentication assertion or authorization assertion) can be built.

Refer to Chapter 12, "Securing the IdentityDesign Strategies and Best Practices," for details.

 

Credential Tokenizer

SAML; Liberty Alliance

This pattern describes how a principal's security token can be encapsulated, embedded in a SOAP message, routed, and processed.

Refer to Chapter 12 for details.

 

Single Sign-on (SSO) Delegator

SAML; Liberty Alliance

This pattern describes how to construct a delegator agent for handling a legacy system for single sign-on (SSO).

Refer to Chapter 12 for details.

 

Password Synchronizer

SPML

This pattern describes how to securely synchronize principals across multiple applications using service provisioning.

Refer to Chapter 13, "Secure Service ProvisioningDesign Strategies and Best Practices," for details.

 


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:

1.

Identify the required security features based on the functional and non-functional requirements and organizational policies (Security Use Cases).

2.

Create a conceptual security model based on architecturally significant use cases (Candidate Architecture).

3.

Perform risk analysis and mitigate risks by applying security patterns (Risk Analysis).

4.

Perform trade-off analysis to justify architectural decisions (Trade-off Analysis).

5.

Identify the security factors for each component or service specific to the application or system infrastructure (Factor Analysis).

6.

Review the factors that impact the security of applications or Web services elements under each logical architecture tier (Tier Analysis).

7.

Define the object relationship for security protection and identify the associated trust models or security policies (Trust Model).

8.

Identify any security risks or threats that are specific to the use case requirements (Threat Profiling).

9.

Formulate a security policy (Security Policy Design).

10.

Apply security patterns wherever appropriate. Sometimes, rearchitecting or reengineering may be required (Security Pattern Design, Security Pattern Catalog, Apply Security Pattern).

11.

Prior to implementation, use Security Reality Checks to review and assess the security levels by logical architecture tiers (Security Reality Check).

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
  • Target deployment platform (and the underlying technologies and implementation constraints)

  • Number or type of access points or intermediaries

  • Service provider infrastructure (centralized, decentralized, distributed, or peer-to-peer), and the associated constraints of connecting to the infrastructure (for example, the data transport security requirement)

  • Network security requirements

Web Tier
  • Authentication-specific requirements (for example, multifactor authentication mechanism)

  • Client devices or platform used (for example, Java card, Biometrics)

  • Key management strategy (for example, whether key pairs are generated by a Certificate Authority and how the key pairs are stored)

  • Authorization-specific requirements based on the sensitivity of the access requests.

Business Tier
  • Nature of the business transaction (for example, non-sensitive information has a lower security protection requirement than sensitive, high-value financial transactions).

Web Services Tier
  • Service invocation methods (RPC-style, document-style, synchronous, or asynchronous communication).

  • Service aggregation requirements (for example, whether business services need to be intercepted, filtered, or aggregated from multiple service providers).

Identity Tier
  • Identity management strategy (for example, how network identity is established, validated, and managed).

  • Policy management strategy (for example, management policies for who can access the SOAP messages and whether the service requester can access the full or partial content).

  • Legacy security integration constraints (for example, security credential propagation).

  • Single sign-on and sign-out requirements.

Quality of Services
  • Service-level requirements (for example, quality-of-services requirements for high availability, performance, and response time).

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:

  • Secure the transport layer (Secure Pipe pattern, Secure Message Router pattern).

  • Validate the SOAP message for standards compliance, content-level threats, malicious payload, and attachments (Message Interceptor Gateway pattern, Message Inspector pattern).

  • Validate the message at the element level and the requesting identity (Message Inspector pattern).

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

  • Protect the exposed business services and resources by service masking (Secure Service Proxy pattern).

  • Protect the service requests from untrusted hosts, XML DoS, Message replay, Message tampering (Message Interceptor Gateway pattern).

  • Timestamping all service requests (Secure Message Router pattern).

  • Log and audit all service requests and responses (Secure Logger and Audit Interceptor pattern).

  • Route requesting to multiple service endpoints by applying message-level security and Liberty SSO mechanisms (Secure Message Router pattern).

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:

  • Actual or attempted unauthorized access

  • Introduction of viruses, Trojan horses, and malicious code

  • Actual or attempted unauthorized probing of content

  • Denial of service attacks

  • Arbitrary code execution

  • Unauthorized alteration and deletion of data

  • Unauthorized access

  • Unauthorized disclosure

  • Unauthorized privilege escalation

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 identifies specific mechanisms meant for responding to a specific threat profile, where a threat profile is a set of threats or vulnerabilities identified through a set of security use cases.

  • A trust model facilitates implicit or explicit validation of an entity's identity or the characteristics necessary for a particular event or transaction.

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:

  • Identity policies: Define the rules and conditions for verifying and validating the requesting entity's credentials. These include usage of username/passwords, digital certificates, smart cards, biometric samples, SAML assertions, and so forth. This policy is enforced during authentication, authorization, and re-verification requirements of an identity requesting access to an application.

  • Access control policies: Define the rules and conditions applied to a requesting entity for accessing a resource or executing operations exposed by an application or service. The requesting entity can be a user, device, or another application resource. The access control policies are expressed as rights and privileges corresponding to the identity roles and responsibilities of the requesting entity.

  • Content-specific policies: Define the rules and conditions for securing the content during communication or storage. This policy enforces the content-specific privacy and confidentiality requirements of an application or service.

  • Network and Infrastructure policies: Define the rules and conditions for controlling the data flow and deployment of network and hosting infrastructure services for private or public access. This helps to protect the network and hosting infrastructure services from external threats and vulnerabilities.

  • Regulatory policies: Define the rules and conditions an application or service must adhere to in order to meet compliance, regulation, and other legal requirements. These policies typically apply specifically to financial, health, and government institutions (for example, the SOX, GLBA, HIPAA, and Patriot Act).

  • Advisory and informative policies: These rules and conditions are not mandated but they are strongly suggested with respect to an organization or to business rules. For example, these policies can be applied to inform an organizational management team about service agreements with external partners for accessing sensitive data and resources, or to establish business communication.

In addition, in some cases we need to design and apply target application environment and business-specific policies such as:

  • 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 audit and traceability policy

  • Password selection and maintenance policy

  • Information classification and labeling policy

  • DMZ Environment access policy

  • Application administration policy

  • Remote access policy

  • Host and network administration policy

  • Application failure notice policy

  • Service continuity and recovery policy

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.

  1. Unclassified: The data or process represented with this classification is neither sensitive nor classified. The information is meant for public release and the disclosure does not violate confidentiality.

  2. Sensitive But Unclassified (SBU): The data or process represented with this classification may contain sensitive information but the consequences of disclosure do not cause any damage. Public access to this data or processes must be prevented. For example: General health care information such as medications, disease status, etc.

  3. Confidential: The data or process in this classification must be protected within the organization and also from external access. Any disclosure of this information could affect operations and cause significant losses. For example: Loss of customer credit card information from a business data center.

  4. Secret: The data or process in this classification must be considered as secret and highly protected. Any unauthorized access may cause significant damage. For example: Loss of strategic military information.

  5. Top Secret: The data or process in this classification must be considered as highest secret. Any unauthorized disclosure will cause grave damage. For example: A country's national security information.

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.

Table 8-11. Simple Assessment Checklist for Application Security Architecture

Security Service

Security Mechanism

Suggested

Current

Future

Authentication

Username and password

 

Client-certificate

Yes

Authorization & Access Control

Group grants

Yes

Role grants

 

Yes

Delegation

 

Yes

Access control lists

  

Policy objects

  

Rules

  

Secret Key

RSA

1024-bit

Yes

Public Key

RSA - MD5

1024-bit

Yes

RSA - SHA-1

1024-bit

Yes

Audit logs

 

Accountability

Centralized audit log

  

Encrypted checksums on log records

   

Encrypted log records

   

Digital signature (non-repudiation)

   





Core Security Patterns. Best Practices and Strategies for J2EE, Web Services, and Identity Management
Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management
ISBN: 0131463071
EAN: 2147483647
Year: 2005
Pages: 204

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net