PEPE's Dream Factory

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

Click here for a larger image.

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.

Application proxy

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.

Contract management

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.

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,

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.

Summary

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.

---------------------------------------------------

OWASP 프로젝트 사이트에서 어슬렁거리다가 동물적인 직감(?)으로 엄청난걸 발견했다.

아직 국내에 완벽하게 상륙하지 않은 서비스 지향 아키텍쳐(Service Oriented Architecture)

SOA의 Security에 대해서 언급하고 있는 페이퍼다.

아직 뉴비 아키텍트에 해당하는 나로서는(ㅠㅜ) 문제의 본질부터가 파악이 안되지만,

앞으로 스터디할때 유용하게 쓸 수 있을것 같다.

뛰는놈 위에 나는놈 있다더니..

IT의 기술변화는 정말 엄청난 속도를 다투는것 같다.