 |
Over the past five years, an "alphabet soup" of new Web Services Security specifications, standards, and buzzwords has been thrust upon the technology scene. 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. |
 |
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. 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.
|
| |
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.
|
| |
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. We have standards for a reason - embrace them
|
| |
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. 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.
|
| |
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. 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.
|
| |
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.
|
| |
(This is an abstracted version of an article published by SYS-CON Media. The full, original article can be found here.) |
|
| |
| |
 |
| |
|
|
