Securing an SOA Environment
A few years ago I was working with a customer who was taking the steps towards a SOA enterprise by encapsulating their custom built CRM functionality and making it available to a third party company that ran their call centre. We took their PL/SQL stored prcedures which encapsulated much of their business functionality and exposed them as web services using JDeveloper and OC4J. We then had the discussion about the S word - security.
Some Options
We discussed several different approaches.
- Use a private network and rely on contracts to enforce legitimate access.
- Use SSL over the network and rely on contracts to enforce legitimate access.
- Use network security based on IP address or originating domain.
- Use WS-Sec standards.
- Ignore the problem.
There are other possible approaches but the above gave us plenty to think about. Approach 5, ignoring security, was determined to be inappropriate as this was exposing customer data outside the corporate firewall. However for many corporations when using data inside the firewall approach 5 may be acceptable.
Using WS-Sec standards was discussed but at the time security standards were new and not easily implemented in either the Oracle web service stack or the Visual Basic client application.
Securing the Network
We came down to securing the network as the best approach. The call centre would be accessing the CRM system across a private leased line network so their was deemed to be no need for SSL, removing the performance overhead of SSL traffic from the equation but still preventing anyone outside the two companies seeing the data.
In addition I recommended securing the server so that it would only accept requests from IP addresses at the call centre location. This approach secured the content to a similar degree to most RPC scenarios.
Securing the Content
Things have moved on however and the security standards are moving along, allowing you to secure parts of the content rather than forcing you to encrypt the whole message. Use of Digital Signatures allows messages to be signed, verifying the source of the message, XML level encryption allows part of the message to be encrypted. The latest JDeveloper 10.1.3 supports this type of web service functionality but inter-operability with a wide range of older clients can still cause problems.
Helping Inter-operability
Putting security directly into the web services themselves can muddy the waters. A declarative approach would allow the security of a service to become a operational policy decision rather than an impementation decision. This is precisely the sort of thing that the Oracle Web Service Manager (OWSM) supports. It allows you to develop client and server without security and then instances of OWSM at each end of the communication pipe can intercept the messages and selectively validate and encrypt/decrypt portions of the content. This allows for a much richer level of security than the old network based security but still keeps the developers focussed on business functionality rather than security. This approach is illustrated below.
Note that it may not be OWSM itself that is on the server or client systems, it could be an agent component.
Other benefits
Other benefits of this approach are that it enables the monitoring of web services, providing an audit capability of all communications between service requestors and service responders. In a loosely coupled SOA environment this can be a useful centralised service.
Conclusion
SOA security is a potentially complicated issue with lots of things to worry about, we haven't even spoken about federated security, flowing identity across layers. But the basic web services security is getting there.
