Do I Need to Secure My Service?

I sometimes get asked by customers whether they need any security at all for their “internal services”. I wanted to take a post to examine this subject.

Let’s take the simplest case possible from a security vantage point: a synchronous web service being called from a limited number of trusted internal clients (let’s say web applications). Because the web service is synchronous we don’t have to worry about the request sitting in a queue unprotected. Likewise, because the web service is being called from a limited number of internal clients we might be inclined to care less, if at all, about ensuring that users/clients are authorized to call the service. Finally, we will assume that there is no requirement to authenticate a “user” of the client invoking the service.

At the same time we will assume that the service is a “high value” service such that exposing it to the “outside” without security would be a mistake.

So, does such a service need security?

I think to answer this question we have to look at all the possible security concerns for such a service and how they can be addressed with or without explicit security. Usually, when a customer implies that their service doesn’t mean security what they are really saying is that the boundaries of their physical network providing all the security they need. So, let’s look and see to what extent that may be true.

The security concerns for an internal, synchronous service are as follows:

1) Client trust: ensuring that only authorized users/clients are invoking the service.

There are two types of potentially unauthorized clients to worry about, internal clients and external clients.

To protect against external client access physical network boundaries may be sufficient.
However, in my experience an increasing number of customers are not comfortable relying on their physical network.

Without additional security, the only protection against unauthorized internal access to your services is the trust and good will of the users that have access internally.

Two-way SSL is a straight forward, easy to deploy security solution that you can add to your web service that provides strong protection against all types of unauthorized client access. Note though, that one-way SSL does nothing to help with this case.

2) Service trust: ensuring that the service being invoked by consumers of the service is authentic; that it is not a Trojan horse service.

The physical network does provide some level of protection here in that a malicious Trojan service would have to be accompanied by IP address spoofing or DNS hacking to do damage. The greater danger might be the standing up and advertising of an unauthorized service for a SOA phishing attack.

Here SSL (technically just one-way) can help ensure that only authorized services are being called by clients.

3) Message integrity: ensuring the message has not been tampered with.

The physical network can limit the potential for capture, alter, and replay attacks to internal users but SSL can be added to eliminate all risk associated with capturing messages over the wire.

4) Message confidentiality: ensuring that the information in the message cannot be intercepted and read.

The physical network can limit the potential for message capture to internal users but SSL can be used to eliminate all risk of capture over the wire.

5) Tracking and reporting: ensuring that the ability exists to track specific requests/transactions to a specific user/client.

Without additional steps the only tracking mechanism provided by the physical network is the IP address of the client which may or may not be of use.

When you add 2-way SSL with each client getting a unique client certificate, you now have definitive record of which client made which request.

6) Identity propagation
If there is a requirement to propagate the identity of the user of a web application onto the web service then there is potentially additional security required.

Given the assumptions made at the beginning that the consumers of our service are trusted internal clients, we will assume that we can trust them to propagate whatever identity they want. Still, the propagation has to be done in some fashion.

Here we have 3 options:
1) The identity could be added through a custom HTTP header. This is easy on the client and secure if we trust the client and are using 2-way SSL at the transport (the header can be encrypted with symmetric cryptography for added security). On the downside it is very non-standard and will most likely require some custom work on the service side to accept an identity from a custom header.

2) The use of a real WSS Security header such as a SAML assertion. Using SAML with the bearer confirmation method (http://fusionsecurity.blogspot.com/2009/09/bearer-confirmation-method-huh-what-is.html) provides a more standard way of propagating a user identity. With bearer, no messy signing or encryption is required and given our assumptions the security of bearer is probably sufficient if 2-way SSL is being used. The only gotcha is you have to have client and server side stacks that can both “speak” SAML bearer.

3) Many customers ask/talk about just putting the user identity in the body of the message. In many ways this is the easiest thing to do. I also think it makes sense if the business logic of the service will actually make use of the user identity information; as would be the case for a “process insurance selection” or “purchase ticket” service. The only thing to understand is that putting user identity information in the message body means including it in the schema and explicitly coding how to retrieve it in the service. If you rely on WSS security for user propagation then the user identity can be left out of the schema and the service can be coded just to get the identity from the container.

When identity propagation comes up in these conversations, the discussion usually centers on using SAML vs. just putting the user info in the message body. The key deciding factors here are whether the user info will be used by the business logic of the service, whether you want to include the user info in the schema or not, and whether you are comfortable with the code of the service itself retrieving the user identity from the message or whether you’d rather rely on getting the user identity from the container.

Summary
On a very restrictive physical network where trust in the users that have access to the network is very high, it may be OK to deploy a high value web service without additional security. However, most of the time it is a good idea to utilize 2-way SSL to provide strong transport level security.
If identity propagation is required a judgment call needs to be made on how to propagate the identity and whether or not to do so through transport security, WSS message level security, or just in the body of the message.