Securing access to information is basic to any application. Security becomes even more critical for implementations structured according to SOA principles due to their loose coupling of services and applications and their operation across organizational boundaries. Such an environment often exposes the delicacy or limitations of existing security implementations.

Irrespective of the efficiencies brought by model-driven development and SOA-based service management, business applications must continue to secure information. Merely securing the perimeter (such as firewalls and routers) is insufficient, because an On Demand Business needs to be able to set up and tear down dynamic trust relationships as relationships among its partners, customers, and employees evolve. Thus, a secure On Demand Business needs a flexible, customizable infrastructure so it can adapt to new requirements and regulations. To provide such flexibility, it should not hardwire policie into the infrastructure; it should implement the requirements of the security model through a policy-driven infrastructure - no simple task.

This article explains how business applications can leverage the security capabilities of an on demand security infrastructure and the design principles that give rise to a programming model for securing service-oriented applications. Business applications and security infrastructureSecure integration and access to business applications and information is typically achieved through authentication, authorization, and accountability. How a business approaches the management of authentication, authorization, and accountability is dictated largely by its view of the trust relationships that exist among customers, employees, and partners; the effects these relationships have on the security of business applications; and the relative importance and security of these applications.

When sensitive information is exchanged between business partners, it must be secured. It may also need to be persisted in a secure manner. The integrity of the message origin needs to be guaranteed (for example, through notary services) to enable validation, auditing, and nonrepudiation when necessary. Sensitive information may need to be encrypted for confidentiality or digitally signed for integrity. (Digital signatures also play a role in nonrepudiation.) A complete SOA security design must address not only message- and transport-level security, but the need to secure persisted content to comply with government regulations and industry best practices.

Fundamentally, the trust relationships among a business and its employees, customers, and partners govern the definition and enforcement of security policies and the level of security that is enforced. Relevant technologies, such as certificates and cryptographic keys, can be used to reflect and manage these trust relationships. Tools can be used to model and specify trust relationships between business partners, between consumers and the business, and so on, and can translate trust definitions into technologies that are appropriate for the IT environment. SOA security modelThe SOA security model is based on a process in which a Web service can require an incoming message to prove a set of claims. Examples of claims include name, key, permission, and capability. Based on the proof provided, the appropriate trust models are applied between the requester, the service endpoint, and a set of possible intermediaries.

A message may traverse several intermediaries between a requester and a target service. The management of end-to-end security must take into account the trust models between the requester, the intermediary, and the ultimate endpoint service (provider), as illustrated in Figure 1.

The OASIS Web Services Security (WSS) specification provides protection for Simple Object Access Protocol (SOAP) messages in transit. You can use WSS to protect the authenticity, integrity, and confidentiality of messages from untrusted network and transport intermediaries.

Not all intermediaries are untrusted. A Web services gateway and an enterprise service bus mediation service are examples of message transformation intermediaries whose function in the SOA involves inspection and, in some cases, modification of message payloads [see Part 4 in this series, "An introduction to the IBM Enterprise Service Bus" (developerworks, 2005)]. When designing your SOA security infrastructure, consider planning to allow certain trusted intermediaries.

Another trusted intermediary might be a message broker that handles trust relationships between requesters and an application service host. In this design, security responsibilities are divided between the broker and the service endpoint. As shown in Figure 2, the message intermediary would be responsible for message-level security, federation of identities between requester and provider environments, and managing the trust relationship between the requester and service provider. The service would retain responsibility only for meeting service-specific security requirements, such as establishing (mapped, federated by the intermediary) identity to access the service, integrity, and confidentiality of application-specific data in the message payloads. By factoring fragile or complex infrastructure code out of the business application and delegating it to the container, an SOA-based approach to security can improve flexibility and reduce the possibility of mishaps.

Message security
The WSS specification also provides a set of basic message-level mechanisms for integrity, confidentiality, and authentication that can help Web service developers secure SOAP exchanges. These mechanisms can be combined in various ways to build a wide variety of security models using a variety of encryption technologies.

WSS also provides an extensible mechanism for associating security tokens with messages that accommodates a variety of authentication and authorization formats and mechanisms. For example, a client might provide proof of identity and a signed claim that they have a particular business certification. A Web service receiving such a message could then determine if it trusts the claim and to what extent.

Security token claims can be endorsed by an authority or left unendorsed. A set of endorsed claims is usually represented as a security token that is digitally signed or cryptographically protected by the authority. A familiar example of a signed security token is an X.509 certificate; it asserts a binding between one's identity and a public key. Security tokens can be "pushed," or carried, in a message, or expressed by a reference so the receiver can "pull" the claim from the authority.

Because a security token is useful within a trust domain, there needs to be a way to articulate the scope of a trust domain. It can be articulated manually, by an agreement, or by implementing a set of rules enforcing the trust policy. An unendorsed claim can thus be trusted if there is any established trust relationship between the sender and the receiver. For example, the unendorsed claim that the sender is Bob is sufficient for a certain receiver to believe that the sender is, in fact, Bob if the sender and the receiver use a trusted connection, which they have set up through an out-of-band trust relationship. In this example, the existence of this trusted connection might be sufficient proof.

Protecting message content from illegal access (confidentiality) or illegal modification (integrity) are primary security concerns. The WSS specification provides a means to protect a message by encrypting and/or digitally signing a body, a header, an attachment, or any combination (or parts) of these.

Authenticating requests is based on a combination of optional network and transport-provided security and information (claims) proven in the message, a technique better known as message origin authentication. Requesters can authenticate recipients using network and transport-provided security, claims proven in messages, and encryption of the request using a key known to the recipient. Trust modelOne way to demonstrate authorized use of a security token is to include a digital signature using the associated secret key (from a proof-of-possession token). This allows a requester to prove a required set of claims by associating security tokens -- such as Public Key Infrastructure for X.509 Certificates (PKIX) or X.509 certificates -- with the messages.

If the requester does not have the necessary token(s) to prove required claims to a service, it can contact appropriate authorities (which we refer to as security token services) and request the needed tokens with the proper claims. Security token services form the basis of trust by issuing a range of security tokens that can be used to broker trust relationships between different trust domains.