SOA Security – A crystal ball?

Well, I hope not. The enterprise architecture should always consider the security aspects of various systems – authentication, authorization, audit trail, and non-repudiation. These fundamentals do not change when extended to SOA. Any SOA implementation should address these concerns. As this article suggests, there are multiple competing standards when it comes to SOA security and I personally believe that it is a good thing (at least in the beginning). Competition keeps vendors on their toes to follow a standard that works well and satisfies customers' needs. Loose consensus over rigid agreement works well for standards. CORBA is a good example of that. It took a lot of people many years to come up with this bloated standard and eventually what people got as a standard was a superset of all the possible features that addressed all the OMG members' needs and satisfied their egos. The end result was a comprehensive but useless standard.

In the SOA security world, there are competing standards, but they do not compete at the same level. If you are using WS-Federation, you can still use SAML tokens and if you are using SAML you can still use Liberty Alliance standards. All these standards will evolve and eventually the one that works well, and easy to use will win. I understand that organizations have concerns over investing too much into single identity management standard, but that does not justify organizations not investing into any security standards at all.

The companies are hard-pressed to open up their services to their partners to stay relevant in this competitive market. Don't listen to your IT department if they use the security card to scare you on your SOA efforts, instead work with them and prototype few simple ad-hoc federation solutions before venturing full-throttle into hub-and-spoke or complete identity federation solutions. This is similar to a kid learning how to bike. Use the training wheels, get rid of your fear, and once you understand how security works, get rid of the training wheels and go for a full-fledged solution. SOA security should not be a crystal ball; do your homework, follow your SOA governance and decision making framework, and most importantly have faith in your decisions – you will be fine.