5 Securing SOA Composite Applications

This chapter describes security configuration procedures unique to SOA composite applications, such as mapping the SOAOperator and SOAMonitor roles to Oracle WebLogic Server groups or users. Most SOA composite application security procedures do not require SOA-unique configuration steps. References are provided to additional documentation for performing those tasks.

This chapter includes the following sections:

5.1 Introduction to Securing SOA Composite Applications

This chapter describes security procedures unique to SOA composite applications. Most SOA composite application security procedures do not require SOA-unique steps and can be performed by following the documentation listed in Table 5-1.

Table 5-1 Security Documentation

For Information On... See The Following Guide...

Securing Oracle Fusion Middleware, including Oracle Single Sign-On (OSSO) configuration

Oracle Fusion Middleware Application Security Guide

Securing and administering web services

Oracle Fusion Middleware Security and Administrator's Guide for Web Services

Understanding Oracle WebLogic Server security

Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server

Securing an Oracle WebLogic Server production environment

Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server

Securing Oracle WebLogic Server

Oracle Fusion Middleware Securing Oracle WebLogic Server

Developing new security providers for use with Oracle WebLogic Server

Oracle Fusion Middleware Developing Security Providers for Oracle WebLogic Server

Securing web services for Oracle WebLogic Server

Oracle Fusion Middleware Securing WebLogic Web Services for Oracle WebLogic Server

Programming security for Oracle WebLogic Server

Oracle Fusion Middleware Programming Security for Oracle WebLogic Server

Securing Oracle Business Activity Monitoring

Section 24.9, "Configuring Security"

Securing Oracle User Messaging Service

Section 27.6, "Securing the Oracle User Messaging Service"


5.2 Mapping the SOAOperator and SOAMonitor Roles to Oracle WebLogic Server Groups or Users

There is no default mapping of the SOAMonitor and SOAOperator roles to Oracle WebLogic Server groups or users. These roles must be manually mapped in Oracle Enterprise Manager Fusion Middleware Control.

You have the following options:

  • Mapping the SOAMonitor role to the Oracle WebLogic Server Monitors group or to an individual user that you created.

  • Mapping the SOAOperator role to the Oracle WebLogic Server Operators group or to an individual user that you created.

Create the mapping option that is best for your environment. The instructions in this section describe how to create both options.

WARNING:

Only the SOAAdmin role is automatically mapped to the Oracle WebLogic Server Administrator role. Possessing only the Oracle WebLogic Server groups (Monitors/Operators) does not provide you with access to Oracle SOA Suite content until the corresponding Oracle WebLogic Server group or user is mapped to the Oracle SOA Suite application role (SOAMonitor/SOAOperator).

Perform the following steps to map the SOAMonitor and SOAOperator roles to groups or users.

  1. Log in to Oracle Enterprise Manager Fusion Middleware Control as a user with the Administrators role.

  2. In the navigator, expand the SOA folder.

  3. Right-click soa-infra, and select Security > Application Roles.

  4. To the right of the Role Name field, click the Search icon.

    The list of roles appears.

  5. Click SOAMonitor, and select Edit.

    The Edit Application Role : SOAMonitor page appears.

  6. Click the Add icon.

    The Add Principal dialog is displayed.

  7. From the Type list, select to map SOAMonitor to either a group or an individual user:

    • Group: For mapping to the Monitors group.

    • User: For mapping to an individual user you created.

  8. Click the Search icon.

    If you selected Group, the Monitors group is displayed in the list. If you selected User, the individual user is displayed in the list.

  9. Make your selection in the list, and click OK.

    The user or group you selected is added to the Members section of the Edit Application Role : SOAMonitor page.

  10. Click OK to save the changes and return to the Application Roles page.

  11. To the right of the Role Name field, click the Search icon.

    The list of roles appears.

  12. Click SOAOperator, and select Edit.

    The Edit Application Role : SOAOperator page appears.

  13. Click the Add icon.

    The Add Principal dialog is displayed.

  14. From the Type list, select to map SOAOperator to either a group or an individual user:

    • Group: For mapping to the Operators group.

    • User: For mapping to an individual user you created.

  15. Click the Search icon.

    If you selected Group, the Operators group is displayed in the list. If you selected User, the individual user is displayed in the list.

  16. Make your selection in the list, and click OK.

    The user or group you selected is added to the Members section of the Edit Application Role : SOAOperator page.

  17. Click OK to save the changes and return to the Application Roles page.

5.3 Configuring Oracle HTTP Server with Oracle BPM Worklist

You must add the /integration location in the mod_wl_ohs.conf file of Oracle HTTP Server for Oracle BPM Worklist to work through Oracle HTTP Server.

  <Location /integration>
       SetHandler weblogic-handler
   #   PathTrim /weblogic
       ErrorPage  http:/WEBLOGIC_HOME:WEBLOGIC_PORT/
  </Location>

5.4 Setting up SAML Message-Protected Policy Configuration for the SOA Infrastructure

This section describes how to set up and validate Security Assertion Markup Language (SAML) message-protected policy configuration for the SOA Infrastructure with the Oracle WebLogic Scripting Tool (WLST). The example in this section describes task query service configuration. However, these instructions are relevant to all human workflow services that support SAML-token ports:

  • Activity guide query service

  • Activity guide metadata service

  • Activity guide admin service

  • Task query service

  • Task service

  • Task metadata service

  • Runtime config service

  • Task evidence service

  • User metadata service

If you want to change the policy for another service, you must apply the same WLST commands to that service's SAML-token port.

To set up an SAML message-protected policy configuration:

  1. Log in to the SOA domain (for example, named base_domain) using WLST.

  2. Detach the existing out-of-the-box service policy named wss10_saml_token_service_policy.

    wls:/base_domain/domainRuntime> detachWebServicePolicy('/base_domain/soa
    _server1/soa-infra','integration/services/TaskQueryService','web',
    'WorkflowProvider','TaskQueryServicePortSAML','oracle/
    wss10_saml_token_service_policy')
    
  3. Restart the application to activate any policy or configuration change.

  4. Attach the new policy. In this case, the policy is named oracle/wss10_saml_token_with_message_protection_service_policy.

    wls:/base_domain/domainRuntime> attachWebServicePolicy('/base_domain/soa
    _server1/soa-infra','integration/services/TaskQueryService',
    'web','WorkflowProvider','TaskQueryServicePortSAML','ora
    cle/wss10_saml_token_with_message_protection_service_policy')
    
  5. Restart the application to activate any policy or configuration change.

  6. List the policy to validate.

    wls:/base_domain/domainRuntime> listWebServicePolicies('/base_domain/soa
    _server1/soa-infra','integration/services/TaskQueryService',
    'web','WorkflowProvider','TaskQueryServicePortSAML')
        TaskQueryServicePortSAML :
        security :
    oracle/wss10_saml_token_with_message_protection_service_policy,
        enabled=true 
    Attached policy or policies are valid; endpoint is secure.
    
  7. Create a keystore, add the orakey alias, and run the Oracle Web Service Manager (OWSM) configuration to activate the SAML message-protected policy. For example:

    keytool -genkeypair
            -keystore  domain_home/config/fmwconfig/default-keystore.jks
            -keyalg RSA
            -dname "cn=consumer,dc=example,dc=com"
            -alias clientalias
            -keypass  password 
            -storepass password
            -validity 3600
    
    keytool -exportcert 
            -keystore domain_home/config/fmwconfig/default-keystore.jks
            -v 
            -alias clientalias
            -storepass password 
            -rfc 
            -file domain_home/config/fmwconfig/certificate.cer
    
    keytool -importcert 
            -keystore domain_home/config/fmwconfig/default-keystore.jks
            -alias orakey
            -file domain_home/config/fmwconfig/certificate.cer
            -storepass password
             createCred(map="oracle.wsm.security", key="keystore-csf-key",
             user="owsm", password="welcome1", desc="Keystore key")
             createCred(map="oracle.wsm.security", key="enc-csf-key",
             user="clientalias", password="welcome1", desc="Encryption key")
             createCred(map="oracle.wsm.security", key="sign-csf-key",
             user="clientalias", password="welcome1", desc="Signing key") 
    
  8. Restart the servers.

5.5 Automatically Authenticating Oracle BPM Worklist and Oracle Business Process Management Users

This section describes how to authenticate Oracle BPM Worklist and Oracle Business Process Management users in different environments.

5.5.1 Automatically Authenticating Oracle BPM Worklist Users in SAML SSO Environments

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 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 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 Oracle BPM Worklist 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 about SAML2IdentityAsserter and configuring SSO with web browsers and HTTP clients, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

5.5.2 Automatically Authenticating Oracle BPM Workspace Users in SAML SSO Environments

To be automatically authenticated when accessing a second Oracle BPM Workspace from a first Oracle BPM Workspace 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 Workspace. In these environments, the first Oracle BPM Workspace is configured as the SAML identity provider and the second Oracle BPM Workspace that you access is configured as the SAML service provider.

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

  1. Add /bpm/workspace/* as the redirect URL for workspace 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 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 Oracle BPM Workspace 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 /bpm/workspace/* to the list.

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

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

5.5.3 Automatically Authenticating Oracle Business Process Composer Users in SAML SSO Environments

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

To automatically authenticate Oracle Business Process Composer users in SAML SSO environments:

  1. Add /bpm/composer/* as the redirect URL for composer 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 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 Oracle Business Process Composer 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 /bpm/composer/* to the list.

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

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

5.5.4 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.

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

For Windows native authentication through Kerberos to work with Oracle Business 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.

5.6 Setting the Authentication Provider

This section describes how to set the first authentication provider.

5.6.1 Listing Oracle Internet Directory as the First Authentication Provider

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.

5.6.2 Accessing Web-based Applications with the Default Authentication Provider

Logging in 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

5.7 Invoking a Web Service that Requests NTLM Authentication

When attempting to invoke a web service that requests NT LAN Manager (NTLM) authentication, you must set the following properties in the composite.xml file:

  • oracle.webservices.auth.username

  • oracle.webservices.auth.password

  • oracle.webservices.preemptiveBasicAuth

You must set oracle.webservices.preemptiveBasicAuth to false.

Example 5-1 provides details.

Example 5-1 composite.xml File Configured for NTLM Authentication

<reference name="Service1" ui:wsdlLocation="test1.wsdl">
   <interface.wsdl
 interface="http://tempuri.org/#wsdl.interface(IService1)"/>
   <binding.ws
 
port="http://tempuri.org/#wsdl.endpoint(Service1/BasicHttpBinding_IService1)" 
               location="test1.wsdl" soapVersion="1.1">
     <property name="weblogic.wsee.wsat.transaction.flowOption"
               type="xs:string" many="false">WSDLDriven</property>
              
                <property name="oracle.webservices.auth.username"
               type="xs:string" many="false">test</property>
                <property name="oracle.webservices.auth.password"
               type="xs:string" many="false">password</property>
                <property name="oracle.webservices.preemptiveBasicAuth"
               type="xs:string" many="false">false</property>
   </binding.ws>
 </reference>

Not setting these properties results in the following error when the BPEL process attempts to invoke the web service.

setting preemptive basic auth" and "invoke failed...Bad response: 401 Unauthorized

5.8 Configuring SSL

This section describes how to configure secure socket layer (SSL) in Oracle SOA Suite and Oracle Business Process Management environments.

5.8.1 Using SSL Certificates When the SOA/BPM Server Is Configured with an HTTPS Port

If the SOA/BPM server is configured with an HTTPS port, ensure that your SSL certificate adheres to the following standards:

  • The certificate that the server presents to SSL clients (the browser or other internal clients such as the notification senders) is a trusted certificate by its own trust store (the CA store).

  • If the certificate for the server is self-signed, ensure that you add it to the trust store. That is, the certificate that the server presents must validate itself against the server trust store.

Not doing so can cause problems when task notifications are sent. For example, you can receive the error message shown in Example 5-2 in the server out log (for example, soa_server1.out).

Example 5-2 Task Notification Error

<Sep 13, 2011 12:59:41 AM PDT> <Error> <oracle.soa.services.workflow.common>
<BEA-000000> <<.>
ORABPEL-0
        at
oracle.bpel.services.workflow.task.notification.
TaskNotifications.getEmailPaylOad
(TaskNotifications.java:1354)
        at
oracle.bpel.services.workflow.task.notification.
TaskNotifications.getEmailNotificationContent
(TaskNotifications.java:987)
        at
weblogic.jms.client.JMSSession$UseForRunnable.run
(JMSSession.java:5170)
        at
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerI
mpl.java:528)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
Caused By: javax.net.ssl.SSLKeyException: [Security:090477]Certificate chain
received from myhost.us.example.com - 10.232.152.78 was not trusted causing
SSL handshake failure.
        at
com.certicom.tls.interfaceimpl.TLSConnectionImpl.
fireException(UnknownSource)
        at
com.certicom.tls.interfaceimpl.TLSConnectionImpl.
fireAlertSent(UnknownSource)
        at
com.certicom.tls.record.handshake.HandshakeHandler.
fireAlert(Unknown Source).
ficationContent(TaskNotifications.java:987)
        at
weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5170)
        at
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerI
mpl.java:528)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
Caused By: javax.net.ssl.SSLKeyException: [Security:090477]Certificate chain
received from myhost.us.example.com - 10.232.152.78 was not trusted causing
SSL handshake failure.
        at
com.certicom.tls.interfaceimpl.TLSConnectionImpl.
fireException(UnknownSource)
        at
com.certicom.tls.interfaceimpl.TLSConnectionImpl.
fireAlertSent(UnknownSource)
        at
com.certicom.tls.record.handshake.HandshakeHandler.
fireAlert(Unknown Source

For more information about concepts and configuration details, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

5.8.2 Recommendation to Configure Either All or 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 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.

5.8.3 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.

5.8.4 Configuring SOA Composite Applications for Two-Way SSL Communication

Oracle SOA Suite uses both Oracle WebLogic Server and Oracle 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 Oracle 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 line 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.

Note:

Both the server and client are assumed to have been configured for SSL with mutual authentication.

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 composite.xml 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"
    

5.8.5 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 syntax results in an SSL handshake exception.

  <import namespace="/adfbc1/common/" 
           
 location="https://myhost05.us.example.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.example.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.example.com in the certificate's CN, then you can use myhost05, myhost05.us.example.com, or the IP address from a browser. In Oracle JDeveloper, always use the same name as in the certificate (that is, myhost05.us.example.com).

5.8.6 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.

5.8.6.1 Configuring Oracle HTTP Server for SSL Communication

To configure Oracle HTTP server for SSL communication:

  1. Update mod_ssl.conf with the <Location /integration/services> location directive.

    LoadModule weblogic_module   ${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so
    
    <IfModule mod_weblogic.c>
          WebLogicHost host.domain.com
          WLLogFile <logdir>/ohs_ssl.log
          Debug ALL
          DebugConfigInfo ON
          SecureProxy ON
          MatchExpression *.jsp
          WlSSLWallet <OHS_
    HOME>/instances/instance1/config/OHS/ohs1/keystores/default
    </IfModule>
    
    <Location /soa-infra>
          WebLogicPort 8002
          SetHandler weblogic-handler
          ErrorPage http://host.domain.com:port/error.html
    </Location>
    
    <Location /b2bconsole>
          WebLogicPort 8002
          SetHandler weblogic-handler
          ErrorPage http://host.domain.com:port/error.html
    </Location>
    
    <Location /b2b> 
          WebLogicPort 8002 
          SetHandler weblogic-handler 
           ErrorPage http://host.domain.com:port/error.html 
    </Location> 
    
    <Location /integration/worklistapp>
          WebLogicPort 8002
          SetHandler weblogic-handler
          ErrorPage http://host.domain.com:port/error.html
    </Location>
    
    <Location /integration/services>
          WebLogicPort 8002
          SetHandler weblogic-handler
          ErrorPage http://host.domain.com:port/error.html
    </Location>
    
    <Location /DefaultToDoTaskFlow>
          WebLogicPort 8002
          SetHandler weblogic-handler
          ErrorPage http://host.domain.com:port/error.html
    </Location>
    
    <Location /OracleBAM>
          WebLogicPort 9002
          SetHandler weblogic-handler
          ErrorPage http://host.domain.com:port/error.html
    </Location>
    
    <Location /OracleBAMWS>
          WebLogicPort 9002
          SetHandler weblogic-handler
          ErrorPage  http://host.domain.com:port/error.html
    </Location>
    
    <Location /sdpmessaging/userprefs-ui/>
          WebLogicPort 8002
          SetHandler weblogic-handler
          ErrorPage http://host.domain.com:port/error.html
    </Location>
    
  2. Start the Oracle WebLogic Servers as described in Section 5.8.4, "Configuring SOA Composite Applications for Two-Way SSL Communication."

5.8.6.2 Configuring Certificates for Oracle Client, Oracle HTTP Server, and Oracle WebLogic Server

To configure certificates for Oracle Client, Oracle HTTP Server, and Oracle WebLogic Server:

  1. Export the user certificate from the Oracle HTTP Server wallet.

    orapki wallet export -wallet . -cert cert.txt  -dn 'CN=\"Self-Signed
     Certificate for ohs1 \",OU=OAS,O=ORACLE,L=REDWOODSHORES,ST=CA,C=US'
    
  2. Import the above certificate into the Oracle WebLogic Server trust store as a trusted certificate.

    keytool -file cert.txt -importcert -trustcacerts -keystore DemoTrust.jks
    
  3. Export the certificate from the Oracle WebLogic Server trust store.

    keytool -keystore DemoTrust.jks -exportcert -alias wlscertgencab -rfc -file
    certgencab.crt
    
  4. Import the above certificate to the Oracle HTTP Server wallet as a trusted certificate.

    orapki wallet add -wallet . -trusted_cert -cert certgencab.crt -auto_login_only
    
  5. Restart Oracle HTTP Server.

  6. Restart the Oracle WebLogic Servers as described in Section 5.8.4, "Configuring SOA Composite Applications for Two-Way SSL Communication."

5.8.7 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).

5.8.8 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
    

5.8.9 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 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> 

5.9 Configuring Security for Human Workflow WSDL Files

If the WSDL files for human workflow services are not exposed to external consumers, then set the flag that exposes the WSDL to false for each of the services:

<expose-wsdl>false</expose-wsdl>