Over the past five years, an "alphabet soup" of new Web Services Security specifications, standards, and buzzwords has been thrust upon the technology scene. As we have watched the evolution of many Web services security specifications, it has sometimes been difficult to wade through the murky and dangerous waters of implementation patent issues, vendor wars, competing specifications, and challenges of interoperability. These waters have thankfully become clearer over the past few years, due to vendor agreement and some diligent work in standards organizations such as OASIS and the W3C. Mature specifications have emerged and have become (or are now on their way to becoming) standards. As a result, many standards-based Web service security toolkits and implementations have been shipped that allow developers to build solutions quickly. That's the good news!

Is there bad news? The bad news isn't tragic, but it must be stated. Because it is relatively easy to use these new products to build security solutions without a security background and without looking at the big picture, it's easy to develop a security solution that is over-engineered, complex, poor-performing, and possibly even insecure. Because our current tools are focused on ease of integration, the use of these tools may not require any background in information assurance or information security techniques. As a result, bad solutions can and will be developed. In meeting this challenge, we must underscore the need to focus on the "A" in SOA, the essential tenets of information security, and a few common sense rules.

This article will build on six basic, common sense rules and best-practices that you can follow as you are building your SOA security solutions.

1)  Plan Ahead
A major pitfall occurs when architects wait until the last minute to plan for security. This happens more than we would like to admit. Either requirements aren't plainly stated and the team is surprised at the last minute, or someone makes a deliberate choice to worry about security later. Many times, our focus is on designing, developing, and testing core functionality of our services, and a security focus is not scheduled until a few weeks before deployment. The standard model of Web Services Security SOAP messaging appeals to designers and developers because of the logical separation of security data in the SOAP header and business data in the SOAP body - and therefore, the physical separation of security logic in security handlers and business logic in the main Web service code. Unfortunately, this separation also provides an unacceptable excuse to worry about security later.

For your project, it is absolutely vital to determine your security requirements very early in the project. Based on those requirements, you can then delve into how you are going to satisfy them. A good requirements analysis phase is absolutely necessary because most customers may simply say "Just make it secure!" From the beginning, you will need to determine what requirements may exist for authentication, authorization, integrity, non-repudiation, auditing, and confidentiality. Talk to your customers and end users and find out who will be levying security requirements. Once you get with the right people, either work with them to gather security requirements or help them determine what their security needs are. The key point here is to make sure that you find out the true requirements at the beginning of your projects in order to make the appropriate design decisions early.

2)  Know the Enterprise Infrastructure
As many of us are developing our applications, we often forget about the environment in which we will deploy our solutions. As we architect our security solutions, we must never architect in a vacuum or assume anything about the existing enterprise security infrastructure. Security-wise, there will undoubtedly be systems such as LDAP directory servers, policy servers, and Public Key Infrastructure (PKI), with which you will have to integrate. This enterprise infrastructure may dictate much about how your system will operate. Issues regarding connectivity, credential management, policy and privilege management, user authentication and authorization, and auditing may be affected by the existing infrastructure. This gets back to our first point - plan ahead by asking the right questions as you begin your project. Do not assume anything about the infrastructure; make sure to know your enterprise integration points.

3)  Stick To The Standards
For those of us who had to develop Web services security solutions in the caveman days (three to five years ago), many times we had to play the role of amateur cryptographer because the secure messaging standards had not yet been developed. As a result, many of us have grown accustomed to tinkering and creating our own "secure" messaging concoctions. This may not have been the best thing to do then, but it is definitely the wrong thing to do now.

Now that there are accepted standards - such as WS-Security and its associated token profiles used for identity propagation (WS-Security SAML Token Profile, WS-Security X.509 Token Profile, WS-Security Username Token Profile) - as well as emerging specifications in standards bodies (WS-SecureConversation, etc.), there should no longer be any reason to create a home-grown security messaging syntax. Certainly, you must be able to understand the purpose and use of these standards and security specifications in order to meet your security requirements, but you need to avoid creating home-grown protocols. In addition to the problems that you will have down the road involving lack of interoperability with other systems, any non-standard solution created by wannabe cryptographers will most likely have security vulnerabilities that could come back to haunt you in very ugly ways. We have standards for a reason - embrace them.

4)  Think Like a Security Guy (or Hire One!)
If you are developing a security architecture for a SOA that involves sensitive, proprietary, or highly confidential information, you will either need to be well-versed in information security and the current standards, or you will need to hire a security professional. Understanding the fundamentals of information security will be necessary not only in determining the security requirements at the beginning of your project, but also for designing the architecture, testing, and - if necessary- getting through the proper certification and accreditation processes.

Although you can lean on the WS-Security standards and toolkits to do the hard work for you, many of these standards have multiple options that you will have to study and select, based on the security requirements of your system. Most Web services security solutions must be able to thwart message replay attacks, protect availability, and, depending on the requirements, provide some or all of the classical security goals: authentication, authorization, confidentiality, integrity, and non-repudiation. Remember that the Web services security standards may not be intuitive for those who have not had an information security background, so make sure your people are educated in information security.

5)  Remember the Nature of Web Services
In a large SOA pilot four years ago, initial tests showed that all Web services were functional and operating normally, so the developers were relieved. When there were errors related to access control, a Web service would throw a SOAP fault. The problem? In this particular environment where much Web service chaining was happening, it wasn't always quite apparent which service threw the SOAP fault, because the SOAP fault contained very little information. I remember calling the administrator of the first Web service on the phone, asking him if he could look in his logs to see why the SOAP fault was thrown. Then he told me that his Web service didn't really throw it, but that his Web service programmatically called another Web service, which must have thrown the fault. I then called the administrator of the next Web service on the phone to get more information. It goes without saying that the process got old quickly.

We can still have similar problems today if we do not understand that Web services are essentially "black boxes" with published interfaces, and that they will be called and used together in ways we may not always anticipate. Web service chaining and orchestration should therefore be expected, so you must understand the distributed and dynamic nature of Web services. In planning for this from a security perspective, you need to focus on Web services transaction management, centralized auditing, and detailed, descriptive error handling. This relates not only to Web services security in regards to auditing, but also to Web service management.

6)  Understand the Double-Edged Sword of Cryptography
Cryptography is a mechanism that we use to achieve most, if not all, of our security goals. It is with cryptography that we achieve authentication, confidentiality, integrity, and non-repudiation. At the same time, we must acknowledge that cryptography is performance-intensive, which could slow down systems and lead to problems with availability and denial of service. The double-edged sword is that cryptography - when done right - is a friend of security, but cryptography always has a negative impact on performance. Think of a seesaw with your security goals on one side, and your goals of performance and availability on the other. The key thing is to keep things balanced.

Sometimes engineers forget about the high cost of cryptography when they choose to secure services that don't need securing, or when they apply unnecessary cryptography. I once saw a solution where the body of every Web services call was signed by the caller with XML Signature, encrypted to the recipient with XML Encryption, and each Web service client initiated an SSL connection to each Web service for every request. What was the biggest problem (other than the redundancy of encryption for each connection)? The back end Web services were reading bytes from a public Internet Web page, so the developers used a lot of cryptography to encrypt, decrypt, sign, and eventually validate the signature of publicly available data that had no assurance of integrity. Essentially, they created a very slow SOAP-based alternative to HTTP!

In planning your SOA security solution, it is absolutely essential to be wise and deliberate about the cryptography you use. Going back to the first rule (Plan Ahead), it is important to truly understand your security requirements. If there is no requirement for confidentiality, then you shouldn't use encryption! If there is only one part of your message that is sensitive, then perhaps only that part of your message should be encrypted. If you need to encrypt everything between two points only, consider using SSL. If you have a requirement for technical non-repudiation, then using XML Signature in your WS-Security messaging is a valid choice. Realize, however, that all cryptography will have a performance cost and will affect the scalability of your system. If you have serious cryptographic needs in solving your security requirements, consider using hardware acceleration products that do the cryptography and XML processing in the hardware. The use of cryptography should be intentional, based on your requirements, and you must plan ahead for its impact on performance.

Conclusion
Diving head-first into detailed implementation issues involved in SOA security, it is truly easy to make mistakes or become overwhelmed if you don't initially focus on the big picture, beginning with understanding your true security requirements, understanding the fundamentals of information security, and understanding the proper use of Web services security standards. This article has attempted to capture this big picture by providing six common sense rules to use when planning and developing SOA security solutions. Above all else, it is important to focus on basic project management, security architecture fundamentals, and common sense!