Web service security through depth
I'm working on a project that uses the Globus Toolkit as a secure service container. Globus can be more effort than necessary to run services, but it provides a solid security stack that uses digital certs and mutual authentication through SSL for authentication and encryption. Two-way SSL is rather secure and usually doesn't raise too many eyebrows.

However, one of the security analysts insisted this was insecure because you could use an HTTP reverse proxy between the user and the service. His reasoning was that you can't put the service container in the DMZ as it is too much of a security risk. Instead you put a web server (IIS or Apache) in the DMZ and have it proxy all traffic directly to the service container.

This is frustrating for several reasons:
1) increased cost and complexity - I generally like KISS
2) Limited increase in security. A configuration I usually use is to have the app server in the DMZ and the database inside the local network. The external firewall limits all traffic to 443 (or 80 if you have plain HTTP), protects against DoS, etc. etc. The vulnerability is that someone could compromise the app server if there is some exploit that works on 443 or 80. But with a reverse proxy, everything is forwarded on to the app server, so you can still exploit any 443/80 vulnerabilities even if the app server is within the local network. In fact, this is a greater risk because now someone has compromised the app server inside the local network, rather than a server in the DMZ.
3) Having an HTTP server proxy SSL sessions means that there are now 2 SSL sessions. One between the user and the HTTP server and then one between the HTTP server and the service. This is not only a performance problem, but now you have to delegate the user credentials. This means that the service can't use stuff like mutual-authentication with users because the proxy server is a man in the middle (although one under benevolent control).

So, what I've been doing is asking everyone I know who designs web services if this isn't stupid. So far I've had 4 architects from 4 different companies say that this configuration is unnecessary and that they don't do it.

In the meantime, we're going to use web services without an HTTP proxy server. It seems NIST is on our side, so I'm hoping we'll be able to withstand the "We must triple encrypt stuff" crowd.

Labels: ,

  SOA Registries- What I need
I was cleaning out my briefcase and found some notes I had written down about what characteristics I need in an SOA registry (or repository if you're one of those people).

I've seen almost all of these features spread out across a couple of different products, but I think eventually you will need these in order to have a successful SOA implementation. Each of these items deserves a whole post, so I'll keep it brief in this post.

A last note before I start enumerating is that I think SOA Registries are more useful at the private/internal/enterprise rather than the outdated public UDDI model of 5 years ago. Registries needed to enable an enterprise's modular development, but aren't required for locating public services as it's pretty much impossible to get all the different providers together in one registry.

So that's a couple of useful things that I'd like to see in my service registry. It goes beyond what some of the big vendors are selling by adding in some user centric features. Don't think that this is all based around bottom-up as there is still governance and all the other stuff that goes into the review a service is put through so that it can make it into the registry.


  IBM SOA Certification
IBM announced two weeks ago that they would launch a free 12 week SOA mentor program to their IT certification program.

Just email to register for the program. There's a real world meeting on Sep 12, but everything else is through email and webex.

You still need to pay for the exams, but free classes are cool.


My google alert picked up Stefan Tilkov's post agreeing with Radovan Janecek's Anti-SOA post. So I will add in my own equally valid opinion to this chain.

To recap, Stefan and Radovan think that commonly accepted infrastructure pieces like ESBs and BPEL are actually detrimental to SOA.

While some of their points are accurate (encouraging P2P service communication rather than funnelling all SOA traffic through gateways or intermediaries), the term Anti-SOA is just provacative.

ESB/WSM/BPEL are all valid components of SOA infrastructure because they all serve valid purposes. Trying to create and maintain a single ESB or a single BPEL engine is fruitless, but so is trying to build a highly available, extreme transaction environment without orchestration, transformation, reliability, security, etc that these tools provide. (sorry about the run on).

My experience is that if you try to deliver on a good SOA without providing the appropriate infrastructure and tools, then you will fail. If you try to create a solid governance policy without delivering the support that you find in ESBs and Registries then it will make your task that much more difficult.

My take on ESBs is that they are a good place to run services and they provide a lot of needed infrastructure (security, transformation, reliability, persistence, orchestration, on and on) that you need to implement somehow. ESBs should not be treated as the end all service environment for an organization and should be designed to work with external and internal partners (especially since that line is getting blurred more and more) services regardless of what kind of implementation provisions and executes the services.

At the end of the day, an organization needs the services provided by an ESB or a BPMS or a Registry/Repository or a Management System. But it is just one piece of the SOA implementation. If a vendor comes by and says ESB = SOA then question loudly and frequently.


Technical and personal notes from Brian Lee, technologist/enterprise architect/software developer/soa guy.

February 2005 / March 2005 / April 2005 / May 2005 / June 2005 / July 2005 / August 2005 / September 2005 / October 2005 / November 2005 / December 2005 / January 2006 / February 2006 / March 2006 / April 2006 / May 2006 / June 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / January 2007 / May 2007 / June 2007 / August 2007 / September 2007 / October 2007 / April 2008 / July 2008 / January 2009 / May 2009 / June 2009 / September 2009 /
My Photo
Name: Brian Lee
Location: Atlanta, Georgia, United States


Powered by Blogger