SOA Security (Part 2)

Yesterday I was taking apart office furniture, preparing for my move to Asia, and a heavy wooden board slipped off the top shelf of my tall bookcase, hitting me in the head about an inch above my eyebrow. Ouch!

This sounds like a good time to pause and talk about SOA security, which can be quite a headache as well.

Before we get into the technical details, let’s fly up and take a 30,000 foot view of SOA security and tell a few “war stories.”

First of all, as mentioned in Part 1, most of the technologies associated with building a loosely coupled, federated, modular service-based distributed computing environment have little or no built in security functionality. Furthermore, since they were designed, for the most part, to piggyback on plain ole’ web transactions, the firewalls (gates) are open.

In fact, as most will recall, SOA – web services style, was motivated by the success of the web and the desire to expose functionality as a web service so folks would not have to do screen scrapes and other odd mashups. The grand vision was that organizations would expose their web APIs as services, place the descriptions in an electronic yellow pages directory service (registries) and web application developers would find them, and (hopefully) (re)use them. Nice idea, but it really did not go as far as folks envisioned.

So, what happened?

Well, folks started to view SOA as an internal integration platform and shifted the SOA focus to intranetwork integration versus the original lofty promise of cross-organizational Internet integration. In other words, since SOA was a bit too ambitious for the difficult cross-trust relationships between different companies, the implementation model shifted to using SOA technologies within an organization where the trust models are, in theory, less complex.

At the same time software companies found a great opportunity to sell security software for SOA (and make money) so the market has been buzzing, for quite some time now, with SOA security tools and technologies. The result for SOA has been simple and expected:

  • Lots of hype, positioning and promises by vendors; and,
  • Very slow adoption due to security concerns by businesses.

In my next post, SOA Security (Part 3), I’ll write about my experience as the lead architect for the world’s largest fully meshed virtual private network (VPN), built (unclassified, don’t worry I will not give any any secrets!) for the USAF. There are valuable lessons to be learned from this experience, a project from 8 years ago, when looking at enterprise SOA security.

Advertisements

2 Responses to SOA Security (Part 2)

  1. Opher Etzion says:

    Hi Tim. Interesting. To be fair I would say that there are large variety of reasons for the slow adoption of SOA, security concerns is indeed one, but not the only one.

    stay well and keep your head.

    Opher

  2. Tim Bass says:

    Hi Opher,

    I agree there are many reaons, of course. Security concerns are one of the largest, based on my operational experience.

    Certainly service definition, granularity and other points of confusion that are linked to politics and funding (politically similar to security concerns) are critical as well.

    Yours faithfully, Tim

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: