6 Securing SOA Composite Applications

6.4.1 Automatically Authenticating Oracle BPM Worklist Users in SAML SSO Environments

In order to be automatically authenticated when accessing a second Oracle BPM Worklist from a first Oracle BPM Worklist in SAML SSO environments, you must perform the following steps. Otherwise, you are prompted to log in again when you access the second Oracle BPM Worklist. In these environments, the first Oracle BPM Worklist is configured as the SAML identity provider and the second Oracle BPM Worklist that you are attempting to access is configured as the SAML service provider.

To automatically authenticate Oracle BPM Worklist users in SAML SSO environments:

1. Add /integration/worklistapp/* as the redirect URL for worklistapp to the SAML service provider site's SAML2IdentityAsserter configuration as follows.

   1. In the Oracle WebLogic Server Administration Console, select Security Realms.

   2. Click the realms for the service providers.

   3. Select the Providers tab, and then the Authentication subtab.

   4. From the provider list, select the provider with the description SAML 2.0 Identity Assertion Provider.

      If you do not see the SAML identity assertion provider configuration, follow the instructions in Oracle Fusion Middleware Securing Oracle WebLogic Server.

   5. Select the Management tab.

      Under the Management tab, you can see a list of identity provider partners. These are hosts that have been configured as the SAML identity provider partners for this SAML identity service provider site. Remember that this configuration step is performed on the identity service provider site on which the worklist application is hosted.

   6. Select the identity provider site where you want the user to perform the initial login.

   7. Scroll down the page until you see the field Redirect URIs.

   8. Add /integration/worklistapp/* to the list.

   After performing this step, you can log in to Oracle BPM Worklist at the SAML identity provider site though the regular URL of/integration/worklistapp. If necessary, you can then navigate to the URL /integration/worklistapp/ssologin at the SAML service provider site, where you gain access to Oracle BPM Worklist and are automatically authenticated.

   For more information on SAML2IdentityAsserter and configuring SSO with web browsers and HTTP clients, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

6.4.2 Automatically Authenticating Oracle BPM Worklist Users in Windows Native Authentication Environments

For Windows native authentication through Kerberos to work with Oracle BPM Worklist, you must use the /integration/worklistapp/ssologin protected URL. For example, after configuring Windows native authentication, you access Oracle BPM Worklist as follows:

http://host_name.domain_name:8001/integration/worklistapp/ssologin 

For information on configuring SSO with Microsoft clients, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

6.4.3 Automatically Authenticating Oracle Business Process Management Process Composer Users in Windows Native Authentication Environments

For Windows native authentication through Kerberos to work with Oracle Business Process Management Process Composer, you must use the bpm/composer/ssologin protected URL. For example, after configuring Windows native authentication, you access Process Composer as follows:

http://host_name.domain_name:8001/bpm/composer/ssologin 

For information on configuring SSO with Microsoft clients, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

6.5.1 Listing Oracle Internet Directory as the First Authentication Provider

The Oracle BPM Worklist and workflow services use Java Platform Security (JPS) and the User and Role API. For this reason, the Oracle Internet Directory authenticator must be the first provider listed when workflow is used with Oracle Internet Directory. If Oracle Internet Directory is not listed first (for example, it is listed below DefaultAuthenticator), login authentication fails.

For information about changing the order of authentication providers, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

6.5.2 Accessing Web-based Applications with the Default Authentication Provider

Logins to web-based applications may fail when using Oracle Internet Directory authentication. This is caused when the Oracle WebLogic Server configuration is set to use the Oracle Internet Directory authentication before default authentication.

This may produce the following error:

"@ User "weblogic" is not found in configuration "jazn.com" Check if the user
 exists in the repository specified by the configurations. Check the error stack
 and fix the cause of the error. Contact oracle support if error is not fixable."

The order of the security providers should be:

1. Default authentication

2. Oracle Internet Directory/LDAP authentication

6.6.1 Recommendation to Configure Either All on No Managed Servers with SSL

As a best practice, Oracle recommends that you configure either all managed servers or no managed servers with SSL (SOA, BAM, and so on). Configuring some managed servers with SSL, while not configuring others, may lead to undesirable results in Oracle BPM Worklist and Oracle Web Services Manager (OWSM). For example, if there is an SSL-configured managed server (bam_server), servers not configured with SSL are not be used by OWSM. In cases in which an SSL-configured server is down, it causes OWSM to be in a down state, which in turn causes Oracle BPM Worklist to be in a down state.

6.6.2 Switching from Non-SSL to SSL Configurations with Oracle BPM Worklist

Switching from non-SSL to SSL configurations with Oracle BPM Worklist requires the Frontend Host and Frontend HTTPS Port fields to be set in Oracle WebLogic Server Administration Console. Not doing so results in exception errors when you attempt to create to-do tasks.

To switch from non-SSL to SSL configurations with Oracle BPM Worklist:

1. Log in to Oracle WebLogic Server Administration Console.

2. In the Environment section, select Servers.

3. Select the name of the managed server (for example, soa_server1).

4. Select Protocols, then select HTTP.

5. In the Frontend Host field, enter the hostname on which Oracle BPM Worklist is located.

6. In the Frontend HTTPS Port field, enter the SSL listener port.

7. Click Save.

6.6.3 Configuring SOA Composite Applications for Two-Way SSL Communication

Oracle SOA Suite uses both Oracle WebLogic Server and Sun Secure Socket Layer (SSL) stacks for two-way SSL configurations.

• For the inbound web service bindings, Oracle SOA Suite uses the Oracle WebLogic Server infrastructure and, therefore, the Oracle WebLogic Server libraries for SSL.

• For the outbound web service bindings, Oracle SOA Suite uses JRF HttpClient and, therefore, the Sun JDK libraries for SSL.

Due to this difference, start Oracle WebLogic Server with the following JVM option.

To configure SOA composite applications for two-way SSL communication:

1. Open the following file:

   • On UNIX operating systems, open $MIDDLEWARE_HOME/user_projects/domains/domain_name/bin/setDomainEnv.sh.

   • On Window operating systems, open MIDDLEWARE_HOME\user_projects\domains\domain_name\bin\setDomainEnv.bat.

2. Add the following lines in the JAVA_OPTIONS section, if the server is enabled for one-way SSL (server authorization only):

   -Djavax.net.ssl.trustStore=your_truststore_location
   

   For two-way SSL, the keystore information (location and password) is not required.

In addition, perform the following steps to enable two-way SSL for a SOA composite application to invoke another SOA composite application or another non-SOA application.

To enable two-way SSL for a SOA composite application to invoke another application:

1. On the client side, provide the keystore location.

   1. From the SOA Infrastructure menu, select SOA Administration > Common Properties.

   2. At the bottom of the page, click More SOA Infra Advanced Configuration Properties.

   3. Click KeystoreLocation.

   4. In the Value column, enter the keystore location.

   5. Click Apply.

   6. Click Return.

2. During design time in Oracle JDeveloper, update the reference section in the composite.xml file with the oracle.soa.two.way.ssl.enabled property.

   <reference name="Service1" 
      ui:wsdlLocation=". . ."> 
      <interface.wsdl interface=". . ."/> 
        <binding.ws port=". . ."> 
         <property name="oracle.soa.two.way.ssl.enabled">true</property> 
     </binding.ws> 
    </reference> 
   

3. In Oracle Enterprise Manager Fusion Middleware Control, select WebLogic Domain > domain_name.

4. Right-click domain_name and select Security > Credentials.

5. Click Create Map.

6. In the Map Name field, enter a name (for example, SOA), and click OK.

7. Click Create Key.

8. Enter the following details.

   Field	Description
   Select Map	Select the map created in Step 6 (for this example, SOA).
   Key	Enter the key name (KeystorePassword is the default).
   Type	Select Password.
   User Name	Enter the keystore user name (KeystorePassword is the default).
   Password	Enter the password that you created for the keystore.

   
   

   Note:

   When you set up SSL in Oracle WebLogic Server, a key alias is required. You must enter mykey as the alias value. This value is required.

9. Set the keystore location in Oracle Enterprise Manager Fusion Middleware Control. See Step 1 for instructions.

10. Modify the composite.xml syntax to use https and sslport to invoke a SOA composite application. For example, change the syntax shown in bold:

    <?xml version="1.0" encoding="UTF-8" ?> 
    <!-- Generated by Oracle SOA Modeler version 1.0 at [4/1/09 11:01 PM]. --> 
    <composite name="InvokeEchoBPELSync" 
    revision="1.0" 
    label="2009-04-01_23-01-53_994" 
    mode="active" 
    state="on" 
    xmlns="http://xmlns.oracle.com/sca/1.0" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
    xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" 
    xmlns:ui="http://xmlns.oracle.com/soa/designer/"> 
    <import 
    namespace="http://xmlns.oracle.com/CustomApps/InvokeEchoBPELSync/BPELProcess1"
      location="BPELProcess1.wsdl" importType="wsdl"/>
    <import namespace="http://xmlns.oracle.com/CustomApps/EchoBPELSync/
    BPELProcess1"location="http://hostname:port/soa-infra/services/default/EchoBPEL
    Sync/BPELProcess1.wsdl"
    importType="wsdl"/>
    

    to use https and sslport:

    location="https://hostname:sslport/soa-infra/services/default/EchoBPELSync
    /BPELProcess1.wsdl"
    

6.6.4 Invoking References in One-Way SSL Environments in Oracle JDeveloper

When invoking a web service as an external reference from a SOA composite application in one-way SSL environments, ensure that the certificate name (CN) and the hostname of the server exactly match. This ensures a correct SSL handshake.

For example, if a web service is named adfbc and the certificate has a server name of myhost05, the following results in an SSL handshake exception.

<import namespace="/adfbc1/common/" 
           
 location="https://myhost05.us.oracle.com:8002/CustomApps-adfbc1-context-root/Ap 
pModuleService?WSDL" 
          importType="wsdl"/> 
 <import namespace="/adfbc1/common/" location="Service1.wsdl" 
          importType="wsdl"/> 

If you switch the order of import, the SSL handshake passes.

<import namespace="/adfbc1/common/" location="Service1.wsdl" 
          importType="wsdl"/> 
<import namespace="/adfbc1/common/" 
           location="https://myhost05.us.oracle.com:8002/CustomApps-adfbc1-context-root/Ap 
pModuleService?WSDL" 
          importType="wsdl"/> 

Note the following restrictions around this issue:

• There are no options for ignoring hostname verification in Oracle JDeveloper as exist with the Oracle WebLogic Server Administration Console. This is because the SSL kit used by Oracle JDeveloper is different. Only the trust store can be configured from the command line. All other certificate arguments are not passed.

• In the WSDL file, https://hostname must match with that in the certificate, as described above. You cannot perform the same procedures as you can with a browser. For example, if the hostname is myhost05.us.oracle.com in the certificate's CN, then you can use myhost05, myhost05.us.oracle.com, or the IP address from a browser. In Oracle JDeveloper, always use the same name as in the certificate (that is, myhost05.us.oracle.com).

6.6.5 Configuring Oracle SOA Suite and Oracle HTTP Server for SSL Communication

Follow these steps to configure SSL communication between Oracle SOA Suite and Oracle HTTP Server.

6.6.6 Configuring SSL Between SOA Composite Application Instances and Oracle WebCache

The Test Web Service page in an Oracle WebCache and Oracle HTTP Server environment may require communication back through Oracle WebCache. Therefore, SSL must be configured between the SOA composite application instance and Oracle WebCache (that is, export the user certificate from the Oracle WebCache wallet and import it as a trusted certificate in the Oracle WebLogic Server trust store).

6.6.7 Using a Custom Trust Store for One-Way SSL During Design Time

To invoke a SOA composite application from another composite over HTTPS when using a custom trust store created with a tool such as keytool or orapki, perform the following actions in Oracle JDeveloper.

To use a custom trust store for one-way SSL during design time:

1. To fetch a WSDL file in the reference section, set the trust store information in Tools > Preferences > Http Analyzer > HTTPS Setup > Client Trusted Certificate Keystore.

2. During deployment to an SSL-enabled server, use the JSSE property at the command line:

   jdev -J-Djavax.net.ssl.trustStore=your_trusted_location
   

6.6.8 Enabling an Asynchronous Process Deployed to an SSL-Enabled, Managed Server to Invoke Another Asynchronous Process Over HTTP

Assume you create the following environment:

• Asynchronous BPEL process A that invokes asynchronous BPEL process B

• Asynchronous BPEL process A is deployed to a one-way SSL enabled, managed server

• All WSDL reference and bindings use plain HTTP

At runtime, the WSDL is looked for over HTTPS, and the callback message from asynchronous BPEL process B fails.

To resolve this issue, the callbackServerURL property must be passed at the reference binding level in the composite.xml file. This explicitly indicates the value of the callback URL for the given reference invocation. If the client composite is running in an SSL-managed server, then the callback defaults to SSL.

<reference name="Service1" 
ui:wsdlLocation="http://localhost:8000/soa-infra/services/default/AsyncSecondB 
PELMTOM/BPELProcess1.wsdl"> 
    <interface.wsdl
 interface="http://xmlns.oracle.com/Async/AsyncSecondBPELMTOM/BPELProcess1#wsdl 
.interface(BPELProcess1)" 
callbackInterface="http://xmlns.oracle.com/Async/AsyncSecondBPELMTOM/BPELProce
ss1#wsdl.interface(BPELProcess1Callback)"/> 
    <binding.ws 
port="http://xmlns.oracle.com/Async/AsyncSecondBPELMTOM/BPELProcess1#wsdl.endp 
oint(bpelprocess1_client_ep/BPELProcess1_pt)" 
                
location="http://localhost:8000/soa-infra/services/default/AsyncSecondBPELMTOM 
/bpelprocess1_client_ep?WSDL"> 
         <wsp:PolicyReference URI="oracle/wss_username_token_client_policy" 
                           orawsp:category="security" 
orawsp:status="enabled"/> 
      <wsp:PolicyReference URI="oracle/wsaddr_policy" 
                           orawsp:category="addressing" 
orawsp:status="enabled"/> 
. 
 <property name="callbackServerURL">http://localhost:8000/</property> 
. 
    </binding.ws> 
. 
  <callback> 
      <binding.ws 
port="http://xmlns.oracle.com/Async/AsyncSecondBPELMTOM/BPELProcess1#wsdl.endp 
oint(bpelprocess1_client_ep/BPELProcess1Callback_pt)"> 
            <wsp:PolicyReference 
URI="oracle/wss_username_token_service_policy" 
                           orawsp:category="security" 
orawsp:status="enabled"/> 
 </binding.ws> 
    </callback> 
    
. 
  </reference>