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.
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
- 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
- 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:
- 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
- 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.