Enabling WS-Security using JDeveloper

In this post i will be talking about some easy techniques to implement WS-Security in our applications. WS-Security is used to enable applications and services for a secured message level communication. WS-Security standards came into picture because of the inherent drawbacks of HTTPS/Transport layer security like provides only point to point security and is not useful if my destination service calls another and that inturn calls yet another. Similarly if i want to encrypt some specific parts of my message than also SSL is of no use.

We can add WS Security features in our Web Services using jdeveloper. Right click on the port name and select Secure web Service.

A popup is displayed that gives us a facility to add WS Security features:-

Click on Authentication to select and configure the authentication based settings for our web service:-












Similarly you can configure other features of WS Security as per your requirements.

Now, once you have enabled the Service to expect wsse security tokens then the client also needs to be configured with the same features. These can be configured on the client proxy by right clicking on the proxy and selecting Secure Proxy.










A configuration popup is shown that allows us to configure WS Security features on the Client proxy.

Configuring WS-Security credentials on a BPEL / ESB in OracleSOA suite:-

In an SOA based application, a BPEL or an ESB can act as a client as well as an intermediary destination. In either case we need to secure the message flows to and from a BPEL or an ESB. Oracle Enterprise Manager provides a facility to add WS-Security credentials to any Webservice deployed on OC4J, BPEL deployed on Process Manager as well as an ESB deployed on Oracle AS. These credentials can also be added using Jdeveloper.

In this article i will be talking about how to enable WS Security features using Enterprise manager:-

Browse to the Enterprise manager and click on your OC4J instance:-















Now click on the Web Services tab and select the Web Service (BPEL/ESB are also exposed as a WebService in EM) on which you want to enable WS Security features:-













Click the Administration Tab:-














Click on the Enable/Disable features button, select security and add it. Click on OK. The resultant screen is somewhat like:-

Click on the Edit Configurations for Security and as per your requirement configure either inbound/outbound policy. An Inbound policy will configure your service with a policy that gets executed when ever a request comes to it. Similarly theOutgoing policy gets executed when ever a request is generated from the service.

Oracle Enterprise manager provides a facility to add authentication, Integrity as well as confidentiality related feature to your service. Choose the apporpriate tab and configure the policy accordingly:-

Following fields are available in the Integrity tab:-

Following fields are available in the confidentiality tab:-











Click on ok and you are through with the policy configurations. In my next blog entry i will be speaking on the details of every configuration tab provided in the inbound/outbound policy.

Oracle Webservice Manager - A Whitepaper

Oracle WSM

INTRODUCTION:
This document talks about a fictitious SOA implementation/business scenario where the owner of the process faces certain security and monitoring concerns that needs to be addressed. As we go ahead in the document we suggest the solutions that we can adopt in order to overcome the drawbacks of the existing system. Then we will justify that why should we go ahead with a specific tool (Oracle WSM in this case) to achieve the objectives.


DESCRIPTION:
Let’s assume that an XYZ bank pvt ltd offers a ULIP (insurance) policy to its customers. This entire process is made up of many small inter linked processes. In this document we will talk about a specific scenario that deals with switching of funds between equities and debts, as per customers request.

In such a scenario, the customer on the basis of the stock market status can opt for a percentage change in fund allocations in equities or in debts. When ever the customer decides to switch his fund allocation, a bpel process flow gets triggered that in turn calls some web services for further processing.

Now this scenario can be implemented as below: (in the current implementation none of the security concerns are addressed).

Security and monitoring Concerns:-
(1) How do I secure the request message for change in allocation from client calling the ESB?
(Transport Level as well as Message Level)
(2) Only authentic users should be allowed to start the BPEL process. How do I ensure this?
That too without making much changes to my existing process.
(3) Now even if the BPEL process gets invoked but the user for whom the process needs to
execute has already carried out the permissible switches then I want to stop the process
then and there.
(4) After passing all the above implementation barriers the request is sent to the actual fund
switching web service (hosted at a different location) that does the required changes and
gives a success/failure response. I want this service to be secured and only authentic users
should be able to invoke this service. I also want to ensure message integrity and
confidentiality.
(5) There should be elaborate monitoring facilities like SLA monitoring, message logging etc?
I also want authentication/authorization graphs and want to know which BPEL processes have unauthorized attempts.
(6) Dynamic routing requirement: Before calling the fund switching web service, I need to
check that if the switch is being performed for the first time then call web service A
Otherwise call web service B.


How do i address above security concerns with minimal changes to my existing flow?
In such a scenario we can either implement various security techniques like HTTPS, WS-Security or can use Oracle WSM (a tool that provides all these features).


What If we go ahead and implement SSL manually (without any tool)?
What if we implement WS-Security manually (without any tool)?
At present there are no full proof implementations of WS-Security except the one provided by axis2 in the form of a module called Rampart.
Even if we use axis2 then also we will have to implement axis configurations at both the client end as well as the server. Also this would not be as flexible at times of modifications in terms of security features to be implemented like digital signatures, Username token, XML encryption etc. Any changes to these would mean a total rebuild of the effected module and hence would result in an extended process down time. (If any changes are made to the service.xml then the corresponding clients aar file needs to be generated and deployed again)


What if we use Oracle WSM?
-The first and the foremost important feature of WSM is that it is a one stop shop for implementing all our security needs plus the monitoring and analysis benefits.
-WSM also uses axis and WS-Policy internally to achieve all security objectives and implement them efficiently.
-It allows IT managers to centrally define policies that govern web services operations such as access control (authentication, authorization), logging, and content validation, and then attaches these policies to one or multiple web services with no modification to existing web services required i.e. we need to implement/create policies on every service/clients. Rather we can define it and control it from one centralized location.


Why OWSM? Where does it fit in the Oracle SOA Suite?
I recommend using OWSM because in the above scenario using it wouldn’t require any changes to the existing ESB, BPEL or any web service. Above all the policy steps in the WSM are fully configurable and can be modified from time to time.

Oracle WSM enforces true end-to-end message-level security, supports WS-Security for authentication and message-level security including encryption and signing, and supports full and partial encryption and decryption step.

OWSM also collects monitoring statistics to ensure quality of service, uptime, security threats, and display them in a dashboard. As a result, Oracle WSM brings enterprises better control and visibility over web services.

OWSM is efficiently placed in the Oracle SOA suite as follows:

Talking about the various components/features of WSM:

A. Policy Manager
B. Policy Enforcement Points (Gateway, Agents)
C. Monitoring Dashboard


A. Policy Manager
The predefined policy steps fall into the following general categories:
Security Steps:
* Credential Management
* Authentication
* Authorization
* Integrity and Confidentiality
* Federation

Nonsecurity Steps:
* Log messages
* Custom fault messages
* Message transformation using XSLT
B. Policy Enforcement Points (Gateway, Agents)


NOTE: OWSM Agents are of interest to sites that wish to implement end-to-end security. This is designed to assure that the business process is secured from the very beginning to the very end of its execution. Agents are also useful in settings where the service endpoint is already known to clients and it would not be desirable to change the endpoint.
Gateways, on the other hand, are used when there is a need to deploy a security choke point. This is similar to a firewall, where security policies can be employed in a central location. A gateway can also perform functions that an agent cannot do, such as message routing, transformations, and failover.

C. Monitoring Dashboard


Following are the security concerns along with the solutions using WSM:-

(1) The request first goes to an ESB where based on the message contents we decide that which bpel process needs to be invoked.

(Soln:-These bpel calls are implemented through SOAP service calls and these calls can be secured using a WSM gateway having an SSL policy step configured on it. This is for transport level security measures. Message security can be achieved by XML decryption policy steps for the specific elements that are encrypted from client)

(2) The corresponding fund allocation switching bpel process gets triggered only when a request is raised by an authentic ULIP customer (one who has a valid ULIP policy).

(Soln:-Configure a client agent on ESB and a server agent on the BPEL having a policy for authentication of user i.e. UserName token and its authentication from a file/LDAP etc)

(3) After checking the credentials, the flow triggers a web service that checks the number of times the customer has opted for a fund switch and whether he is allowed a further switch or not.

(Soln:-As such no security required.)

(4) When this web service gives a go ahead response then actual switch fund Web Service is invoked that does the actual processing. This Web Service requires a Username token validation along with a digital signature.

(Soln:-For this we can make changes in the bpel.xml for sending the Username token properties i.e. no client agent needs to be configured on BPEL. On the web service we can create a WSM server agent having a policy configured that validates the Username token after extracting it from the message along with the digital signature).

(5) Once this web service gives a success response the parent bpel flow proceeds further and returns a success message to the user.













By implementing above I can successfully address all the security concerns.


Dynamic Routing can be achieved by creating a gateway and then configuring the dynamic
xpath for the specific destinations.


What about other concerns like SLA monitoring, message logging etc?I also want authentication/authorization graphs and know which BPEL processes
have unauthorized attempts.

http://download-uk.oracle.com/docs/cd/B31017_01/core.1013/b28764/monitor002.htm

http://download-uk.oracle.com/docs/cd/B31017_01/integrate.1013/b31008/op_mgmnt.htm#sthref221


CONCLUSION:
The main drawback in OWSM usage according to me is that while dealing with client agents we need to install the OWSM on both, the client end as well as server end and this may prove to be a bit of overhead in some cases. OWSM is recommended in most cases where we need to introduce security features without modifying the existing web services. This results in a fully configurable secured environment because we can easily add or remove any of the security components. Apart from providing the security components, OWSM also provides logging and monitoring facilities like SLA etc.