Infosys-Oracle Blog

Let us first look at the need of securing web services. SOA in principle means loose coupling and practically it represents an open plug to which any application can hook for retrieval of data. Most of the data is so mundane that it is of no interest to anyone. But moment any financial data is in picture, it will trigger an itch to those who believe in peeking and poking even though the intention is harmless, you cannot guarantee albeit. So in all such cases security becomes the most critical non-functional requirement. And any kind of programmatic security will hurt the performance.

To build a mechanism that enables strong protection during run-time and beyond infrastructure firewalls one has to use enhanced web service security options. OWSM (Oracle Web Security Manager) comes as a handy option to establish an authenticated security. What has been seen on the other hand is that it will degrade the performance to significant or marginal levels depending on the transactional volume and infrastructural capabilities.

During initial SOA implementations, specifically for platforms where the web services were built only to be used over intranet, in the solution architecture OWSM was kept at bay for the fear of performance attenuation. Infrastructural level firewalls were built where access to webservice layer is confined only to particular IPs. This mechanism of security is commonly called as network filtering and it worked only in favour of architects to corroborate their decision.

However during the most recent implementation the deployment infrastructure appeared a bit different. A very high configuration server is being used for multiple applications in a virtual manner. Network filtering emerged as only half way protection or if one has to not mince any words then it was a weak protection, as the number of IPs that needed access to SOA layer was never a constant. Network filtering would still have left some unknown areas from where intrusion was suspected. Plus what firmed up further the need of OWSM was the stringent DR environment policy. If you migrate from PROD to DR, all IPs are new and all your network filtering will need changes and DRM policy needed a seamless transition. We selected OWSM after proof of concept to rule out any noticeable dent on performance was established.

Oracle Web Services Security supports many policies out of the box and the appropriate policies must be chosen based on the need of the deployment. Judicious consideration should be given to tradeoffs between security and performance. Transport level security is faster than Application level security, but transport level security can be defenseless in multi-step transactions. Application level security has more performance implications, but provides end-to-end security. Each additional policy can impact performance. Custom policy is another area which should be delved into on when it is a dire need. Further if you are exposing your services to external world, the universally accepted standards, include the Security Assertion Markup Language (SAML) and WS-Federation Language. These languages use XML to exchange authentication and authorization for SOA systems. They use various systems for exchanging authentication information within in SOA, including session keys, tokens and digital certificates.

A careful design can certainly let you savor best of both worlds - security and performance. In the nutshell do not procrastinate your security considerations, address them from day one with appropriate options.

Please do share some of your experiences which have led to alteration of beliefs around web service security in either ways.