FMW 11g - Developing and Testing Secured SCA composites - Part 2 of 4 - WS-Security Username Password

Before reading further:

This is part 2 of series of 4 posts on "Oracle SOA 11g Secured SCA components development and testing". For gaining the context and continuity, you may want to refer to the part 1.

In this part of 11g SCA composites Security tutorial series, let us visit the ws-security username/password based security wrt SCA composites, and calling/testing of those composites. 

The Callee (SecuredStringConverterClient) and Caller (StringConverterProcess) SCA composites that we use as part of this tutorial are already developed in the part 1 of this tutorial series.

Let us visit StringConverterProcess and edit the security policy it was attached to as per the needs of this post. Login the Enterprise Manager console, view StringConverterProcess, go to the policies tab, and detach the any policies previously attached to its end point.

Attach a new policy oracle/wss_username_token_service_policy to the end point and press OK.

Now this service is secured with WS-Security username/password credentials, (but with no message encryption though).

Testing of this secured composite

As discussed in the beginning of this series, this SCA composite will be tested/called in the following different ways, and will discuss configurations below:

Calling the secured end point using Enterprise Manager Console

Navigate to the ‘Test’ interface of EM of the service in context.

In the request tab, choose ‘OWSM Security Policies’, and select ‘oracle/wss_username_token_client_policy’ (gets automatically selects usually), and fill-in the credentials of username and password as shown below

Now test the service, we get the response of Upper case string:

Calling the secured end point using soapUI

In the soapUI, delete the configuration done in the part 1 of this series for testing end points that are secured with HTTP basic auth, using soapUI.

Double click the soapUI project on the left pane, and select the “WS-Security Configurations” of the interface on the right side, further choose “Outgoing WS-Security Configurations” tab below. Click the '+' button there to add an 'Outgoing WSS config' as shown below:

And then in the subsequent window pop ups, provide details as shown below:

and to provide details, add a WSS entry by clicking '+' button in the bottom pane and filling details as shown below:

As the default passwd is supplied for this configuration above, we get the username and passwd filled in automatically. Change the password type to ‘Password Text’

Now, this configuration can be used either at the request level, or at the binding level.

Configuring WS-Security Credentials at 'request' level

At the request level, the above configuration wss-UsernamePassword to be choosen in the ‘Outgoing WSS’ drop down box, an shown

and then test the service.

Upper case converted string will be the result. Output image ignored for simplicity.

Configuring WS-Security Credentials at 'binding' level

Delete the request level configuration discussed above, so that it doesn't interfere with the 'binding level config we will be doing now.

Right click the service binding on the left pane, and click the 'Show Interface Viewer', and choose the 'Service Endpoints' tab.

For the available end point, configure 'outgoing WSS' value from the pull down menu (only one value appears that we have configured above), as shown below:

And, after saving this, run the test request again. Upper case converted string should be returned.

Calling the secured end point from another SCA composite

This security testing can be done using the same composite developed before for HTTP basic auth testing with name ‘SecuredStringConverterClient’.

On EM, go to SecuredStringConverterClient details, and ‘detach’ the existing security policies (that we attached during part 1 of this series, for testing HTTP basic auth.)

In the SecuredStringConverterClient composite, for the reference (of StringConverterprocess), attach oracle/wss_username_token_client_policy as shown below:

Username and password values are to be added as the properties in the reference in the composite, like described in part 1 (composite may need to be edited for this).

Now, lets test the StringConverterProcess from SecuredStringConverterClient as follows:

As the security configuration and credentials are internally supplied, testing from this interface here is pretty simple and does not involve supplying any credentials. We get the upper case string as output.

Summary

In this post, we discussed securing 11g SCA composite, using ws-security username / password and called the secured composite from 

Next Steps

For securing SCA composites using PKI (Public Key Infrastructure), and testing them from different means, pl refer to part 3 of this series.

॥ स्वस्थि  ॥