Section 9.4. Securing SOAs

9.4. Securing SOAs

In SOAs, security is certainly of primary concern and should have solid foundations in the infrastructure. Before you take any technical steps to implement a specific security structure, you should capture the security requirements for all relevant pieces of software during a risk analysis. Based on this analysis, you build the software architecture to incorporate the defined security requirements. Performing a risk analysis is beyond the scope of this book, but details on the subject can be found in [PT2001]. Instead, based on a number of implementation projects carried out by the authors, we discuss here some technical issues that you must address when designing a security infrastructure in a distributed software architecture.

The main issues of a basic security infrastructure are authentication, authorization, and confidentiality. The focus broadens where the infrastructure is exposed on the outside of some well-controlled environment, such as a specific department or geographic location. In these situations, concerns such as non-repudiation, message integrity, and legally binding identity assertion become increasingly important [GS1997].

In this section, we discuss these principles and provide examples of how they relate to platforms that are commonly used to create SOAs. The guiding principle is that we want to use security as a tool to foster and encourage the use of our enterprise architecture, rather than security simply being a means to prevent incidents.

9.4.1. AUTHENTICATION

Authentication means that a service caller is using a mechanism to prove its identity to the called resource. The caller must provide credentials such as a username and password or a digital certificate. Often, security requirements for authentication include an implicit authorization requirement. The typical scenario is that callers must authenticate themselves before being allowed to use the environment.

Three levels of authentication can be readily distinguished. First, it is possible for the caller to authenticate against the application frontend, second, authentication against the SOA framework is possible, and finally, authentication against a single service is also a possible option. Figure 9-16 illustrates authentication at different levels of the application.

Figure 9-16. Authentication against different levels of the infrastructure. In this case, the Web site supports authentication. Authentication against the infrastructure is also supported. Individual services, such as the customer service, might also require or support authentication.

Authentication against the application frontend is generally straightforward and quickly deployed. Often, it will be a vital business requirement to protect access to the application itself. Authentication against individual services is often desirable in order to limit access to these services and to create a clean audit path within service invocations. However, when authentication becomes part of each individual service, a significant amount of code cluttering results. If the authentication mechanism and storage change, a significant amount of reengineering might be necessary to propagate these changes into the various services. In addition, different services probably rely on different types of storage and authentication mechanisms in the first place.

Therefore, it is generally better to insist that the user be authenticated against the infrastructure rather than against individual services. It is a prerequisite for SOA-wide authorization and identity assertion, as we discussed in the following. However, some very important advantages are available. For example, having a common user for subsequent operations in an SOA makes monitoring the environment a lot easier. Common types of attackssuch as password guessing or denial of service attackscan be prevented or at least treated in a standard way throughout the SOA. In addition, maintenance benefits greatly because changes in the underlying authentication mechanism can be performed across the board rather than against individual application frontends or services.

Authenticate Against the SOA

Authentication against the SOA facilitates cleaner and easier-to-maintain code with a comparably small overhead.

Authentication against the SOA is usually based upon the framework that is used to build the SOA infrastructure or a common framework on top of the basic infrastructurefor example, a J2EE-compliant server that can be extended using a pluggable authentication provider.

An authentication framework usually consists of at least an authenticator and a context. Technically, a context is often associated with conversational state in a session (see Chapter 8). The authenticator is a software component that checks a user's credentials, such as a username and password or a digital certificate. The infrastructure then creates a context that is accessible from the business domain in order to obtain the authenticated user, commonly known as the principal. The predominant middleware frameworks all support authentication mechanisms that can be leveraged in an SOA and that can be readily extended to satisfy individual enterprise needs. For example, a company might create an authenticator within a newly created SOA that uses usernames and passwords from an existing mainframe application. The J2EE environment provides JAAS (Java authentication and authorization service), a mechanism that describes the process of authentication and authorization of client interactions.

One drawback of such specifications is that they tend to be at least partly proprietary. Contexts that originate from different frameworks are usually incompatible. Even when they support a common client API such as JAAS, their implementations can differ significantly, and they might support different and incompatible extension mechanisms.

Such systems share the fact that the actual authentication process is fully transparent to the individual service. A service might decide to check the current principal and thus reject any operation, but it will not perform the actual login process. This isolates the service implementation from changes in the authentication mechanism. For example, it is possible to change authentication credentials from username/password to digital certificates without the need to change the service implementation. In short, the service needs only to know the context, not the authenticator.

If authentication against the SOA itself is not practicalperhaps because individual services are engineered in a way that requires individual authentication, possibly using different credentialssingle sign-on frameworks can be used to relax the problems of integration. Typical single sign-on frameworkssuch as Netegrity Siteminder, Oblix NetPoint, and Citrix Metaframeplug into the authentication hooks of the various software components used, including middleware, Web servers, and mainframe applications. They provide a consistent view of an authenticated principal within all these environments. The individual systems mighton their ownrely on different authentication mechanisms that have their own storage mechanisms and different credentials. A single sign-on framework can provide credential mapping, providing the correct logon credentials for each invoked service or even backend applications. Single sign-on is generally straightforward and transparent to implement for programmers but needs a significant effort to introduce and maintain, especially when credential mapping is involved. The general principle of a single sign-on framework is illustrated in Figure 9-17. Note that most single sign-on products are not limited to simple authentication and credential mapping; they usually offer mechanisms and storage for authorization, too. Some frameworks even provide hooks to include biometric equipment such as retina scanning or face recognition.

Figure 9-17. Principal of a single sign-on infrastructure. The user is originally authenticated against a single application that interfaces to the single sign-on framework. The framework provides login contexts and tokens for the other applications and the application frontend.

9.4.1.1 Authentication and Middleware

Authentication is fairly straightforward to implement when standard middleware such as J2EE, CORBA, or .NET is used as the basic runtime foundation. Most of these frameworks support some notion of authentication and caller identity.

Of course, the process of passing credentials might not be very secure. For example, it is common practice to use unencrypted passwords when logging in to a remote EJB container. Therefore, most distributed environments use the notion of a login session. Once logged in, a session ID is passed between the participants. A frequently used technique for session creation is the server-side session management in Web applications where HTTP cookies or URL rewriting is used to maintain a session. Similar techniques apply to CORBA and to authentication when obtaining a J2EE naming context.

There is also the notion of a login context in the Java Authentication and Authorization Service (JAAS), now a standard in the J2EE application environment. This login context provides callbacks that enable the called runtime environment to query the caller identity using the callback:

 ... import javax.security.auth.login.LoginContext; ...     LoginContext loginContext = null;     try {       // Create LoginContext with username, password and           // login url       loginContext = new LoginContext("AirBookers",              new AirBookersCallbackHandler(username, password, url));       loginContext().login();     } catch (Exception exc) {     } 

The callers then pass their identity on each subsequent invocation using an implementation of the PrivilegedAction interface, in this case FlightBookingAction:

 Subject subject = loginContext.getSubject(); FlightBookingAction flightAction = new FlightBooking-Action(url); Security.runAs(subject, flightAction); System.exit(0); 

After the user has completed the interaction, the login context can be discarded by calling loginContext.logout(). Note that the client interface for JAAS authentication is rather complicated to handle. However, the actual service implementation is usually not concerned with the details of the authentication mechanism. The implementation does not directly call any of the available callbacks. Instead, the framework provides the current caller within a context object, for example a SessionContext object in case of stateless and stateful session EJBs. The caller principal can then be obtained from the session object:

 ... Principal principal = ctx.getCallerPrincipal(); System.out.println("Called by "+principal.getName());        ... 

More sophisticated frameworks protect the login session by varying the session ID during the session by issuing new session IDs or transaction numbers for every service invocation.

Creating authentication as part of an SOA is easy because of its limited impact on the underlying applications. Remember that services are often created from existing applications. Service enablement of such applications includes obtaining the caller principal from the service infrastructure. Even if the application does not support anything similar to a pluggable authentication module (PAM), it is fairly easy to create something similar in almost every application. For example, if the legacy application has an existing data store of users that it has a strict requirement to use, you can always create shadow users for every principal in the infrastructure security store and map them to the existing users of the legacy application.

Sometimes, you might see the concept of authentication as a service. Several frameworks are available that provide identity services that require a certain amount of infrastructure to be available. Although they are very powerful, there is also some resistance to adoption of these frameworks. Deploying such systems in any large organization is generally a costly exercise that must be based on a strategic decision made at the enterprise level. Even then, individual project teams might show a certain resistance to using them because they can create additional risks in projects in terms of software development skills or adherence to their SLAs. In the end, using these frameworks can help an SOA effort as well as kill it. Within the enterprise, the best option is to standardize on a single storage facility to access enterprise-wide user data. Directory services such as LDAP servers provide a very efficient means of storing and looking up such data.

When designing an authentication architecture from scratch, you should take care to make it "pluggable." This makes it possible to change the implementation as well as the underlying concept of an authentication mechanism, such as changing user stores or switching from username/password authentication to certificate-based authentication.

9.4.1.2 Authentication and SOAP

Web services using SOAP are one of the most popular ways of building a Service-Oriented Architecture. Although various techniques exist to secure a Web service environment [H2003], SOAP provides only limited standardized support to satisfy the most basic authentication needs.

SOAP 1.2 does not include a standard means of passing credentials, nor does it support the concept of a caller context. Although both can be built easily using simple SOAP calls and the SOAP header, this amounts to a proprietary approach. Any bindings into the application to access the context and caller principal must be handcrafted.

There are specifications that offer solutions, most notably the WS-I Basic Security Profile and SAML, a framework for exchanging authorization and authentication information. Both define a means for authentication at the protocol level, but unfortunately, that is all they do. No stable standard bindings are available into common programming languages such as Java or C++ that can be leveraged in a project. Hand coding support that strictly adheres to the specifications is by no means trivial. It is not so much a problem for service implementation but for the client applications. For application developers, an SOA using SOAP that does not adhere to some standard is likely to discredit the SOA initiative in the first place. For the moment, the best compromise might well be to use only a small and clearly constrained subset of the specifications that either are available or that can be easily provided for the client environments of the SOA. Unfortunately, at the time of writing, this process can result in a somewhat weak security model. The WS-I Security Profile of the Web Services Interoperability Organization is likely to provide a more consistent and thorough toolset for securing Web services in the future. It willamong other thingssupport user authentication using various technologies.

The Security Assertion Markup Language (SAML) developed by OASIS can be used to include authentication and authorization-related statements in addition to signed messages into a SOAP document. In SAML, security statements are packaged into assertions that are issued by assertion providers. There are three basic types of assertions: authentication, attributes, and authorization. Similarly, there are three matching assertion providers, although a single entity might well act as assertion provider for all three types. An application can request a security assertion from an assertion provider, such as using username and password. The assertion provider will return an (optionally signed) assertion that always contains a timestamp, an assertion ID, and the subject of the assertion, typically the application user. It can contain conditional information; for example, about the length of time the assertion remains valid. The assertion or the assertion ID can be included with other SOAP messages and can be automatically verified by the called application. Single sign-on frameworks are obviously prime candidates to act as assertion providers. The following is an example of an authentication assertion:

 <saml:Assertion       MajorVersion="1" MinorVersion="0"       Assertion       Issuer="www.dolphinair.com"       IssueInstant="2003-07-01T12:00:00+01:00">       <saml:Conditions        NotBefore="2001-07-01T12:00:00+01:00"        NotAfter="2001-07-01T12:00:00+01:00"/>    <saml:AuthenticationStatement         AuthenticationMethod="password"         AuthenticationInstant="2001-05-31T13:21:00-05:00">       <saml:Subject>       <saml:NameIdentifier>          <SecurityDomain>"www.dolphinair.com"</SecurityDomain>          <Name>"cn=Dirk,co=travel,ou=check-in"</Name>       </saml:NameIdentifier>       </saml:Subject>   </saml:AuthenticationStatement> </saml:Assertion> 

9.4.2. AUTHORIZATION

Authorization is the mechanism used to grant a caller access to a specific resource. In the simplest case, the caller might have the right to generally use a certain service, but more often, the authorization decision is much more dynamic. For example, a user may alter only certain data sets that belong to that particular user. Consider a flight planning example, where cockpit crews may change their own flight plans but not the flight plans of other flights. In authorization, no common abstraction principle lies at the core of the authorization process, other than allowing or denying certain actions. As with authentication, authorization can be performed at several levels, such as the application frontends, the individual services, and the SOA infrastructure.

Authorization within the application frontends is one possibility. However, if used on its own, this creates a severe security flaw because the underlying services would not offer any authorization protection at all. The ease of implementation comes at the high price of reduced security, as well as inconsistent authorization policies for the same business activity due to the implementing application. Mirroring authorization decisions at the application level might appear sensible in order to reduce round trips to a remote server, easing the load on the remote server and the network while at same time providing a better user experience. Consideration for the maintenance of the system is an issue during the design phase.

As with authentication, the level for authorization might not necessarily be the SOA infrastructure level. Instead, both the storage of the authorization data and the level of dynamism in determining caller permissions determine the preferred location for an authorization decision in an SOA.

The parameters used to determine the access decision can be complicated, and several approaches can be identified. They mainly differ in the way in which the authorization relevant information is stored and the way the authorization decision is determined:

• Store access data with the authorized resource. This is a modular approach where the actual data that determines the authorization decision is stored with the resource itself. As a common example, consider the file access rights in the Unix file system. No central registry stores the read, write, and execute rights in addition to the owner and group information for a file. This data is stored with the file itself. The benefit of such an organization is that the authorization decision is very effective from a performance viewpoint. An obvious disadvantage is that the introduction of a new authorization policy can be a rather complicated exercise.

• Store access data centrally. This approach is for the example used in the access control system of the Windows NT operating system family. Often, authorization information is stored and accessed by means of access control lists (ACLs), whereby a resource is identified by a certain path. Each resource features certain capabilities, such as read, write, delete, or execute. Access to these resources can be either granted or denied.

Both of these mechanisms basically define a static binding between a resource and either a user or a mapping of users into a group or role. In a real-world scenario, this is rarely sufficient. The following types of access decisions can be readily distinguished:

• Static authorization decision based on the current user or a static group membership. This is easily determined by a resource external to the actual business process providing access to the authorization data is guaranteed.

• Dynamic authorization decision based on a dynamic group membership (role). This might be based on any factor external to the application but accessible for the authorization framework. Popular examples are decisions that grant access during a certain period of the day or based on the value of session variables that are only temporarily available.

• Dynamic authorization based on an attribute of the authorized resource. This is the type of decision that is often at the core of business processes. As an example, consider the authorization of a credit card that is based on the card number, expiration date, and customer address. Another example is the authorization of a banking transaction that is based on the user entering a valid transaction number from a list.

Often, business requires the auditing of authorization and authentication processes. This particularly includes both forms of dynamic authorization decisions. A fair amount of authorization can be performed using standard technologies, such as the authorization mechanism in frameworks such as .NET or the Java Authorization and Authentication Framework (JAAS). Language bindings are also available that enable authorization at the message level of SOAP, even though these are, at the time of writing, mostly proprietary solutions. CORBA enables declarative authorization using the CORBA security service.

Authorization can in principle be performed by an external service. Technologies such as SAML and the upcoming WS-I security support it out of the box.

Although frameworks and APIs are available to support authorization using declarative mechanisms or even rule-based decision frameworks, you must bear in mind that SOA is fundamentally about the integration of existing applications. Applications that are to be integrated might very well use authorizations mechanisms that cannot be mapped easily onto a common system.

This is because at least some part of the authorization procedure will generally be part of the service implementation, instead of residing on the service infrastructure level. For example, the authorization scheme within a certain service implementation might not easily map to the one in another service implementation. Often, the authorization decision is buried deep within the service implementation. At the same time, it is often at the heart of the business process. Requiring externalization of the authorization procedure in the business process also creates a risk for service enablement in integration projects and poses an entry barrier for applications to join an integration initiative.

All this makes it rather unusual to perform authorization completely within the service framework itself because it is genuinely hard to move authorization out of technology. However, a refactoring of code during service enablement to make specific parts of authorization pluggable can provide a good compromise with limited impact and high flexibility. This can include decisions that depend on the principal's static or dynamic group membership. It can also include rule-based decisions, where the parameters for these decisions are available at infrastructure level. Later in the service lifecycle, security frameworks can provide or replace the authorization implementation well within the lifecycle of the application.

9.4.3. ENCRYPTION AND T RANSPORT SECURITY

When talking to people who cover security for business clients, one is often confronted with the requirement of encryption. The general impression is that if something is "encrypted," it is safe, as long as decryption cannot be performed easily and swiftly. To understand the pitfalls of this perspective, it is necessary to distinguish between two different forms of encryption: encryption at the message level and encryption at the transport level. The former can be employed to create real end-to-end security and is generally the preferable method. Furthermore, because encryption can be performed at the message level, it is possible to encrypt only the payload or payload segments of the message. If such a message uses the SOAP protocol and the W3C's recommendation for XML encryption syntax and processing, a section of the message using encryption might look like this:

 <PaymentInfo xmlns='http://www.dolphinair.com/booking'>     <Passenger>John Smith</Passenger>     <Itinerary >ae12345-fght</Itinerary >     <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#         Element'      xmlns='http://www.w3.org/2001/04/xmlenc#'>       <CipherData>         <CipherValue>A23B45C56</CipherValue>       </CipherData>     </EncryptedData> </PaymentInfo> 

The benefit of this approach is that it not only provides superior security but that certain rules can still be applied to the otherwise encrypted messages. This makes it possible to use message-based routing, to perform advanced audit checks on the unencrypted parts of the messages, and to perform analysis to detect denial of service attacks, attempts for message replay, or similar attacks that might otherwise go unnoticed. Of course, this comes at a price in that the necessary infrastructure to support message-level encryption must be in place. In the preceding example, the payment information that might be sent as part of a ticket purchase includes the name of the customer as well as the itinerary ID in clear text. Only the actual payment information is encrypted. This has the same basic challenges one faces when creating a thorough authorization infrastructure, both organizational and technical.

Because of this overhead, it is often a sensible alternative to apply security at the transport level. The preferred way to accomplish this is to use the Secure Socket Layer (SSL) protocol. The benefits of this approach are obvious because SSL works almost everywhere, from mobile phones to mainframe computers. It requires little overhead to initialize, and resource usage is limited. Where resources are at a premium, it can be made faster using special cryptographic devices. When two-way SSL is employed, it can even be used to pass user credentials and to perform transparent user logon. The main advantage, however, is that it is widely understood. This is a very important issue because many failures in security infrastructure are due to accidental misconfiguration that in turn occurs because the implications of the infrastructure parameters are not fully understood.

However, there are also downsides to this approach. Intrusion detection becomes practically impossible because there is no way to "listen in" to the occurring traffic. When no end-to-end network connection can be employed, this setup is a potential target for a man-in-the middle attack because messages must be decrypted somewhere along the transport chain. This can be a simple network "hop," or messages need to be decrypted by some part of the SOA architecture, such as a MOM server that encrypts them again when forwarding to the recipient. Furthermore, two-way SSL for authentication is no longer usable because the original certificate does not retain a value beyond the first network hop.

In summary, encryption at the message level is definitely more desirable than encryption at the transport level. Yet more often than not, the latter will be the only feasible solution due to the lack of standards for creating message-level security and fundamental technical considerations; for example, with systems where performance is at a premium, you often cannot afford the computational and memory overhead of message encryption and decryption.

9.4.4. T RUST DOMAINS

A layered architecture such as an SOA often employs the concept of trusted domains. Authentication and authorization is located in the application frontend and in the high-level process-centric services. Other backend services and applications might require no security at all or might support a very limited set of security features. For example, no authorization or user-level security might be required by the backend services. Often, minimal security is imposed using a firewall setup, where connections to the insecure backend services are allowed only from specific hosts.

This is somewhat analogous to common setups using a Web server or an application server and a backend database. In this situation, not every user is authenticated against the database; instead, the server uses a pool of connections to the database that are all associated with a single database user.

It is evident that such a setup is applicable only within a closed and secured computing network. For a typical enterprise computing setup, this maps to certain network segments in a closed data center environment.

One benefit of this approach is the ease of setup and development of the backend services. The development effort associated with authentication is simply omitted. In addition, the backend services can be independent of any enterprise single sign-on infrastructure, making them simpler and ultimately more robust.

The greatest benefits of the approach are also its greatest weaknesses. For example, all auditing within the backend services must be performed manually. It is thus more error-prone and harder to maintain. This can lead to enormous efforts if legal regulations require in-depth changes to auditing. It is often desirable to make a backend service publicly available. In the case where the required security infrastructure is missing in these services, they usually must be proxied by another service that adds no business value at all. This adds an additional level and introduces a maintenance effort if the original service changes. For example, an airline might decide to expose their booking process to a partner airline, as in Figure 9-18.

Figure 9-18. A trusted domain can be convenient but can introduce overhead and entropy if a service in the trusted domain must be promoted for third-party use. In this example, an airline is offering its booking service to a partner airline.

Trust Domains

Trust domains require a controlled, closed environment. Individual securing of even basic services is likely to save money in the long run and reduce maintenance efforts.

9.4.5. SECURITY AND HETEROGENEITY

Typical IT landscapes in the enterprise are very heterogeneous. For security considerations, the same rule applied to SOAs holds true: Do not fight heterogeneity but rather embrace it. More often than not, it is impractical to bind a backend service, let alone an entire legacy implementation, completely into the global enterprise security framework. On top of that, heterogeneity also exists among different client devices to your SOA, as well as the difference between the infrastructure inside and outside the enterprise or the department running the SOA.

For the outside world, it is important that the SOA appeals to as many potential clients as possible. The general rule is to secure the services exposed to the outside world as much as possible. It might be an option to provide certain services in multiple versions for different environments and to ensure that access takes place through the correct device.

Within the SOA, it is a good idea to provide a unified security framework. However, no possible participant of an SOA should be alienated by the required participation in a security framework that one does not want or cannot support. Thus, it should be an option rather than a requirement.

In addition to providing an SOA security framework, the infrastructure should be well protected using firewalls and trip wiring between the different layers of the application, as illustrated in Figure 9-19.

Figure 9-19. Illustration of security infrastructure that is catering for hetero-geneous frontends and backends alike. In this example, a number of service implementations participate in a common security infrastructure, which uses a common security store. The customer implementation is part of a trust domain with respect to the SOA infrastructure. Access to this domain should be policed in a clearly defined way.

Secure the OutsidePolice the Inside

Use off-the-shelf technology, such as firewalls, to lock out intrusion at the network perimeter. Use monitoring and trip wiring at system boundaries inside the enterprise to detect and report any suspicious activity.

Let us study the practical implications of such a setup with the customer booking process. The booking process originates on the airline Web site. At this level, customers will usually authenticate themselves with the system. The ability of the customer to book a flight is decided within the Web layer. The booking process then calls into the customer booking service using a single privileged user. A firewall ensures that no call with that user identity is made from anywhere but the Web application. The process-centric service checks authorization of the caller and calls out in turn to the different backend services passing the user. They in turn call out to the actual legacy implementations. Although two of these share the same user store with the application, credential mapping is performed in order to access the customer information system on the mainframe. None of the business services perform any authorization because these decisions are made within the legacy applications themselves.

If the process originates from a travel agent application frontend, authentication is performed directly within the application. The application is also bound into the general authorization scheme, presenting the travel agent with only the authorized options. Each travel agent is authorized as a separate user.

9.4.6. OTHER SECURITY TOPICS

When a service is offered to third parties outside the enterprise, matters of non-repudiation and message integrity are vitally important. Both technologies are directly related to concepts of asymmetric encryption, often using a public key infrastructure [GS1997].

For message integrity, it is sufficient to digitally sign the message using a symmetric or asymmetric key, provided the key is known only to trusted parties. For most practical purposes, the message will be signed using the private key of a message sender, and the receiver will check the signature using the public key of the sender (see Figure 9-10). Note that the sender and receiver need not be the original sender and final receiver of the message but that the signature can be added to a sent message only for certain parts of the route, for example between two trusted domains. Furthermore, the keys need not be maintained by an independent third party. It is perfectly feasible and often easier to use a PKI that is hosted within the service provider for this purpose, especially where the service provider engages in business only with entities that are well known to the original service provider.

Non-repudiation means that the service provider and service user assume legal responsibility for the actual message contents (see Figure 9-10). For example, if the airline orders a certain number of menus from the caterer, the caterer might want to ensure that the airline has actually placed this exact order and not something different. Likewise, the airline can use the signed order confirmation of the caterer in case there is a dispute between the airline and the caterer. For messages to be non-refutable, it is usually required that a trusted entity manages the public keys of the parties engaged in the actual business transaction. Moreover, these entities will usually be licensed by some government agency to conform to certain standards, processes, and service levels. Message signatures can then be considered suitable for usage in a legal dispute or multimillion dollar contracts, for example the gross purchase of fuel or the ordering of an aircraft.

Technically, message signing can be easily accomplished if the message is in plain text format and can easily be manipulated. The best example is signing XML snippets that can be placed inside the body of a SOAP message.

Figure 9-20. Communication scenario for message integrity (top) and non-repudiation (bottom). For message integrity, the routers sign the message and check the signature to ensure message integrity after leaving and before entering the trusted domains. For non-repudiation, a trusted third party is needed.