Solutions to SOA Security
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 authentication processes.
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.