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: services, SOA
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.
- Service Level Agreements- the SLAs available for the service should be listed out so an architect or program manager can search based on what is compatible with their system needs.
- Security - what kind of authentication is needed for the consumer to implement. Here's where you get all the various metadata that tells potential service consumers the kludgy way that userids. Until an enterprise gets their single sign-on, SAML compliant wonderland authentication framework in place, you can look to the registry to see if a service needs basic auth (and where to get a userid), digital certificates (and where to get a cert), custom headers, etc etc.
- Data classification - what kind of data is passed in the service. I'm currently dealing with this in the public health sector as there are special regulations that kick in when you deal with Personally Identifiable Information (PII).
- Endpoint - of course this is in the WSDL, but for non-WSDL services, you have to have the endpoint.
- Service Interface/Schema - again, another item in WSDL, but this needs to be available for POX, etc.
- Examples & Documentation - essential to have links to example client calls and user documentation on how to use the service. This sounds like a no brainer, but every time I've had a "WSDL only registry" there is always reams of extra work that goes into demonstrating how to call the service. An even better way of documenting the service is to provide test programs/classes that a potential user can download and play around with. Don't assume that all your users have fully licensed SOA tools.
- Approval Level/Rating - this should show what approvals and governance checks the service has gone through. Is this a demo service? Or does it meet all the necessary service characteristics that the service governance center came up with. Think of this as a stamp of approval. You don't have to limit this to just a formal approval, think of a digg/reddit type rating where users in your systems can add their thumbs up to a service. Word is going to get out if developers across your company like the service anyway, make it easier for them.
- Providing organization- who built this service. This is especially important in a federated repository where it is not necessarily clear who is responsible for maintaining a service.
- Version/last updated - not only showing the current version but other related versions.
- Timeliness- how long is this version guaranteed to be supported.
- Keywords/tags - service provisioners should add keywords to allow for easier searching and finding of related services.
- Usage statistics- how many executions per time period, average time of execution. Stuff like this. Implement service performance measurement and publish the results as part of the registry.
- RSS for updates and announcements - allow consumers to subscribe to a service's feed to see when a new version is coming out, known issues, etc etc.
- Cost/chargeback model- if your enterprise charges for services (which has its pluses and minuses as Nick Malik pointed out) then go ahead and show it as part of the registry. Buy 1,000 transactions, get 1 free.
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 email@example.com
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.