This article picks up where Security in a Loosley Coupled SOA Environment left off but it can also stand on its own.
Now that we’ve been “slapped in the face” by security concerns in the SOA in the last article, and said “Thanks, I needed that!” it’s time to look at some possible solutions to these challenges. The short answer for SOA security problems is that you need to buy or develop
a security solution for your SOA. The long answer, which follows, is quite subjective
and complex. The goods news, however, is that most major security issues in the SOA
can be resolved by a correctly designed SOA security solution. The solution itself may
consist of a number of sub-solutions, each dealing with a certain aspect of SOA security.
Depending on your needs, and the existing security infrastructure, you will probably
require a specific set of solutions that might differ from those of another entity.
Let me repeat my earlier disclaimer: It is my goal here to give you a way to evaluate
how security may affect your SOA planning. I am a vendor of SOA security products.
And yes, you may detect some bias on my part for one solution approach over
another. At the same time, you should be aware that I compete with many other companies
that also approach SOA security in the same manner as I do. In effect, the market
has validated some approaches to SOA security more than others.
SOAP message monitoring
SOAP message monitoring based on SOAP interception is one way to build the foundation
of an effective SOA security solution. SOAP interception involves placing a special
Figure 7 A SOAP interceptor monitoring SOAP messages serves as a
foundation for security in this SOA. The SOAP interceptor analyzes the user
identities contained in the headers of the SOAP messages it monitors and
compares them with those names stored in the existing security
infrastructure. The result is authentication and authorization of SOAP
message senders and receivers.
piece of software called a “SOAP interceptor” in the path of the SOAP messages that
travel back and forth between a web services consumer and a web service. Because of
their ability to digest, monitor, copy, and forward the data-rich SOAP messages, SOAP
interceptors figure very prominently into SOA security. As shown in figure 7, an
SOA security solution “watches” the SOAP invocation messages approaching the web
service as well as the responses to those service calls. When it “sees” a message, the SOA
security solution checks to make sure that the requesting entity is authenticated and
authorized to use the web service. The SOA security solution accomplishes this by
checking the user data contained in the SOAP message header.
In most cases your SOA security solution will be augmenting an existing security
solution that you deployed to secure your entire enterprise before beginning transitioning
to an SOA. In all likelihood, as a result, your SOA security solution will have
to connect to and communicate with the existing security infrastructure. As shown in
figure 7, the authentication and authorization of users on the SOA occurs when
their credentials are checked with the enterprise’s database of authorized users.
Authentication and authorization are achieved by intercepting the SOAP messages
and comparing the users listed in the message header with those users stored in the
existing security infrastructure.
SAML and federated authentication
What happens when you need to authenticate and authorize SOA users who come
from outside your enterprise? The openness of the SOA makes this scenario more likely
than it has been in the past. You may be faced with the challenge of figuring out who
is who, amid a group of users for whom you have no record in your existing security
infrastructure. To deal with the security challenges inherent in securing third parties,
an SOA security solution can utilize federated authentication. Federated authentication
is a process by which multiple parties agree that a designated set of users can be authenticated
by a given set of criteria. Users of the federated authentication approach can
create a Federated Identity Management System, which is a sort of pool, of authenticated
users. The SOA security solution can authenticate a user by checking with the
Federated Identity Management System. In other words, a “federation” of systems,
communicating with one another, can agree that certain individuals are okay.
In some cases, the authentication process will result in the SOA security solution
creating a Security Assertion Markup Language (SAML) assertion that expresses the
authenticity of the user in a way that will be accepted by the web service that the user
is invoking. SAML is an XML-based standard that provides a framework for describing
security information about a user in a standardized way. WS-Security is the name
given to the set of security standards that have been ratified to date. Many SOA security
solutions take advantage of these emerging security standards. As shown in
figure 8, the SOA security solution can intercept the SOAP message, and then route
it through an authentication process wherein the user is authenticated. Then, the SOA
security solution passes the SOAP message along to the destination web services, but
with a SAML assertion tacked on. Note: SAML assertions do not rely on federated
Figure 8 To use federated authentication in SOA security, the SOAP
interceptor must forward an incoming SOAP message to a security solution
that checks the identity of the user contained in the SOAP message header
with the users listed in the federated authentication database. Once
approved, the SOA security solution creates a security “assertion” that the
user has been authenticated in a Security Assertion Markup Language
document that is appended to the SOAP message as it travels to the web
service it was intended to invoke.
One highly effective way to protect the security of core systems is to avoid letting anyone
reach the service hosting platform. This can be done by deploying a proxy for the
web services within your SOA. As shown in figure 9, a secured proxy can receive and
respond to all web service requests on behalf of the actual web services, and is therefore
protected from malicious intent. An added advantage of the proxy approach is its
ability to reduce the load on the enterprise’s security infrastructure. Instead of generating
a lot of message traffic across the network to authenticate and authorize each
user every time it wants to invoke a web service, the proxy reduces the traffic by centrally
managing and caching the authentication and authorization of web service
requests. The proxy also inserts the authentication and authorization SAML assertions
into the message, thereby eliminating the need for the actual web service instance to
query the security system directly.
We’ll spend a lot more time on this subject in the next chapter, but contract management,
which is primarily an SOA management issue, also plays a significant role in
SOA security. A contract is a set of rules that governs the use of a web service. For
instance, a contract might stipulate that a particular user has the right to invoke a specific
web service ten times per day. And, upon invocation, the service level must meet
certain parameters, such as a one-second response time.
In security, contracts are helpful in determining whether the SOA is functioning
properly or whether it is being misused due to a security breach. As shown in
figure 10, the SOAP interceptor sends the web service request and response data to
the SOA security solution, which then calculates whether the contract has been met
or broken. If a security problem, such as a DoS attack, has slowed a web service to
the point where it is not meeting its contractually agreed-upon service levels, the
SOA security solution can alert management that there is a possible problem. Of
course, a severe enough attack could bring the whole network to a halt, but the
Figure 9 The web service proxy helps secure an SOA by handling the
SOAP message traffic, reducing the load on the enterprise’s security
infrastructure and protecting the web service from malicious use.
Figure 10 The SOA security solution monitors service levels and
sends an alert when a security problem has caused a web service to miss
its contractually set service level.
security solution would at least have the capability of issuing a notification that
something is wrong.
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.
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, 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
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
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
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