Flattening the Treacherous Journey

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Bill Dettelback's Blog | August 14, 2007   6:23 PM | Comments (1)

Andy Dornan has a good bird's-eye look at the SOA Security landscape in his recent article, "SOA Security: One Treacherous Journey".  I like how his argument is laid out that these are (at best) confusing times for enterprises who want to open up their services to partners outside of their existing trust domains.

After I read the article, I was of mixed feelings.  Is it really that hard?  Have we software vendors really let down our customers with standards implementations that are incomplete, incompatible and downright hard to use?  Working for a software company, it's easy to get into a mindset that your hammer is the solution to everyone's problem.  I talk to a lot of customers and I'll freely admit there have been times when I had to bite my tongue rather than blurt out a hasty answer before they got done telling me their problem.

So after I thought about it, I had to agree with Mr. Dornan- it is hard right now for our customers.  The SOA Security landscape is incredibly fragmented, inconsistent and hard to understand.  Sure, it will get better over time, as standards evolve, implementations harden and adoption grows.  So what can we do to shorten the treacherous journey that Mr. Dornan has outlined?

Something wasn't sitting right with me when I considered his arguments.  He has identified message level security and federated identity as two of the harder SOA Security problems to grapple with.  But I think he's missed another one- access control.  To Mr. Dornan's credit, he does mention authorization in passing, as part of a WS-Security discussion.  But the problems he's talking about are all plumbing issues, e.g. how do we make sure your partner's connector fits into your receptacle correctly and securely?

There is another leg to the treacherous journey just around the corner- entitlement policies.  After all, once you've verified identity, and correctly decoded the message, who's to say this person has any business at all using this service in the first place (WS-Policy notwithstanding)?  Even worse, how can the service know how to make finer grained decisions based upon identity and message payload once it's started executing?

I believe that once we get the SOA Security plumbing issues all ironed out (someday), we're in for another crop of issues around federated entitlements policy.  Standards like XACML are helping to establish the format for how we can share an entitlement rule.  But I wonder how we're going to make it easy to share policy semantics between organizations.  When you mention an invoice in your policy, do you mean exactly the same thing that I do?  I can foresee a time when a company might not just need to securely share their services, but also share their access control policies.  Share my sensitive security policies with strangers?  Why in the world would I do that?

Currently, I'm reading Thomas Friedman's book, The World Is Flat.  His premise is that the global playing field has been leveled by multiple recent forces (I'll let you read the book to find out what they are). He says we must recognize that countries like India and China are now providing so many services for US companies that we all exist in a much flatter global structure.  But it's not just leveraging low-cost labor.  One of his most striking examples is how so many companies today are actually running their business via strategic partnerships with other firms- he cites United Parcel Service performing laptop repair for Toshiba (in addition to picking up and delivering your fixed machine) as an example.  Think about that- a major electronics manufacturer outsourcing logistics and technical repair services to a company we typically think of as an alternative to the post office.  Imagine the trust relationship you need in that sort of arrangement!  Now giving your repair work to a partner is one thing, what about outsourcing your billing, or inventory management?

In the truly flat world, there is literally nothing you can't outsource to a strategic partner.  What sort of security policy collaboration and exchange needs to take place when that happens?  If we think the federated identity challenges are big now, just wait.

I advise everyone to take a look at Friedman's book (it's readily available in paperback- I picked mine up at Costco for $9).  I even want to start reading it to my 10 year old son at night to prepare him for the world in which he's going to be employed.  But that's another story...

Comments

• Hi Bill,

  Below is a model I am trying to put together in my head:

  SOA Security = WS-Security + SAML + XACML

  We could extend that to include an generic place holder:

  SOA Security = WS-Security + SAML + XACML + CustomStuff

  What do you think?

  --alex

  Posted by: atoussai on August 15, 2007 at 9:57 AM