We started with the bit of advice "only make them as secure as you need to". In other words the "HelloWorld" service probably doesn't need an encrypted request with a signed SAML Assertion over a mutually authenticated SSL channel on a private, physically disconnected network segment. And the "launch nuclear weapon" service should probably be secured with something other than a simple username token.
Figuring out what sort of security your services require takes time and effort and lots of information. So I'm not going even try to give you a recommendation here. Instead I guess I'm going to tell you what I told them...
This customer has requests coming in from the Internet. Their users do NOT have individual certificates but do have a username and password. The plan, in as much as there is one, is to have OSB in the DMZ accept the SOAP request from the user and then route it to the real service behind the firewall. So the customer asked us what they should do to secure the services.
They tossed around a bunch of ideas including:
- using an STS - the client would go to the STS and get a SAML assertion, then use that assertion to send the request to OSB.
- using an STS with WS-Secure Conversation - same as above, but instead of just getting a SAML Assertion the client would do the more advanced session "stuff" that spec describes.
- Publishing a certificate issuance SOAP endpoint. The SOAP client would call over to that service with a username and password and get a Certificate issued. The username and password would then be locked out and the Certificate would be the only way the user could authenticate after that point.
Turns out their requirements were that the data had to be transmitted securely - meaning nobody else could listen in and see the data. And they wanted to make sure that nobody could inject requests that didn't come from a real user into the flow. And that's it.
Those of you playing along at home know that one way SSL with the username and password in a WS-Security header meets those requirements. Plus it's really lightweight and simple to implement.
Sometimes simpler is better. And in this case turning all of the security levers up to 10 wouldn't have bought them anything but trouble.
So that's what they're going to go with - at least initially. In the future they'll revisit this solution and if things change they can always add new Proxy Services on the bus for other authentication methods.
Behind the bus was a whole 'nother story. They're going to use SAML assertions with the Sender Vouches confirmation method to pass identity down to the real services. But that's a story for another day.
Posts
