March 21, 2019
Hot Topics:

Solutions to SOA Security

  • May 19, 2006
  • By Eric Pulier and Hugh Taylor
  • Send Email »
  • More Articles »

Certificates, keys, and encryption

Over the years, the IT world has embraced a number of message-level security techniques involving cryptography. Now, you can apply these same techniques to your SOA. These processes, involving digital signatures, certificates, keys, and encryption, can play a role in securing your SOA. A quick disclaimer here: One could easily write a book or even several books about each of these four security techniques. Please look at this section as a brief overview of encryption-based security as it relates to the SOA.

If you want your SOA to have robust security, where you are confident that the users of your web service are properly authenticated and that the information flowing back and forth between web service and their invoking applications is not read by unauthorized people, then you will almost certainly need to apply the powerful tool of public/private key encryption to your SOA security solution. A key is a large number (humongous, really-hundreds of digits) that has certain special mathematical properties. Though they come in different shapes and sizes, the essential property of a key is that it can be uniquely connected with another key. That is, when one key meets its unique counterpart, they both say, "Oh, it's you, my unique counterpart… and no one else."

The unique key pairs serve two basic functions:
  • Because they are unique, they are a very powerful authentication tool.
  • Because of their mathematical properties, they can be used to create unique,
impenetrably encrypted messages that can only be "read" by a user who has both of the unique, matching keys in the pair.

Here's how it works when two users want to exchange encrypted information: User A creates a unique pair of keys. He then keeps one hidden within his own system (the "private key") but posts the other key (the "public key") at a location on the network where User B can access it. User B then takes the public key and uses it to encrypt the information he wants to send to User A. How this is actually done involves so much math that I get a headache just thinking about it, but basically the public key and message data are run through an encryption algorithm that produces an encrypted file that is impossible to open without the private key. User B then sends his encrypted message to User A, who uses the private key he hid at the beginning of the process to "unlock" the encrypted data. The bottom line is that User A is the only person in the world who can unlock the encrypted data because he has the unique matching key to User B's public key.

Now, if you're paranoid like I am, you might be thinking, great, but how does User A know that User B is actually User B? What if someone hacked into the system and found the public key that User B was meant to use? To answer this valid question, a number of entities have come into existence that assure the authenticity of specific users and grant them digital certificates that attest to their authenticity. These entities are known as certificate authorities (CAs). A well-known example of a CA is VeriSign, which issues certificates for use in e-commerce transactions.

Thus, an SOA security solution that uses keys, encryption, and certificates to enforce privacy and authentication might resemble the one in figure 11. In our manufacturer example, the vendor system wants to send a SOAP message to the manufacturer's web service. To make this possible, the manufacturer has to first send a public key to a CA. The vendor system then requests a certificate from a CA. The certificate that the vendor receives contains the public key that matches the private key residing on the manufacturer's system. The vendor then uses the certificate's public key to encrypt its message and transmits it to the manufacturer. However, as in the previous examples, the SOA security solution intercepts the message and checks the validity of the certificate with the CA. This serves to authenticate the vendor's identity. Only after this authentication has been completed does the encrypted SOAP message travel to the manufacturer. Once there, the manufacturer uses its private key to decrypt the message and process it.

If you think this sounds like a lot of work just to send a message, you're right. Security in the SOA, as in other areas of IT, creates a lot of "overhead." Each message has to travel to several places before it reaches its destination. Certificate files can be large and taxing to network infrastructure, and the whole process tends to slow down performance. Still, it is an unfortunate necessity.

XML encryption

To preserve the openness of your SOA while instituting tight message-level security standards, you will probably want to use XML for your encryption. When the SOA security solution uses a key to encrypt a message, it transforms the message into a

Figure 11 The step-by-step process of using public/private key encryption and certificates in a secure SOA

piece of XML that is encrypted. The message is in XML format, but the content is not apparent because it is hidden through the use of an encryption algorithm. The benefit is that the system that receives the message can accept it, decrypt it, and process it as XML without relying on custom or proprietary messaging standards. You get security, but your system remains based on open standards.

Digital signatures

Digital signatures, another form of message-level security, are a variation on the certificate, key, and encryption approach to security. A digital signature is a mathematical statement of authenticity that you attach to a SOAP message. Based on keys, the digital signature is a number (again, a very large number) that uniquely captures your identity and the content of your message, by running the two sets of data (the key and the message) through a special algorithm. So, to take a simplified example, if your message is "hello" and your key is 12345, the algorithm will process those two inputs-the digital value of the world "hello" and the key number 12345-and produce a third number, which is your unique digital signature. When the receiving system gets the message and attached digital signature, it can use the key to verify that

  • You are the true author of the message (authentication).
  • The SOAP message has not been altered in transit.

If it had been altered, then the unique signature number would no longer match the key and the original message used to create the key. The difference between digital signatures and the complete encryption process described earlier is that in the digital signature case, you do not have to encrypt the entire message. As a result, the performance of the system improves. As long as you don't mind if someone can see your message in plain text, then the performance considerations of digital signatures provide a high degree of security and integrity of data in your SOA.

Signatures can be a component of nonrepudiation, an important aspect of security that needs to be addressed in an SOA context. Nonrepudiation refers to an organization's ability to authenticate that a particular transaction occurred, and thus deny the sender the opportunity to repudiate (a fancy word for "deny") that the transaction went through. For example, if you placed an electronic order for merchandise, and that order was not authenticated in some way, such as with a digital signature, then it might be possible to repudiate the order. If the merchant's system provides for nonrepudiation, then the merchant can affirm that the order was indeed placed.

Replay attack protection and auditing

Finally, your SOA security solution should provide a facility for tracking SOAP requests in order to limit the potential for damage in DoS attacks. Usually, a tracking feature will monitor the sender of the SOAP message and the time that it originated. In some cases, the SOA security solution will "stamp" the SOAP message with a unique identifying number. If the solution is set to block duplicate messages, it then becomes impossible for the same message to be sent twice. Eliminating this potentiality helps reduce the change that hackers could flood the SOA with duplicate requests-a favored technique used in DoS attacks.

Auditing is a further use of SOAP message tracking capabilities. If the SOA security solution is configured to track messages, then it should be able to generate usage logs and audit reports for SOA message traffic during specific periods of time. The audit has many uses, but in security it serves as an important record of what has happened that can be used to investigate security problems and diagnose potential security weaknesses. This type of log has become essential to achieve regulatory goals such as Sarbanes-Oxley compliance.

The Savvy Manager Cautions: Don't Let Security Paralyze You

SOA security is a massive subject. I could write a whole book on it. In fact, that's not a bad idea... My intent in this chapter is to give you an overview that provides a basic toolset for evaluating information presented to you on the subject. If you are a business executive, my suggestion is to avoid becoming overwhelmed by security issues. It is easy to become paralyzed by security-security people can also do it to you-and balk at doing virtually anything for fear of security concerns. Indeed, I could probably take a proposed IT solution you are contemplating and walk you through enough security nightmares around it to scare you away from it.

Instead, I recommend that you seek high-quality counsel on security and explore what your enterprise already has in effect. Chances are, your company probably already has a pretty robust security system (or systems). The challenge with SOA is to figure out how to extend those existing security measures to the web services that comprise your SOA. Many SOA security solutions are designed to interconnect effectively with existing security functionality. At that point, the security risks might begin to look a bit more manageable and you can proceed with your plans.


Security is a pressing issue in SOAs because the SOA stresses machine-to-machine interaction, while most IT security is based on human-to-machine interaction. Authentication and authorization become more challenging in this environment. It is virtually impossible to block unauthorized use of web services in an unsecured SOA; it is quite simple for an unauthorized user to access web services. Web services have no innate ability to track who is using them or who is permitted to use them. And you cannot stop unwanted listening in and message interception. The unsecured SOA presents hackers with the ability to eavesdrop on SOAP message traffic and see information that may be private. In addition, it is relatively easy to intercept a SOAP message in an unsecured SOA and reroute it or transform its content for purposes of mischief or fraud.

You cannot secure unknown third parties in an SOA because of the architecture's open nature. It is possible for secondary or tertiary users-the partners of your partners, for example-to access an unsecured SOA. As a result, the unsecured SOA is vulnerable to overload. With no access controls, an unsecured SOA is open to being "flooded" with excessive SOAP message traffic from hackers. The result can be a DoS attack that harms the ability of your systems to function. Finally, you have no transaction logging. The unsecured SOA cannot keep track of its users or its messages. Thus, there is no auditable record of usage that can be used to investigate security problems or diagnose security weaknesses.

There are both prepackaged and custom solutions to SOA security that can potentially address all of these issues. As you examine your SOA security needs, consider implementing an SOA security solution that enables SOAP message monitoring; federated authentication; application proxy; contract management; certificates, keys, and encryption; and audit logging. It seems like a long list, but the truth is without any one of these in place, all the benefits from your SOA will evaporate.

SOAP message monitoring utilizes a SOAP interceptor model to intercept and monitor SOAP messages as they travel from invoking systems to web services. SOAP message monitoring is the foundation of SOA security because it gives your security solution the ability to stop and examine each message for user authentication and authorization. To secure third parties, your security solution can take advantage of federated authentication. You should offer the ability to authenticate users on the system through a federated authentication process. The end result is an SAML assertion that provides credible authentication of the user to the web service.

A web service application proxy aids security by receiving and processing SOAP requests in place of the actual web service. It can keep all users away from the actual service. Along with moderating the load on the network, the proxy provides an additional layer of security to the SOA.

Contract management is an SOA management feature that also contributes to security. Contracts establish who has the right to use a web service and when they can use it. By eliminating usage by noncontracted parties, the contract adds security to the SOA.

Certificates, keys, and encryption are also essential for a truly secure SOA. The most robust SOA security results from the implementation of encrypted messaging authenticated by private key/public key pairs from a certificate authority. XML encryption allows a web service user to send an encrypted SOAP message that retains its XML formatting. As a result, the system is secure but remains standards based. Digital signatures, a variant of the encryption model, offer the web service user the ability to create a unique, authenticated digital "signature" that serves the dual purpose of verifying the identity of the user as well as assuring the integrity of the message data.

Finally, in order to track the use of an SOA, it is necessary to employ an SOA security solution that maintains an ongoing audit log of all SOAP message requests and responses. The audit log is necessary for investigating security problems, diagnosing security weaknesses in the SOA, and achieving government regulatory compliance.

About the Authors

Eric Pulier is a pioneer in the software and digital interactive industries. A frequent public speaker at technology conferences around the world, Eric has helped establish cutting-edge technology companies in media management, professional services, voice systems, and peer-to-peer networking.

Hugh Taylor is an SOA marketing executive who writes, teaches, and promotes the business value of SOA and web services to major companies. The authors live in Los Angeles, California.

About the Book

Understanding Enterprise SOA
By Eric Pulier and Hugh Taylor

Published: November, 2005, Paperback: 280 pages
Published by Manning Publications
ISBN: 1932394591
Retail price: $39.95
This material is from Chapter 9 of the book.

Page 2 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date