WebSphere

Security

A service-oriented architecture (SOA) allows the loose coupling of services, and therefore requires careful attention to security. This section introduces the IBM® SOA security reference model and how this relates to an enterprise service bus (ESB).

Introduction

Security is particularly important for implementations structured according to SOA principles, because of the loose coupling of services and applications. Operations can occur across trust boundaries.

When using an ESB it is important to protect business information and establish business trust relationships for identity and data. Because requests can come from external entities and cross security domains, the propagation of identity across domains is a key consideration.

An ESB gateway can manage the trust relationship between the service requester and service provider; it can also make use of numerous security services, including those responsible for:
  • Message level security.
  • Confidentiality and integrity.
  • Identity and authentication.
  • Authorization and privacy.
  • Federation of identities between requester and provider.

This section introduces some of the concepts of the IBM SOA security reference model.

Security in the SOA life cycle

Every stage in the SOA life cycle requires planning for security, as shown in the following diagram.
Figure 1. The SOA life cycle with security
The SOA life cycle with security.

The ESB can make use of various security techniques. For typical ESB end-to-end security scenarios, see: Click this link to go to the topic for WebSphere ESB. Click this link to go to the topic for WebSphere ESB for z/OS. Click this link to go to the topic for WebSphere Process Server. Click this link to go to the topic for WebSphere Process Server for z/OS.

IBM SOA security reference model

The IBM SOA security reference model provides an overview of the components of SOA security. There are three main components to the security reference model:
Figure 2. IBM SOA security reference model
The IBM SOA security reference model
  • IT security services.
    • The building blocks to provide security functions as services. The use of common IT security services enables a consistent security implementation; and reduces the cost of developing and deploying services. IT security services can be used by different components in the SOA environment. For example, gateways, proxy servers, application servers, data servers, and operating systems.
  • Security policy infrastructure.
    • How processes and services manage the behavior of the underlying infrastructure, in order to secure access to information, specify information availability and provide for audits.
  • Business security services.
    • A collection of services and capabilities required to provide a verifiably-secure deployment environment for an SOA solution.

IT security services

The IT security services are made up of the following components:
Figure 3. IT security services
The components of IT security services.
  • Identity Services.
    • Identity foundation.
      • There can be multiple user repositories. For example, there might be an enterprise user repository for identity information that is common to many applications, and individual user repositories for each of the applications. The identity of a customer can be spread across the repositories.
    • Identity provisioning.
      • Enable a policy-based approach to managing identities across user repositories. You can use a central provisioning service to create, modify, and delete identity information across user repositories.
    • Identity federation.
      • Translate secure identity information to a different format.
        • For example, a service request might contain a user name security token. An ESB mediation module could call a trust service that translates the security token to a format suitable for the service provider. The mediation module could also perform identity mapping, to translate identity and attribute information. If the incoming user name was jsmith, it might be translated to jsmith1234.
    .
  • Authentication Services.
    • Portal users can be requested to present authentication credentials as a prerequisite to service authorization. Authentication credentials include: a user name and password, hardware token, or biometrics. Authentication credentials are passed to the authentication service, which verifies the identity of the user.
  • Authorization and Privacy Services.
    • Requests must be authorized before being granted access.
      • For example, a mediation module could call an authorization and privacy service to implement service level authorization (authorization that determines who can call a service). The advantage of using the ESB is that it can perform authorization for a service provider before making any request to the service provider. There might be finer grained authorization at the application level, and further authorization at the data level (often implemented by a database).
  • Confidentiality and Integrity Services
    • Messages, data stores and systems need to be secured to prevent unauthorized access. User registries and service provider databases have to be protected, as well as the systems on which they reside.
      • The ESB provides support for the following data privacy and integrity solutions. For more information, see: Click this link to go to the topic for WebSphere ESB. Click this link to go to the topic for WebSphere ESB for z/OS. Click this link to go to the topic for WebSphere Process Server. Click this link to go to the topic for WebSphere Process Server for z/OS.
        • Point to point protection. Normally, the whole data stream is protected at the protocol level, rather than the message level. Secure Sockets Layer (SSL) is the most common example of a point to point protection scheme.
        • Message level protection. WS-Security adds support for authentication, integrity, and privacy for a single message; and is suitable for securing messages in an asynchronous environment.
  • Audit services.
    • You can create an audit event for any of your security events.
  • Non-repudiation services.
    • Non-repudiation services provide evidence that a message flow has taken place. From the point of view of the service provider, the ESB receives the initial service request, and calls the service provider. The ESB can invoke the non-repudiation services, based on the incoming request, and the service provider can access the non-repudiation services to record the message coming from the ESB. From the point of view of the service requester, the important evidence to record is that the ESB has responded to the request. Because access to the service provider is not direct, evidence for the non-repudiation record might be based on the secure channel between requester and the ESB. The service requester can create a non-repudiation record by using the audit service to record the signed data response, with a time stamp to indicate when the response was received.

Security policy infrastructure

The Security policy infrastructure is made up of the following components:
Figure 4. Security policy infrastructure
The components of security policy infrastructure.
  • Policy administration.
    • Policy administration deals with the life cycle of security policies. It can sub-divided into message protection policies and provider policies.
      • Message protection policies specify the interaction between service requesters and the ESB, and between service providers and the ESB. For example, if the ESB is expecting signed and encrypted messages from a service provider, the service provider must be aware of this so that outbound messages are correctly prepared.
      • Provider policies are policies that are internal to a particular service provider. For example, authorization policies are often used to describe the entities able to access a service.
  • Policy distribution and transformation.
    • High-level, abstract policies need to be made available to components that require the information specified in those policies. For example, a centrally-defined security policy for accessing application functions could get transformed and distributed to include the following:
      • Web services security management policy distributed to a WebSphere® DataPower® security appliance.
      • Permission set to RACF® on z/OS®.
  • Policy decision and enforcement.
    • Policy decision points can include:
      • Common audit services that evaluate their policy for the generation and distribution of audit data. For example, a central data warehouse might be used in the enterprise to store audit records collected across solution components.
    • Policy enforcement points are usually distributed across multiple components in the SOA environment. For example, an ESB can enforce policies relating to the protection of messages, based on the results of cryptographic operations for signature validation or decryption.
  • Monitoring and reporting.

concept Concept topic

Terms of use | Feedback


Timestamp icon Last updated: 20 June 2010 00:38:45 BST (DRAFT)


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wbpm.scenarios.esb1.620.doc/concepts/cwesb_security.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).
iDoc on