SOA Security and SAML – Maturity Defined by Usage Not Time

Gerald Beuchelt ridicules my post on SOA security in his reply, Where is the problem? In particular, Gerald takes aim at my statement that SAML, and other SOA security standards, are immature, stating that SAML has been around since 2001.

I agree with Gerald that, if you measure maturity by time (as he does in his reply), then SAML could be considered “mature”.

On other other hand, I am measuring “maturity” by actual usage, and the proof of security solutions is in the actual adoption, not simply years of standards activity and vendor marketing.

For example, here is a WS-Security related quote from Michael Meehan, SOA standards searched for maturity in 2005:

“You can find WS-Security in all SOA products, but almost no one’s using it,” said Burton Group Inc. vice president and research director Anne Thomas Manes. “It’s amazing how few people are using it.”

The same is true for SAML and other security standards for SOA. Yes, there has been a lot of activity for a number of years, and vendors include the products in their sales portfolio, but very few people actual use it to build secure applications.

I measure IT maturity by actual usage. For example, HTTP, SSL, SNMP, IPSEC are “mature” in my opinion, they are used worldwide. SAML, and most of the other SOA-related security standards, are not.

Advertisements

4 Responses to SOA Security and SAML – Maturity Defined by Usage Not Time

  1. Hi Tim –

    I took the liberty to reply to your comments …

    http://beuchelt.blogdns.net:8080/SAMLsMaturity.aspx

    Best,

    Gerald

  2. Tim Bass says:

    Dear Gerald,

    Thank you for taking time to reply.

    Based on your own excellent descriptions and discussions of SAML, at best, SAML is in the embroyo stage or “early adopters” phase.

    Even the Liberty Alliance, while a great idea, has not had a major impact in the day-to-day operations of most people doing day-to-day business on the web. Yes, you can point out some patches of success here-and-there; but this does not define “maturity”.

    I have traveled the globe working with clients and very few of them are passionate about SOA, as you are. Most people are looking for simple, secure and cost-effective methods and technologies to do EAI.

    Services? Yawn.

    Most of what businesses really need can be accomplished without a complex security stack with open protocols that are relatively immature compared to other technologies that have been around for many years.

    Yours faithfully, Tim

  3. Tim –

    Thanks for your reply. I guess I will agree to disagree: I appreciate your customer experience and the conclusions you draw from this. However, my experience is somewhat different, especially in current, forward looking projects:

    My partners and customers appreciate that the creation, deployment, and operation of a federation is anything but trivial. Nevertheless, any major project I have been working on over the last 2 year had federation as a requirement. Cross-technology interoperability issues were among the most serious technical problem. However, non-technical issues have been at the core of any federation hold-up, among them being privacy, regulatory concerns, liability and arbitration provisioning and more.

    Is it possible to solve current business problems with older (or more mature??) technology? Certainly. Yet, avoiding the “adopt potentially immature technology” risk is then mitigated by taking a “paint yourself in a corner with old and over-customized technology” risk.

    In my experience, it depends pretty much always on the type of organization or customer which of these risks is more acceptable to them.

    Best regards,

    Gerald

  4. Tim Bass says:

    Dear Gerald,

    Forward looking, future plans do not define a mature security protocol, in my humble opinion. Just like cryptographic systems, maturity is defined over proven usage and hardening over a long periods of time with a large user base. I guess we do agree to disagree (however, I think we actually agree more than our blogocomments indicate).

    Regarding federation, you might be pleased to know that I helped coin the use of the term federation in the DoD around 7 years ago and helped introduce SAML at that time (I have an old deliverable paper I co-authored on cross-domain federation somewhere on my hard drive). So, I have a background of many years of experience with identity federation.

    And yes, the core issues in IT are always non-technical; which means that just because a technology is sophisticated or elegant, that does not necessarily lead to social and political acceptance in organizations. Remember GOSIP? That was more elegant that the TCP/IP stack, but GOSIP eventually was buried.

    Most SOA implementations do not require cross-domain federation because organizations are using SOA for internal EAI – and even then, they are having trouble getting their arms around SOA security even without SOA federation!

    I agree that IT adoption depends on the organization and their risk management strategy. The fact of the matter is that most of the buzz about cross-organization, federated SOA is simply utopian hype. Most organization are still struggling with basic EAI – they live in a dystopian political and social IT culture.

    In other words, in most organizations, the films that are the best metaphors for their IT culture are Blade Runner or Brazil, not The Brady Bunch.

    There are exceptions, of course, but for the most part, SOA is simply too complex for most organizations with mere humans and average wages operating the network and the IT. The risks with these “forward looking” protocols are high, too high for most companies, that is one reason why adoption is so slow and the actual user base is so small.

    Federation? We all can agree that this is really a great idea. So is world peace, that’s a great idea too. Most organizations have political problems with basic EAI and SOA in their own administrative domain, much less trying to federate across organizations and cultures.

    Peace.

    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: