FMW 11g - Developing and Testing Secured SCA composites - Part 1 of 4 - HTTP Basic Auth

Developer Summary


 Hi
This tutorial series walks though important steps of developing secured SCA composites, by applying different OWSM security policies on to the SCA composites, and testing them through different possible means like Enterprise Manager test console, soapUI, and from another SCA composites, etc.

Technology / Tools (used in this tutorial series)

  • Oracle SOA Suite 11g – ver 11.1.1.6
  • JDeveloper 11g – ver 11.1.1.6
  • soapUI – ver 4.5.1 and 4.0.1
  • Portecle - ver 1.7


 I this series of blogs, the following technical use cases get covered:
1. Securing a SCA composite with HTTP basic auth
2. Securing a SCA composite with WS-Security username/passwd
3. Securing a SCA composite with PKI (security and message protection) - one-way SSL and  two-way SSL
4. Security a SCA composite with SAML tokens


 In all the cases, we will test it in all the following styles:
1. From Enterprise Manager 11g console
2. from soapUI
3. from another SCA composite

Use case:


 Simple string conversion is taken as the use case for these tutorials, to keep the functionality trivial, and focus on FMW SOA Suite 11g security features. For walking through this, prepare an XSD that is suitable for this need - something like <StringChangeCase.xsd>with one input string, and one output string.

 In part 1 of this series, I would cover the HTTP basic auth based security and testing
---------------------------------------------------------------------------------------------

Securing 11g SCA composites with HTTP basic auth, and testing

Develop a simple SCA composite (in this tutorial named as StringConverterProcess) that takes a string as input and converts that to upper case and returns it. Deploy this composite on to the 11g runtime. [ I am keeping the steps/details of development of this composite off here, as that is trivial for Oracle FMW developers.]

After the SCA composite has been deployed, login the Enterprise Manager, and view the composite details. 

In the composite details, go to the ‘policies’ tab, and in that, click the ‘Attach To / Detach from' drop down box. Choose the composite end point ‘stringConverterProcess_client_ep’ (or, as you named it) from it as shown below




A new window pops up with a choice of policies that can be applied on to this end point. Select the policy “oracle/wss_http_token_service_policy”, and attach it the end point, and press ‘OK’ on the top of the window as shown below:




After this, the chosen policy is visible in the list of policies applied for this composite as shown below:




Applying this policy means, service end point expects username and password in the HTTP header and validates them against configured identify store. Eg: myRealm configured in WebLogic Server.

Note - This policy can be applied only to HTTP end points.



Testing of secured SCA composite


This session discusses how to call a service end point that is secured in HTTP basic authentication. (Note: only http end points can be secured using http basic authentication)

Calling the secured end point using Enterprise Manager Console



Go to the ‘TEST’ interface of composite, and choose “HTTP basic Auth” and provide credentials as shown below:


And, we get response from the service –string converted to Upper case.


Note - if the WSDL of the WS itself is secured with HTTP basic auth, EM console provides an easy way to parse it for subsequent testing, shown in the pic below:


Calling the secured end point using soapUI

soapUI gives multiple levels of configuration of security credentials for calling a secured service. It can be configured at request level, or, at the bindging level.
Let us try it configuring at 'request' level first

Configuring HTTP auth credentials at ‘request’ level


After opening the request, ‘Aut’ tab is available on the bottom-left corner for security credentials configuration



selecting this tab, text boxes available for filling-in username and password. Provide these details as shown:
(Also the username / passwd will also be reflected in the ‘request properties’ on the left pane.)




After providing the HTTP basic auth credentials, we can test the service to get the response




Configuring HTTP auth credentials at ‘binding’ level

When we have multiple requests to pass to the same end point for testing multiple cases, configuring the security credentials at binding level makes more sense than configuring for each request separately. soapUI supports configuring HTTP basic auth credentials at binding level.

Right click on the binding(on left pane) and click the ‘Show Interface Viewer’, we get Interface Viewer window. In that, ‘Service Endpionts’ tab has the configuration of binding level security credentials for WS - shown below. Configure the credentials here.


Delete the request level security credentials configuration done in the previous step, to make sure that that configuration doesn’t interfere with the ‘binding level’ settings.

After the binding level configuration of HTTP basic auth, service can be tested to get the response. (Results are not shown here as they appear same as previous step.)

Calling secured End pint from another SCA composite


For this testing, create another SCA composite with BPEL process with name ‘SecuredStringConverterClient’ (or, any other name of  choice) that takes a string as input and returns upper case converted version of the same string in response (Functionality is deliberately trivialized to focus on the security features). We will achieve the upper case conversion, by calling previously developed secured SCA composite ‘StringConverterProcess’. Hence, in this tutorial, we create reference to ‘StringConverterProcess’ in JDeveloper.


Client side security policy can be configured on thsi reference for this testing. it can be done either at the code level with in the JDeveloper, or, at the Enterprise Manager. Doing at the EM level makes more sense, however, for the purpose of exercise, lets do both in this tutorial.

In the JDeveloper, right click on the reference, and choose “Configure WS Policies …” as shown below:



and then, in the subsequent menu choose security policy named ‘oracle/wss_http_token_client_policy’ as shown below:


In the composite.xml, edit the reference’s configuration by adding username and password properties as follows:



Alternatively, these configurations can be done from ‘Enterprise Manager’ console (like it was done for StringConverterProcess before), in a similar way that we did for the ‘StringConverterProcess’.

Deploy the composite to the SOA server.


It can be tested like any other SCA composite, and typical response would be something like this:




Summary


In this post, we discussed securing a 11g SCA composite with HTTP basic auth, and testing it from EM console, soapUI, and another SCA composite

Next Steps


For securing and testing 11g SCA composites ws-security username and passwd, pl check part 2 of this series.



 ||  स्वस्ति ||


Comments

Post a Comment