Securing a Web Service

[M Jay]

Hi,

I am part of a project that aims to SOA enable my organization. This is being achieved through Web Services and the use of an ESB. We now have a requirement to expose one of our Web Services onto the internet to be consumed by a number of mobile devices - this is not a public service, but a third party organization will invoke our service from a number of mobile devices. How can we make sure that our web service is secure? Would using SSL with Client authentication be sufficient? I have been reading a few articles around XML Digital Signatures and XML Encryption/SAML ...etc but this all seems to be message-level security and I don't feel that those technologies are relevant. Our main requirements are to authenticate the client and ensure that messages exchanged are secured, in addition to securing the service against DoS attacks.

Thanks for your help in advance

[Jimmy Clark]

How can we make sure that our web service is secure? Would using SSL with Client authentication be sufficient? I have been reading a few articles around XML Digital Signatures and XML Encryption/SAML ...etc but this all seems to be message-level security and I don't feel that those technologies are relevant.

Using WS-Security, XML Encryption, XML Addressing, and all the rest are the best practice for implementing web service security. Your feelings about them are in conflict with industry standard.

Using SSL, HTTPS at the transport layer might be "barely" sufficient for your particular security requirements. However, any industry-strength SOA implementation would be severely flawed with only "transport-level" security.

[M Jay]

Thanks for your reply James,

Of the different technologies that fall under WS-Security, which ones are applicable to the scenario I described? i.e. which technology would be used to authenticate the client (no username and password required this is just to authenticate theh actual client and not the user), and which one would be appropriate for securing the messages so that they cannot be intercepted?

Thanks

[Jimmy Clark]

All of them are applicable. You need to determine the design once you get a good handle of message-level security strategies.

There is nothing that will secure internet-based messages "so that they cannot be intercepted." However, once there is a solid security implementation, then you shouldn't have much to worry about.

Message-level security is the strongest tool for building a solid security implementation.

For starters, learn about XML Encryption and WS-Addressing standards.

Good luck!

[Ulf Dittmer]

WS-Security is about both authentication and encryption (as well as signature), so once you have that implemented, all bases should be covered.

[M Jay]

Thanks a lot James and Ulf... that was very helpful.

[Jait Thomas]

All the above methods hold true for communication within a web service. You can give thought of giving access to the service by imposing firewall, if its accessed only by IP address and it can be restricted within a group as its not exposed outside.

[M Jay]

OK so I have read a number of articles on the internet relating to WSS and still have some unanswered questions...

I understand that using WSS is industry-standard and best practise but at the same time I need to justify the use of this over SSL and so far I cannot see what WSS offers that cannot be accomplished through SSL (for my requirements below) - especially that SSL is easier to implement through server configuration only whereas to implement things like XML Digital Signatures and XML Encryption would involve code writing!

Essentially we have a number of services that we are to expose to the cloud... these services are intended for B2B transactions... so:

1- We need to ensure that the service caller is authorised to do so by verifying they are our business partner.
2- We need to make sure that the messages exchanged over the internet are encrypted.

Please correct me if I'm wrong, but I believe both of the above requirements will be satisfied by using SSL since the communication between the service and consumer is secured and the communication channel is encrypted, and the identity of the caller can be verified through a client digital certificate which is registered at the server-side trust store. Am I missing something? Is there other security considerations that I am overlooking?

[Ulf Dittmer]

I cannot see what WSS offers that cannot be accomplished through SSL

SSL encryption -being a transport-level protocol- ends the moment the request arrives at the web server (or SSL terminator); from then on, the data is unencrypted. This may not matter in your scenario, but if you have a more elaborate WS processing pipeline you may want to pass the request on the a different machine - using WSS it could still be encrypted, whereas using SSL it would not. Admittedly, a rare edge case, but an important one IMO.

the identity of the caller can be verified through a client digital certificate which is registered at the server-side trust store.

It takes a certain effort to add a certificate to the truststore for each client; WSS authentication would allow you to work with a DB (or LDAP) repository.

[M Jay]

Thanks again for your reply Ulf.

SSL encryption -being a transport-level protocol- ends the moment the request arrives at the web server (or SSL terminator); from then on, the data is unencrypted.

This will not matter in my scenario, since the services we are exposing are within our network perimiter, we only need to secure interactions with the outside world which is point-to-point rather than end-to-end.

It takes a certain effort to add a certificate to the truststore for each client; WSS authentication would allow you to work with a DB (or LDAP) repository.

This is a very valid point. The number of web service clients that we might have could potentially be up to 500 different clients. I will look into how WSS authentication works.

Thanks for your help.