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 policies 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 infrastructure
Secure 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 model
The 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.
Figure 1. Trust models from requester to provider through intermediaries
Network and transport intermediaries (for example, firewalls, routers, and proxy servers) are generally not trusted with respect to message processing. All messages in transit should be protected from tampering by untrusted intermediaries.
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.
Figure 2. Message intermediary brokers trust relationship and federation
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.
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.
One 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.
One mechanism would be the use of a challenge-response protocol as defined in WS-Trust (see Resources for more information about the WS-Trust spec). This is used by a Web service for additional challenges to a requester to ensure message freshness and verification that the use of a security token is authorized. This model is illustrated in Figure 3, showing that any requester may also be a service, and that the requester and target service may have a trusted third-party security token service that helps validate the security tokens required per the target service’s policy.
Figure 3. Security token service
This SOA security model -- claims, policies, and security tokens -- subsumes and supports several more specific models, such as identity-based authorization, access control lists, and capabilities-based authorization. It allows use of existing technologies, such as X.509 public key certificates, XML-based tokens, Kerberos shared-secret tickets, and even password digests. The SOA security model, in combination with the Web Services Secure Conversation Language (WSSC) and Web Services Policy Framework primitives, is sufficient to construct higher-level key exchange, authentication, policy-based access control, auditing, and complex trust relationships.
A Web service has a policy applied to it, receives a message from a requester that possibly includes security tokens, and may have some protection applied to it using WSSC mechanisms. The following main steps are performed by the trust engine of a Web service:
- Verify that the claims in the token are sufficient to comply with the policy and that the message conforms to the policy.
- Verify that the attributes of the claimant are proven by the signatures. In brokered trust models, the signature may not verify the identity of the claimant; it may verify the identity of the intermediary who may simply assert the identity of the claimant. The claims are either proven or not based on policy.
- Verify that the issuers of the security tokens (including all related and issuing security tokens) are trusted to issue the claims they have made. The trust engine may need to externally verify or broker tokens (that is, send tokens to a security token service in order to exchange them for other security tokens that it can use directly in its evaluation).
If these conditions are met and the requester is authorized to perform the operation, then the service can process the service request.
Network and transport protection mechanisms, such as IP Security (IPSec) or Transport Layer Security/Secure Sockets Layer (TLS/SSL), can be used in conjunction with this SOA security model to support different security requirements and scenarios. As an added level of security, requesters should consider using a network or transport security mechanism, if available, to pre-authenticate the recipient when issuing, validating, or renewing security tokens.
Programming model design principles
From a security perspective, the programming model includes decisions to be made about who is responsible for enforcing security policies (such as infrastructure or application) and what of this information needs to be made available to requesters. In addition to the operational aspects, some of the design-time policy (for example, captured in J2EE deployment descriptors) can help manage the application. One of the key implementation decisions is whether the business needs will best be met by enabling the infrastructure to implement the security model or by codifying security enforcement into each application. Another dimension to consider is how variable the service invocation is. Are service consumers given flexibility through choices they can customize during subscription? Lastly, when implementing any secure solutions, one should consider security engineering -- an engineering methodology to build secure applications.
Infrastructure-managed vs. application-managed security
Each organization typically gives certain people the responsibility for identifying and enforcing its security policies. In many cases this process is manual, causing the organization to devote significant resources to coordinating access across different entities and applications.
We recommend that complex organizations centralize, in the infrastructure, the enforcement of the security policies associated with a solution -- that is, validating the user challenge (for example, user ID/password), controlling access to applications (such as
reserve() method on
travelService), and delegating identity (for example,
run-as travelAgency id) to ensure a consistent approach. Initial application security policies can be defined in some deployment artifacts (e.g., deployment descriptors for J2EE applications). After development, when the application logic is largely known, the policy information can be made available to the deployment environment. Policy declarations can be abstracted into high-level policy requirements for later refinement as implementation constraints are considered during the deployment phase.
The application design introduces decisions to be made about infrastructure- versus application-managed security. The security constraints and conditions are attached to the implementation artifacts. The time for deciding whether to let the infrastructure handle security, or codify security in the application, is during the implementation phase when information about the application platform -- such as Java™ 2 Platform, Enterprise Edition (J2EE) and Microsoft® .NET -- is usually available.
We recommend that applications focus on business logic and defer securing the service access and the messages to the infrastructure (the runtime container hosting the application). In this infrastructure-managed approach, security policies attached to design artifacts are transformed into platform-specific policies [for example, requirements expressed through a Unified Modeling Language (UML) model are transformed into J2EE deployment descriptors).
In the application-managed approach, security enforcement is done in the application, and the appropriate security callouts must be implemented. Even application-managed security has to translate its security callouts (such as
authenticate()) into appropriate platform-specific functions [such as
loginContext.login() using Java Authentication and Authorization Service (JAAS)].
Authorization and access control can vary from coarse- to fine-grained. The choice of coarse-grained access (to the solution itself) versus fine-grained access (to one of its operations) is usually governed by business and technical considerations. Granularity is also influenced by factors, including the instance of the information entity (for example, credit account profile for a given traveler), contextual information, such as user attributes (for example, travel agent), temporal constraints (for example, 9-5 p.m.), purpose of access (such as for the purpose of making a travel reservation), access path (for example, intranet vs. external request), and many others.
Authorization-related policy can be abstracted by defining application roles, where a role is a collection of permissions that allow certain actions on given application resources. For example, a travel application can declare that the
change() reservations methods on ReservationBean can be accessed by TravelAgent role. In other words, TravelAgent is an implementation-defined role that identifies what can be done by a "travel agent" in terms of a set of permissions to invoke specific methods on the respective Enterprise JavaBeans (EJBs). What is not likely defined during the implementation phase is who has the privileges of a TravelAgent. User-to-role assignments are typically initialized at deployment and managed thereafter throughout the application's lifetime. Listing 1 shows an example of code defining some role-based method permissions.
Listing 1. Code defining some role-based method permissions
<method-permission> <role-name>TravelAgent</role-name> <method> <ejb-name>ReservationBean</ejb-name> <method-permission> <role-name>TravelAgent</role-name> <method> <ejb-name>ReservationBean</ejb-name> <method-name> view</method-name> <method-name> change</method-name> </method> </method-permission>
Applications that require authenticated identity information before performing some business logic must obtain that information from the infrastructure. For instance, in a J2EE environment, the run time establishes the user's identity after authentication; the application can retrieve this information with an API, such as
Flexibility of choice
Sometimes certain requirements or constraints on the access to the service itself -- including authentication, integrity, and confidentiality requirements -- are needed by a client run time. And it may be desirable to support a wide variety of client run times (such as browser clients, nonbrowser clients, and PDA thin clients). To achieve this, you publish policies asserting that the client runtime must ensure message confidentiality and must provide evidence of the user's identity (user ID/password or a certificate). The policy abstraction for authentication can list alternatives, such as the types of credentials that are acceptable or which credential-issuing authorities are trusted.
For instance, a TravelService Web service can declare its intent to require certain security token types and confidentiality requirements. The implementation may support the declaration of intent through descriptors. Tools can, in turn, generate necessary machine-level details (such as a WS-SecurityPolicy expression), as illustrated in Listing 2.
Listing 2. Example of WS-Security Policy description
<wsp:Policy> <sp:SymmetricBinding> <wsp:Policy> <sp:ProtectionToken> <wsp:Policy> <sp:KerberosV5APREQToken sp:IncludeToken=".../IncludeToken/Once" /> </wsp:Policy> </sp:ProtectionToken> <sp:SignBeforeEncrypting /> <sp:EncryptSignature /> </wsp:Policy> </sp:SymmetricBinding> <sp:SignedParts> <sp:Body/> <sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing" /> </sp:SignedParts> <sp:EncryptedParts> <sp:Body/> </sp:EncryptedParts> </wsp:Policy>
In developing secure solutions, one of the best practices is security engineering -- following well-defined patterns so that your application, service, or component will do exactly what its designers and users expect. You should assess the risk inherent in each implementation artifact, designing and implementing it to avoid opening it up to vulnerabilities (for example, efficient memory management and avoiding covert channels) Tools support and code reviews can also help minimize (or eliminate) harm to the environment in which your solution is deployed.
An SOA programming model must ensure that each service invocation adheres to security policies that are valid for both the requester and service endpoint. The security infrastructure -- including the ability to authenticate requesters and authorize their access to services, propagate security context across Web service requests based on an underlying trust model, audit significant events, and effectively protect data and content -- forms a fabric of the SOA environment that helps secure components and services. At the core of all SOA security is a policy-based infrastructure and management of the policies. In the ideal case, the SOA application is centered on business logic, delegating the enforcement of security policies, and handling trust relationships for the infrastructure. The Web services security model and approaches based on the Web services security specifications help meet the challenges of securing service-oriented applications.
- Visit the OASIS Web site for information about OASIS Web Services Security: SOAP Security.
- Read Part 4 of this series, "An introduction to the IBM Enterprise Service Bus" (developerWorks, 2005).
- Get more information on the Web Services Trust Language.
- Find out more about the Web Services Secure Trust Conversation Language.
- Learn more about the Web Services Policy Framework.
- Visit the developerWorks SOA and Web services zone for extensive how-to information, tools, and project updates on SOA and Web services technologies.
- Read the other articles in this series.
- Browse all the SOA and Web services articles and free SOA and Web services tutorials available from developerWorks.
- Participate in the discussion forum.
- Get involved in the developerWorks community by participating in developerWorks blogs.
Dig deeper into SOA and web services on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.