Authenticating Oracle SOA Suite Composites: Restricting Invoke Privileges to Specific Users

Authors Note: This blog will be valuable for architects and developers who use Oracle SOA Suite to design and build integration processes.

I recently had a request to secure an Oracle SOA Suite 12c composite initiated by a SOAP based web service with a username and password. Because of the functionality of the composite, there was an additional requirement to restrict which users were accepted in the basic authentication. This blog explains authentication in Oracle SOA and will walk you through how you can add basic authentication to a SOA web service restricting access to a specific user to meet security requirements.

Authentication in Oracle SOA

Let’s begin by going through the concepts of how Oracle SOA Suite implements authentication with composites.

To add authentication to a soap-based web service, SOA utilizes Oracle Web Services Manager (OWSM) policies. The policies that apply basic authentication to a composite are either oracle/wss_http_token_service_policy or oracle/wss_http_token_over_ssl_service_policy depending if the web service requires TLS/SSL. Attaching one of the two http token service policies to the SOA composite service adds authentication to the composite. When the policies are attached to the SOA based web service, the web service will only process if the request includes a username and password that is authenticated against a user set up in the security realm.

When only the http token service policy is attached, any user set up in WebLogic would be able to invoke the composite with a username and password. Three OWSM binding policies can be added on top of the http token service policies to restrict which users are accepted. The binding policies are:

1. oracle/binding_authorization_denyall_policy – This policy denies all users. No further setup is required to use this policy.
2. oracle/binding_authorization_permitall_policy – This policy permits all registered users with invoke privileges. No further setup is required to use this policy.
3. oracle/binging_permission_authorization_policy – This policy permits certain users, groups, or roles based on the application policies configured. Further setup is required to utilize this policy. The policy itself does not define the user, role, or group. The OWSM policy works in coordination with oracle.wsm.security.WSFunctionPermission permission class. The permission class is associated with a resource and guarantee (user, group, or role) in an application policy.

Please note there are a couple more binding policies for basic authentication which utilize the Oracle Entitlement Server. However, for this post, I am assuming the entitlement server is not in use.

Attaching both an http service policy and a binding policy to the composite service adds authentication with restrictions to a SOA composite.

Walkthrough Implementation

Now that you know the concepts behind adding basic authentication to a composite, let’s walk through an example implementing the composite security restrictions in Oracle SOA Suite 12c. Imagine this scenario: There is a system we would like to have call a SOA composite through a soap based web service. Because of the capabilities of the composite, we only want the system to be able to invoke the composite through basic authentication.

I have seen this implemented in SOA two different ways:

For both options, we need to create a “systemUser” which the system will send as authentication. This user is specific to the SOA system, so the user will not be added to another directory such as active directory. The user will be created like the default installation weblogic admin user but will not be given admin privileges:

To create the user, on the admin console, go to security realms, users and group, and click to create a new user. Create the user as a default authenticator and fill in the blanks similar to the image below:

After pushing the create button, the user is created.

To set up authentication for the “systemUser,” the first implementation is to create a custom policy like the oracle/binding_authorization_permitall_policy.

During the creation of a binding policy, there is an option to select whether the policy effects permit all, deny all or permit selected roles. The binding_authorization_permitall policy selects permit all. In this case, we only want selected users, so we will create a similar policy except select selected roles instead of permit all which would restrict to certain users.

First create the role that is going to be associate the systemUser. In enterprise manager, open the SOA folder, right click on soa-infra, scroll down to Security, and from that reach Application Roles. Click create and fill in the role names and description and add the user as a member like the image below:

 

Next create the policy that will use the role. On enterprise manage, go to WSM policies, click on the oracle/binding_authorization_permitall_policy, and once highlighted click the Create Like option.

Adjust the name to reflect the new policy on the general page, and then on the assertions page under roles, click Selected Roles instead of Permit All.

Click save to create the new policy, and the policy is created. To use the new policy with the SOA composite, attach the policy to the service along with oracle/wss_http_token_service_policy.

The custom policy implementation works well if the same group of users under the same role always have authentication privileges, so the new custom policy will be reused. However, if a SOA implementation has a lot of different roles or different groups of users who require access to different composites, a different custom policy would be needed for each of the roles. Many different custom policies could be difficult to manage with the individual custom policy setup and attaching each custom policy to different services. Because the scenario requires only the systemUser permitted with composite, other composites would mostly require a different role, making this scenario fall into the multiple custom policies set up.

In order to avoid multiple custom policies creations, another way to add authentication is to attach the oracle/binging_permission_authorization_policy on top the oracle/wss_http_token_service_policy and to set up application policies to control which users and resources are permitted.

To set up the application policy with the systemUser, first navigate to the application policies in enterprise manager. Open the SOA folder, right click on soa-infra, scroll down to Security, and from that click on Application Policies.

Click on the create button to create the application grant.

Add the “systemUser” in the Grantee section by clicking add and searching for the desired user. While we are using a user, you can search and add roles or groups as the grantee for the application policy. Multiple grantees can be added to the same policy.

Next, add the permissions by clicking on add. For the permission class, type oracle.wsm.security.WSFunctionPermission. For simplicity purposes, in the resource name and permission action enter *. The * indicates any resource will be restricted to the grantee when using the binding policy. If you would like to specify the composite to authenticate, set up the resource name as: namespace of the composite # operation.

During development of the SOA composite or at runtime, attach the two polices, and the authentication with restrictions has been added.

Compared to the custom policy implementation, only one binding policy would have to be attached to every composite and the different users and roles can be set up in the application policies which are more manageable. For this scenario with different users permitted per composite, the application policy implementation is cleaner at design and deployment time, which is why I use this approach rather than the custom policy implementation.

Conclusion

In summary, basic authentication can be added to SOAP based SOA composite services restricting permission to certain users. If there is reuse in users or roles permitted per different composite, create a custom policy like the oracle/binding_authorization_permitall_policy with only the selected role permitted and attach the custom policy and oracle/wss_http_token_service_policy. If there are different users permitted per different composites, complete soa-infra application policy set up and attach the oracle/wss_http_token_service_policy and oracle/binding_permission_authorization_policy.

Please refer to the Oracle Fusion Middleware Developer’s Guide for Oracle SOA Suite for detailed information about configuring and using OWSM policies in Oracle SOA Suite 12c, or reach out to one of our experts.