Skip Headers
Oracle® Fusion Middleware Developer's Guide for Oracle Service Bus
11g Release 1 (11.1.1.6.3)

Part Number E15866-08
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

49 Configuring Transport-Level Security

This chapter describes how to configure transport-level security for different transports in Oracle Service Bus (OSB).

Transport-level security applies security checks as part of establishing a connection between service consumers, proxy services, and business services. The type of security checks that Oracle Service Bus can apply depends on the protocol that the proxy service or business service uses to communicate. Some protocols can also encrypt the communication between client and endpoint to prevent snooping from third parties.

Inbound transport-level security secures the communication between clients and Oracle Service Bus proxy services. Outbound transport security secures all three techniques of sending outbound requests from Oracle Service Bus proxy services: route actions, publish actions, and callout actions.

This chapter includes the following sections:

49.1 Configuring Transport-Level Security for HTTPS

The HTTPS protocol uses SSL to secure communication. SSL can be used to encrypt communication, ensure message integrity, and to require strong server and client authentication. Before you can use HTTPS, you must configure SSL in Oracle WebLogic Server, see Section 45.7, "Configuring the Oracle WebLogic Security Framework: Main Steps."

The following sections describe configuring transport-level security for the HTTPS protocol:

49.1.1 HTTPS Authentication Levels

For each proxy service or business service that communicates over the HTTPS protocol, you can configure the service to require one of the following levels of authentication:

  • One-way SSL, no authentication

    This level enables encrypted communication but does not require clients to provide credentials. To establish a one-way SSL connection, the client initiates the connection and Oracle Service Bus sends its certificate to the client. In other words, the client authenticates Oracle Service Bus.

  • One-way SSL, BASIC authentication

    This level enables encrypted communication and requires clients to supply a user name and password after the one-way SSL connection is established. The client supplies a user name and password by encoding it in the HTTP request header (which is encrypted by SSL). When the proxy service receives the encrypted request, it passes the credentials to the domain's authentication provider, which determines whether the client's credentials match a user account that you have created.

  • Two-way SSL, CLIENT CERT authentication

    This level enables encrypted communication and strong client authentication (two-way SSL).

    To establish a two-way SSL connection, the client initiates the connection and Oracle Service Bus sends its X.509 certificate to the client. Then, the client sends its certificate to Oracle Service Bus and Oracle Service Bus authenticates the client.

    To get the user name from the client's certificate, you configure an identity assertion provider, which extracts a field in the certificate to use as the client identity (X.509 token), typically the CN (common name) or E (email) of the SubjectDistinguishedName in the certificate. After extracting the X.509 token, the token is compared to the user accounts in the Security Configuration module of the Oracle Service Bus Administration Console.

    For more information about SSL and identity assertion providers, see "Security Fundamentals" in Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server.

  • Transport-Level Custom Credentials.

    You can authenticate client requests at the transport-level via custom authentication tokens. Transport-level custom credentials are supported only on inbound requests. You specify a custom token in an HTTP header. The HTTP-specific configuration pages of the service definition wizard allows you to configure client authentication. Custom authentication concepts are described in Chapter 54, "Configuring Custom Authentication."

49.1.2 Configuring Inbound HTTPS Security: Main Steps

To configure inbound transport-level security for a proxy service:

  1. Make sure that you have configured the WebLogic security framework to support SSL, an authentication provider, and an identity assertion provider, depending on the HTTPS authentication level that you want to use:

    • For no client authentication (anonymous requests), set Client Authentication to None.

    • For basic authentication, set Client Authentication to Basic. See "Adding Users" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

    • For SSL client authentication, set Client Authentication to Client Certificate, configure the WebLogic Identity Assertion provider and the WebLogic CertPath Provider.

    • For custom authentication token, set Client Authentication to Custom Authentication. The custom authentication token can be any active token type previously configured for an Identity Assertion provider that is carried in an HTTPS header. Custom authentication concepts are described in Chapter 54, "Configuring Custom Authentication."

      Note:

      You must first configure, or create and configure, an Oracle WebLogic Server Identity Assertion provider as described in Section 54.5, "Configuring Identity Assertion Providers for Custom Tokens," and add the user names and passwords of the clients that you want to allow access to the Security Configuration module of the Oracle Service Bus Administration Console.

    See Section 45.7, "Configuring the Oracle WebLogic Security Framework: Main Steps."

  2. When you create a proxy service, on the Transport Configuration page select HTTP.

  3. On the HTTP Transport Configuration page, select the "HTTPS required" option.

  4. Choose an authentication level, as described in Section 49.1.1, "HTTPS Authentication Levels."

  5. Make your Dispatch Policy, Request Encoding, and Response Encoding choices, as described in Section 4.3, "Proxy Service Configuration."

  6. If the service you are creating is WSDL-based and has operations, make your selections on the Operation Selection Configuration page. Determine whether to enforce WS-I compliance (for SOAP 1.1 services only) and select the selection algorithm to use to determine the operation called by this proxy service. This option is available only for SOAP or XML services defined from a WSDL.

49.1.3 Configuring Outbound HTTPS Security: Main Steps

In outbound transport-level security, a proxy service is the client that opens a connection with a business service.

To configure outbound transport-level security:

  1. If you are configuring transport-level security for a production environment (as opposed to a development or testing environment), make sure that Host Name Verification is enabled. See "Using Host Name Verification" in "Configuring SSL" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

  2. When you create a business service, on the Transport Configuration page, select HTTP.

    Choose an authentication level.

    If you configured the proxy service such that Oracle Service Bus does not authenticate clients, configure the enterprise system to authenticate clients by selecting an authentication level of one-way SSL, which is the "BASIC" authentication option.

  3. The URI determines whether HTTP or HTTPS is used. HTTP business services can combine HTTP and HTTPS URLs unless the authentication method is Client Certificate, in which case all URLs must be HTTPS.

  4. If the business service uses HTTPS with BASIC authentication, create a service account to provide the user name and password that the business service requires.

    You can add a user name and password directly to the service account, or configure the service account to pass through the credentials that it received from its client's request, or you can map a client user name to an Oracle Service Bus user. If you configured the proxy service so that Oracle Service Bus does not authenticate clients, create a service account that passes through the credentials.

  5. If the business service uses Client Certificate authentication, do the following:

    1. Create a service key provider to provide the key-pair that proxy services use for SSL client authentication with the business service. See "Service Key Providers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

    2. Create a proxy service or edit an existing proxy service so that it specifies the service key provider. See Section 2.3, "Working with Proxy Services."

49.2 Configuring Transport-Level Security for HTTP

The HTTP protocol does not encrypt communication between clients and proxy services or business services, but it does support BASIC authentication in which clients send user names and passwords in requests. HTTP also supports custom token authentication.

Caution:

Unless you have configured strong network security, Oracle recommends that you do not use BASIC authentication with HTTP in production environments because the password is sent in clear text. Instead, use BASIC authentication with HTTPS.

The following sections describe configuring transport-level security for the HTTP protocol:

49.2.1 Configuring Inbound HTTP Security: Main Steps

To configure inbound transport-level security for a proxy service:

  1. When you create a proxy service, on the Transport Configuration page select HTTP. Choose the Client Authentication option None, Basic, or Custom Authentication. If you choose Custom Authentication, you must also specify the HTTP header that is to carry the token and the token type.

    The steps for configuring transport-level custom credentials are described in Section 2.3, "Working with Proxy Services." Custom authentication concepts are described in Chapter 54, "Configuring Custom Authentication."

    The custom authentication token can be any active token type, previously configured for an Identity Assertion provider, that is carried in an HTTP header.

    Note:

    To use custom authentication you must first configure, or create and configure, an Oracle WebLogic Server Identity Assertion provider as described in Section 54.5, "Configuring Identity Assertion Providers for Custom Tokens."

    If you want Oracle Service Bus to authenticate clients (Basic or Custom Authentication) you must create user accounts for the clients. See Section 47.3, "Configuring Administrative Security: Main Steps."

  2. Modify the proxy service's default transport-level access control policy, which specifies conditions under which users, groups, or roles can access a proxy service. See "Editing Transport-Level Access Policies" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

49.2.2 Configuring Outbound HTTP Security: Main Steps

In outbound transport-level security, a proxy service is the client that opens a connection with a business service.

To configure outbound transport-level security:

  1. When you create a business service, select HTTP on the Transport Configuration page. On the HTTP Transport page, select Basic.

    See Section 2.2, "Working with Business Services."

  2. Create a service account to provide the user name and password that the business service requires. SeeSection 2.1.15, "Creating Service Account Resources."

    You can add a user name and password directly to the service account, or configure the service account to pass through the credentials that it received from its client's request, or you can map a client user name to an Oracle Service Bus user. If you configured the proxy service so that Oracle Service Bus does not authenticate clients, create a service account that passes through the credentials.

  3. Create a proxy service or edit an existing proxy service so that it specifies the service account.

49.3 Configuring Transport-Level Security for JMS

While transport-level security for JMS does not provide end-to-end security for JMS messaging, it does provide the following:

The following sections describe configuring JMS transport-level security:

49.3.1 Configuring Inbound JMS Transport-Level Security: Main Steps

To configure inbound JMS transport-level security:

  1. When you create or edit a JMS proxy service, on the Transport Configuration page, under Advanced Settings, select the Use SSL check box.

    Oracle Service Bus configures the JMS proxy service to use the T3S protocol.

  2. If the JMS administrator created access control policies that restrict access to a JMS connection pool, configure the proxy service to authenticate when it connects to the JMS server:

    1. Create a service account to provide the user name and password that the JMS server requires. See Section 2.1.15, "Creating Service Account Resources."

      The JMS service account for the proxy service is used not only for the JMS object access, but also for the JNDI lookup.

      You must add a user name and password directly in the service account. JMS cannot use a service account that passes through the credentials that it received from its client's request or that maps a client user name to an Oracle Service Bus user.

    2. When you create or edit the proxy service, on the JMS Transport page, click the Browse button next to JMS Service Account. Select the service account that you created in the previous step.

49.3.2 Configuring Outbound JMS Transport-Level Security: Main Steps

To configure outbound JMS transport-level security:

  1. When you create or edit a JMS business service, on the Transport Configuration page, under Advanced Settings, select the Use SSL check box.

    Oracle Service Bus configures the JMS business service to use the T3S protocol.

  2. If the JMS administrator created access control policies that restrict access to a JMS connection pool, configure the business service to authenticate when it connects to the JMS server:

    1. Create a service account to provide the user name and password that the JMS server requires. See Section 2.1.15, "Creating Service Account Resources."

      The JMS service account for the proxy service is used not only for the JMS object access, but also for the JNDI lookup.

      You must add a user name and password directly in the service account. JMS cannot use a service account that passes through the credentials that it received from its client's request or that maps a client user name to an Oracle Service Bus user.

    2. When you create or edit the business service, on the JMS Transport page, click the Browse button next to JMS Service Account. Select the business account that you created in the previous step.

  3. Select the Pass Caller's Subject check box to have Oracle Service Bus pass the authenticated subject when sending a message.

49.4 Configuring Transport-Level Security for SFTP Transport

As described in Section 26.5, "SFTP Transport," Oracle Service Bus supports the SFTP transport for inbound and outbound transport-level security. The SFTP transport uses Secure Shell (SSH) version 2 to transfer files.

49.4.1 How Two-Way Authentication is Performed

The SFTP authentication is two–way: both the SFTP server and SFTP client (Oracle Service Bus service) authenticate each other, via different mechanisms:

  • The SFTP server uses the authentication method you specified in the Transport Configuration page to authenticate the SFTP client (the Oracle Service Bus service): Username Password, Host Based, or Public Key.

  • The SFTP client (the Oracle Service Bus service) uses a known_hosts file to authenticate the SFTP server. The known_hosts file on the Oracle Service Bus proxy service (inbound requests) or business service (outbound requests) system must have the hostname, IP address, and public key of the remote SFTP servers to which the proxy service or business service can connect. SSH version 2 uses this public key to authenticate the connection.

The SFTP client (the Oracle Service Bus service) always uses the known_hosts file to determine whether to connect to an SFTP server, no matter which of the three authentication methods is chosen in the Transport Configuration page. That is, in all cases the SFTP server is authenticated by the Oracle Service Bus service using the information present in this file. This ensures that the Oracle Service Bus service is connecting to a known server.

For example, in case of Username Password authentication, the SFTP Client (Oracle Service Bus Service) authenticates the SFTP server against the SFTP server's public key in the known_hosts file. The SFTP server authenticates the client (Oracle Service Bus service) with the username and password from the service account.

49.4.2 Use of the known_hosts File

No matter which authentication method you choose in the Transport Configuration page, a known_hosts file on the Oracle Service Bus proxy service (inbound requests) or business service (outbound requests) system must have the hostname, IP address, and public key of the remote SFTP servers to which the proxy service or business service can connect.

The Oracle Service Bus service authenticates the SFTP server with the public-key/host/IP combination present in the known_hosts file.

Note:

This SSH authentication mechanism is outside of the typical Oracle Service Bus service key provider/PKI credential mapper process.

The known_hosts file requirement must be satisfied during authentication. SFTP servers not listed in the known_hosts file are not authenticated.

Creating the known_hosts File 

  1. Use the editor of your choice to create a known_hosts text file.

    The format for known_hosts is as follows:

    Hostname,IP   algorithm  public-key
    

    where Hostname, IP, and public_key identify the SFTP server.

    The algorithms supported are RSA (entered only as ssh-rsa) and DSA (entered only as ssh-dsa or ssh-dss).

    The public key format for this file is "OpenSSH public key format."

    For example:

    getafix,172.22.52.130   ssh-rsa   AAAAB3NzaC1yc2EAAAABIwAAAIEAtR+M3Z9HFxnKZTx66fZdnQqAHQcF1vQe1+EjJ/HWYtgAnqsn0hMJzqWMatb/u9yFwUpZBirjm3g2I9Qd8VocmeHwoGPhDGfQ5LQ/PPo3esE+CGwdnCOyRCktNHeuKxo4kiCCJ/bph5dRpghCQIvsQvRE3sks+XwQ7Wuswz8pv58=
    

    Multiple entries are supported, one entry per line.

  2. Move the known_hosts file to the following directory:

    MW_HOME/user_projects/domains/osb_domain/osb/transports/sftp

    The directories /transports/sftp are not created automatically. You must create them.

49.4.3 SFTP Transport Authentication Process

The following general principles apply to the SFTP authentication process for both a proxy service and business service.

  • Connection: The Oracle Service Bus service (proxy and business) always acts as the SFTP client and connects to the SFTP server.

  • Authentication by the SFTP Server: For Public Key and Host Based authentication, the SFTP server authenticates the connection with the public key of the Oracle Service Bus service. For Username Password, the SFTP server authenticates the connection with the username and password.

  • Authentication by the SFTP Client: The Oracle Service Bus service always authenticates the SFTP server with the public-key/host/IP combination present in the known_hosts file.

  • Connection established: If both the server and client authentications are successful, only then is the connection established and ready for transfer.

  • Transfer: The file (message) is downloaded in case of the proxy service and uploaded in the case of the business service.

The SFTP authentication process is as follows:

  • Inbound one-way download to the proxy service:

    1. The proxy service, which is the SFTP client, attempts to connect to the SFTP server.

    2. The proxy service is authenticated by the SFTP server via the authentication mechanism selected on the Transport Configuration page.

      For Host Based and Public Key authentication, the remote SFTP server uses the host name and public key of the proxy service to authenticate the Oracle Service Bus system. For Username Password authentication, the SFTP server uses the username and password supplied by the proxy service (via the service account) to authenticate the Oracle Service Bus system.

    3. A known_hosts file (on the Oracle Service Bus proxy service system) keeps the information of the remote SFTP servers to which the Oracle Service Bus proxy service can connect.

      Specifically, this file contains the host name, IP address, and public key of the accepted remote servers.

      SSH version 2 uses this public key to authenticate the connection. SFTP servers not listed in the known_hosts file are not authenticated.

    4. If authentication is successful, the proxy service is the SFTP client connected to the remote SFTP server.

    5. If allowed by the SFTP server, the proxy service (the SFTP client) polls a remote directory on the SFTP server and downloads any files (messages) present in the remote directory.

      The proxy service configuration determines which remote directory to poll, how often to poll it, and what to do with any files (messages) that it downloads.

  • Outbound one-way upload from the business service:

    1. The business service (which is the SFTP client) attempts to connect to the SFTP server.

    2. The business service is authenticated by the SFTP server via the authentication mechanism selected on the Transport Configuration page.

      For Host Based and Public Key authentication, the SFTP server uses the host name and public key of the business service to authenticate the Oracle Service Bus system. For Username Password authentication, the SFTP server uses the username and password (from the service account) to authenticate the Oracle Service Bus system.

    3. A known_hosts file (on the Oracle Service Bus business service system) keeps the information of the SFTP servers to which the Oracle Service Bus business service can connect.

      Specifically, this file contains the host name, IP address, and public key of the accepted servers.

      SSH version 2 uses this public key to authenticate the connection. SFTP servers not listed in the known_hosts file are not authenticated.

    4. If authentication is successful, the business service is the SFTP client connected to the remote SFTP server.

    5. If allowed by the SFTP server, the business service (the SFTP client) uploads files to the remote directory on the SFTP server.

      The business service configuration determines in which remote directory to upload the file, how often to retry the upload, and any file prefix or suffix to add to the uploaded file name.

49.4.4 Configuring Inbound SFTP Transport-Level Security: Main Steps

To configure inbound transport-level security for a proxy service:

  1. Create a known_hosts file, as described in Section 49.4.2, "Use of the known_hosts File," on the Oracle Service Bus proxy service system.

    known_hosts keeps the information of the remote SFTP servers to which the Oracle Service Bus proxy service can connect. Specifically, this file contains the host name, IP address, and public key of the accepted remote servers.

    SSH version 2 uses this public key to authenticate the connection. SFTP servers not listed in the known_hosts file are not authenticated.

  2. When you create a proxy service, on the Transport Configuration page select SFTP.

  3. Specify the end point URI in sftp://hostname:port/directory format, where:

    • hostname is the host name or IP address of the SFTP server.

    • port is the port on which SFTP server is listening. Default port for SFTP is 22.

    • directory is the location that is periodically polled for files. This directory is relative to the home directory of the user.

  4. On the SFTP Transport Configuration page, select either Username Password, Host Based, or Public Key authentication.

    The authentication choices are summarized here. See Section 26.5, "SFTP Transport" for complete information.

    • Username/Password authentication specifies that a static service account (using user credentials on the SFTP server) is associated with this authentication method. The service account provides a user name and password that the proxy service uses for authentication to the SFTP server. The SFTP client is authenticated using the provided credentials. Only the static service account type is supported.

    • Host Based Authentication specifies that only connections from identified, known hosts are allowed. This authentication method requires a username and a service key provider.

      The SFTP Server authenticates the proxy service with the public key of the proxy service.

      Note:

      The Oracle Service Bus proxy service does not itself use the service key provider to authenticate any credentials from the SFTP server. It uses only the known_hosts file to authenticate the SFTP server.

      The public key of the proxy service is present in the key-pair referred by the service key provider. You need to extract this key when you set up the service key provider, and then configure the SFTP server to use the public key.

      For example, with SFTP server on Linux, you need to:

      • Edit the /etc/ssh/shosts.equiv file and add the host name or IP address of the machine on which Oracle Service Bus domain is running.

      • Edit the /etc/ssh/ssh_known_hosts file and add the host name or IP address of the machine on which Oracle Service Bus domain is running, followed by space and the public key.

      The username is used to determine which directory on the SFTP server to poll.

    • Public Key specifies a username and service key provider are required to use this authentication method. Every user has their own private key.

      The SFTP Server authenticates the proxy service with the public key.

      Note:

      The Oracle Service Bus proxy service does not itself use the service key provider to authenticate any credentials from the SFTP server. It uses only the known_hosts file to authenticate the SFTP server.

      The public key of the proxy service is present in the key-pair referred by the service key provider. You need to extract this key when you set up the service key provider, and then configure the SFTP server to use the public key.

      For example, to allow access to a system for a given identity with an SFTP server on Linux, place the public key in a $HOME/.ssh/authorized_keys file on that system. All keys listed in that file are allowed access.

      The username is used to determine which directory on the SFTP server to poll. It is also use to identify the location of the public key on the SFTP server.

  5. If allowed by the remote SFTP server, the proxy service (SFTP client) polls a remote directory on the SFTP server and downloads any files present in the remote directory.

    The proxy service configuration determines which remote directory to poll, how often to poll it, and what to do with any files (messages) that it downloads.

    The directory to be polled is an absolute path.

49.4.5 Configuring Outbound SFTP Transport-Level Security: Main Steps

To configure outbound transport-level security for a business service:

  1. Create a known_hosts file, as described in Section 49.4.2, "Use of the known_hosts File," on the Oracle Service Bus business service system.

    known_hosts keeps the information of the remote SFTP servers to which the Oracle Service Bus business service can connect. Specifically, this file contains the host name, IP address, and public key of the accepted remote servers.

    SSH version 2 uses this public key to authenticate the connection. SFTP servers not listed in the known_hosts file are not authenticated.

  2. When you create a business service, on the Transport Configuration page select SFTP.

  3. Specify the end point URI in sftp://hostname:port/directory format, where:

    • hostname is the host name or IP address of the SFTP server.

    • port is the port on which SFTP server is listening. Default port for SFTP is 22.

    • directory is the location to which files are uploaded. This directory is relative to the home directory of the user.

  4. On the SFTP Transport Configuration page, select either Username Password, Host Based, or Public Key authentication.

    The authentication choices are summarized here. See Section 26.5, "SFTP Transport" for complete information.

    • Username/Password authentication specifies that a static service account (using user credentials on the SFTP server) is associated with this authentication method. The service account provides a user name and password that the business service uses for authentication to the SFTP server. The SFTP client is authenticated using the provided credentials. Only the static service account type is supported.

    • Host Based Authentication specifies that only connections from identified, known hosts are allowed. This authentication method requires a username and a service key provider.

      The SFTP Server authenticates the business service with the public key of the business service.

      Note:

      The Oracle Service Bus business service does not itself use the service key provider to authenticate any credentials from the SFTP server. It uses only the known_hosts file to authenticate the SFTP server.

      The public key of the business service is present in the key-pair referred by the service key provider. You need to extract this key when you set up the service key provider, and then configure the SFTP server to use the public key.

      For example, with SFTP server on Linux, you need to:

      • Edit the /etc/ssh/shosts.equiv file and add the host name or IP address of the machine on which Oracle Service Bus domain is running.

      • Edit the /etc/ssh/ssh_known_hosts file and add the host name or IP address of the machine on which Oracle Service Bus domain is running, followed by space and the public key.

      The username is used to determine the upload directory on the SFTP server.

    • Public Key specifies a username and service key provider are required to use this authentication method. Every user has their own private key.

      The SFTP Server authenticates the business service with the public key.

      Note:

      The Oracle Service Bus business service does not itself use the service key provider to authenticate any credentials from the SFTP server. It uses only the known_hosts file to authenticate the SFTP server.

      The public key of the business service is present in the key-pair referred by the service key provider. You need to extract this key when you set up the service key provider, and then configure the SFTP server to use the public key.

      For example, to allow access to a system for a given identity with an SFTP server on Linux, place the public key in a $HOME/.ssh/authorized_keys file on that system. All keys listed in that file are allowed access.

      The username is used to determine the upload directory on the SFTP server and for identifying the location of the public key on the SFTP server.

  5. If allowed by the remote SFTP server, the business service (SFTP client) uploads files to the remote directory on the SFTP server.

    The business service configuration determines in which remote directory to upload the file, how often to retry the upload, and any file prefix or suffix to add to the uploaded file name.

    The upload directory is an absolute path and is automatically created.

49.4.6 SFTP Security Attributes Preserved During Import

The following security attributes are preserved when Section 45.6.1, "Preserve Security and Policy Configuration Check Box" is turned on during import:

  • Client authentication method

  • Reference to the service account (in case of Username Password authentication)

  • Reference to the service key provider (in case of Host Based and Public Key authentication)

  • Username (in case of Host Based and Public Key authentication)

49.4.7 SFTP Credential Life Cycle

Whenever the username/password or public key credential changes, the SFTP transport drops all idle connections made with the previous credential and attempts to reconnect. For active connections, the SFTP transport drops the connection after the current operation is finished.

49.5 Email, FTP, and File Transport-Level Security

The following sections describe the security measures that are available for communication over the email, FTP, and file protocols:

49.5.1 Email and FTP Transport-Level Security

Email and FTP are not secure protocols. They support weak authentication, typically over insecure channels. The supported security method for email or FTP transport is the username and password needed to connect to the email or FTP server.

To secure email, you must designate a service account as an alias for the username and password. The service will use the username and password to authenticate to the SMTP server.

To secure the FTP transport, select external_user and designate a service account as an alias for the username and password. The service will use the username and password to authenticate to the FTP server.

For information about how to add security to email and FTP transport, see Section 2.2, "Working with Business Services"

49.5.2 File Transport Security

The supported security method for file transport is the user login to the computer on which the files are located.

The SFTP transport, described in Section 49.4, "Configuring Transport-Level Security for SFTP Transport," is the preferred mechanism to secure FTP.

49.6 Configuring Transport-Level Security for SB Transport

The Service Bus (SB) transport allows client Oracle Service Bus servers to invoke an Oracle Service Bus proxy service synchronously via RMI. RMI is the only mechanism by which client Oracle Service Bus servers can access the SB transport. In this release of Oracle Service Bus the associated API is for internal user only and is not documented.

The SB proxy service is accessed in one of two ways:

The SB business service can send messages only to SB proxy services. A JNDI provider, which is specified in the endpoint URI of the business service, is used to do a JNDI lookup on the remote Oracle Service Bus server. Specifically, the JNDI provider points to the Oracle Service Bus server where the service is deployed to retrieve the RMI stubs corresponding to the SB proxy service.

For example, the endpoint URI you specify in the business service could be sb://some_secured_jndi_provider/some_remote_sb_proxy.

A secure JNDI provider should have a provider URL with a secure protocol. In the SB business service case, you can use the HTTPS or t3s protocols.

The service account (of the business service) specifies the user credentials that should be used for invoking the remote SB proxy service. If no service account is specified, the user credentials of the inbound proxy service (the inbound client) of this business service are used for security context propagation.

The SB transport can use SSL to require strong server and client authentication. Before you can use the SB transport with SSL, you must configure SSL in Oracle WebLogic Server. See Section 45.7, "Configuring the Oracle WebLogic Security Framework: Main Steps."

Caution:

When set, the Use SSL flag means that request must be sent over an SSL connection. However, the SB transport does not forbid unsecured connections. The proxy service will be advertised (via the effective WSDL or UDDI) with a secured URI (indicated by sbs), but secured access is not enforced.

The Oracle Service Bus server administrator must close all unsecured protocols on the server (t3, http, and so forth) to strictly enforce secured-client connections.

49.6.1 Configuring SAML Authentication With Service Bus (SB) Transport

If you are using SAML-based authentication with the SB transport, be sure to follow these configuration requirements:

  • On the SB client side, configure a SAML Credential mapper provider and create a SAML relying party for each SB proxy service you plan to invoke from this client. In the target URL field enter http://openuri.org/<OSBProxyServiceURI>, where OSBProxyServiceURI is the service URI of the SB proxy service.

  • On the Oracle Service Bus side (where the SB proxy service resides), configure a SAML Identity Assertion provider and create a SAML asserting party. In the target URL field enter the service URI of the SB proxy service. Do not include the SB protocol or host/port information. For example, /<OSBProxyServiceURI>.

49.7 Configuring Transport-Level Security for WS Transport

Web service reliable messaging (WS-RM) functionality is available in Oracle Service Bus as the WS transport. Oracle Service Bus supports the specification submitted in February 2005. For more information about the specification, see Web Services Reliable Messaging Protocol (WS-ReliableMessaging) at http://schemas.xmlsoap.org/ws/2005/02/rm/.

The WS transport has both proxy service (inbound) and business service (outbound) components that are based on SOAP1.1- and SOAP1.2-based WSDLs, along with WS-RM policy. It supports both one-way and request-response patterns, but response is unreliable.

49.7.1 Reliable Web Services Messaging Defined

As described in "Overview of Web Service Reliable Messaging" in Oracle Fusion Middleware Programming Advanced Features of JAX-RPC Web Services for Oracle WebLogic Server, WS-RM is a framework in which an application running in one application server can reliably invoke a web service running on another application server, assuming that both servers implement the WS-ReliableMessaging specification. "Reliable" is defined as the ability to guarantee message delivery between the two web services. In particular, the specification describes an interoperable protocol in which a message sent from a source endpoint (or client web service) to a destination endpoint (or web service whose operations can be invoked reliably) is guaranteed either to be delivered, according to one or more delivery assurances, or to raise an error.

49.7.2 WS Transport Resources Visible in WLS Console

WS proxy services are visible from the Oracle WebLogic Server Administration Console, but attempts to assign policies from WLS are ignored.

Specifically, administrators can navigate to the Home > Summary of Security Realms > myrealm > Realm Roles pages in the Oracle WebLogic Server Administration Console and seemingly edit the security policy for the WS proxy service.

However, this policy will have no effect and it will not be evaluated at runtime.

The EAR application is auto-generated and deployed by Oracle Service Bus when you activate the session. This is one EAR file for each WS proxy service.

49.7.3 Use of WS-Policy Files for Web Service Reliable Messaging Configuration

You configure WS transport security through WS-Policy files, either from a WSDL or bound directly to the service.

Oracle Service Bus use WS-Policy files to enable a destination endpoint to describe and advertise its WS-RM capabilities and requirements. The WS-Policy specification provides a general purpose model and syntax to describe and communicate the policies of a web service.

These WS-Policy files are XML files that describe features such as the version of the supported WS-ReliableMessaging specification, the source endpoint's retransmission interval, the destination endpoint's acknowledgment interval, and so on.

WS-Policy with RM assertions and WSSP transport-level security assertions are supported for the WS transport only.

49.7.3.1 Preconfigured WS-RM Policy Files

Oracle Service Bus includes two simple WS-RM WS-Policy files that you can specify if you do not want to create your own WS-Policy files:

  • DefaultReliability.xml – Specifies typical values for the reliable messaging policy assertions, such as inactivity timeout of 10 minutes, acknowledgement interval of 200 milliseconds, and base re-transmission interval of 3 seconds.

  • LongRunningReliability.xml – Similar to the default reliable messaging WS-Policy file, except that it specifies a much longer activity timeout interval (24 hours.)

You cannot change these pre-packaged files. If their values do not suit your needs you must create your own WS-Policy file.

For example, the complete LongRunningReliability.xml file (as extracted from weblogic.jar) is shown in Example 49-1:

Example 49-1 LongRunningReliability.xml File

<?xml version="1.0"?>
<wsp:Policy
   xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"
   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
   xmlns:beapolicy="http://www.bea.com/wsrm/policy"
  >
  <wsrm:RMAssertion >
    <wsrm:InactivityTimeout
        Milliseconds="86400000" />
    <wsrm:BaseRetransmissionInterval
        Milliseconds="3000" />
    <wsrm:ExponentialBackoff />    
    <wsrm:AcknowledgementInterval
        Milliseconds="200" />
    <beapolicy:Expires Expires="P1M" optional="true"/>
  </wsrm:RMAssertion>
</wsp:Policy>

49.7.4 RM WS-Policy Required Prior to Activation

A proxy or business service that uses the WS transport must have a WS-Policy with RM assertions, either from a WSDL or bound directly to the service. Services that use any other transport must not have a WS-Policy with RM assertions.

You can bind RM assertions only at the service level and not at the operation or request/response levels.

49.7.5 Async Responses

WS-RM supports two messaging patterns: one way, and request/response. The WS transport supports both patterns, but does not support reliable response. That is, the response is not sent reliably but the request is always reliable.

Async responses from a proxy service using the WS transport to an RM client connect to the AcksTo or ReplyTo endpoint references specified by the RM client. The RM client is free to use an HTTP or HTTPS URL. When using HTTPS, the RM client is free to request a client certificate during the SSL handshake. The WS transport will use the SSL key-pair of the service key provider upon request.

49.7.6 Proxy Service Authentication

The WS transport supports the following HTTPS security modes via WS-Policy files:

  • HTTPS – no client authentication

  • HTTPS with BASIC authentication

  • HTTPS with client-certificate authentication (2-way SSL)

Table 49-0 shows the preconfigured security policies that implement these modes and indicates when you might use them.

Table 49-1 WS Transport Authentication Matrix

HTTPS Required Authentication Required Preconfigured Transport Security Policy

Yes

None

Wssp1.2-Https.xml

Yes

BASIC

Wssp1.2-HttpsBasic.xml

Yes

Client-certificate

Wssp1.2-HttpsClientCert.xml


WS proxy services support both basic and client-certificate (2-way SSL) authentication, as determined by the WSSP 1.2 transport-level security assertions in the WS-Policy.

Consider the example of the HTTPS token and the Basic256 algorithm as extracted from the packaged Wssp1.2-Https.xml policy, as shown in Example 49-2.

When basic authentication is specified in the WS-policy, all HTTPS requests (including RM protocol messages to the WS proxy service) must have a valid username and password.

Example 49-2 Wssp1.2-Https.xml File (Partial)

:
<sp:TransportBinding>
    <wsp:Policy >
      <sp:TransportToken>
        <wsp:Policy>
          <sp:HttpsToken />
        </wsp:Policy>
      </sp:TransportToken>
      <sp:AlgorithmSuite>
        <wsp:Policy>
          <sp:Basic256/>
        </wsp:Policy>
      </sp:AlgorithmSuite>
      <sp:Layout>
        <wsp:Policy>
          <sp:Lax/>
        </wsp:Policy>
      </sp:Layout>
      <sp:IncludeTimestamp/>
    </wsp:Policy>
  </sp:TransportBinding>
</wsp:Policy>

Proxy service authentication is supported as follows:

  • Outbound client-certificate authentication using the SSL key-pair assigned to the service key provider configured for the proxy service.

    If you plan to create a service key provider (which passes key-certificate pairs in outbound requests), use the Oracle WebLogic Server Administration Console to configure a PKI credential mapping provider. In any Oracle WebLogic Server domain that hosts Oracle Service Bus, you can configure at most one PKI credential mapping provider.

  • Username/password identity propagation through a WS proxy service (with basic authentication) to any other outbound transport, or outbound WSS username token.

    If a business service requires user name and password tokens, you can configure the business service's service account to pass through the user credentials from the original client request. See Section 2.1.15, "Creating Service Account Resources."

  • Credential mapping between WS proxy service (with basic or 2-way SSL authentication) and any other transport.

  • Sending (non-reliable) asynchronous responses from a WS proxy service to an RM client via HTTP or HTTPS. The default protocol used by proxy and business services is HTTP.

    Asynchronous responses from a WS proxy service to an RM client connect to the AcksTo or ReplyTo endpoint references specified by the RM client. The RM client can use either HTTP or HTTPS URL. If the RM client uses HTTPS, the RM client can request a client certificate during the SSL handshake. The WS transport uses the SSL key-pair of the service key provider upon request.

49.7.7 Preserving Security Configuration on Import

If the Preserve Security and Policy Configuration flag is set, the WS transport provider preserves the following security configuration: The reference to the service account (WS business services only)

49.7.8 Configuring Inbound and Outbound WS Transport-Level Security

You configure WS transport security through WS-Policy, either from a WSDL or bound directly to the service.

49.8 Configuring Transport-Level Security for WebSphere Message Queue Transport

Oracle Service Bus provides support for a native Message Queue (MQ) transport that can send messages to and from WebSphere MQ. In this context, the MQ transport is a client that connects to an MQ Server using MQ libraries.

You configure the security-related properties for the transport when you create an MQ Connection resource. These properties are then used by the MQ proxy or business service.

Note:

Make sure that you add the MQ client libraries to your environment, as described in Section 33.8.1, "Adding MQ Client Libraries to Your Environment."

The MQ Connection resource has two modes:

binding mode – You use the binding mode to connect to the MQ Queue Manager located on the same machine as Oracle Service Bus. In this mode, the service calls directly into the existing queue manager API rather than communicating over the network. This mode provides a fast path to connect to local queue managers.

TCP mode – You use the tcp mode when the MQ Queue Manager is not available on the same machine as Oracle Service Bus.

49.8.1 Configuring Inbound MQ Transport-Level Security: Main Steps

To configure inbound transport-level security for a proxy service:

  1. Before you create a proxy service that uses the MQ transport, create an MQ Connection resource for the transport to use. Choose from the following security configuration settings:

    • SSL Required. Select the check box to use HTTPS for sending messages. Only server-side SSL (server authenticates to client) is supported when the 2-way SSL Required option is not selected.

    • Cipher Suite. This option is available only when the SSL Required check box is selected. Select the Cipher Suite algorithm to be used by SSL.

      A cipher suite is an SSL encryption method that includes the key exchange algorithm, the symmetric encryption algorithm, and the secure hash algorithm. A cipher suite is used to protect the integrity of a communication.

      The Cipher Suite algorithm is used to encrypt and decrypt message communications between the WebSphere MQ server and the MQ Transport.

    • 2-way SSL Required. This option is available only when the SSL Required check box is selected. Select the check box to force the use of both client-side and server-side SSL authentication.

    • Reference to the Service Key Provider. If you select 2-way SSL Required, you must provide a reference to the service key provider for obtaining the appropriate key manager for client-side SSL.

      Enter the path (project/folder) and name of a service key provider, or click Browse to select one from the Select Service Key Provider page.

    • Reference to the Static Service Account. Required for user name and password authentication. Enter the path (project/folder) and name of a static service account, or click Browse to select a service account.

  2. When you create a proxy service, on the Transport Configuration page select mq.

49.8.2 Configuring Outbound MQ Transport-Level Security: Main Steps

To configure outbound transport-level security for a business service:

  1. Before you create a proxy service that uses the MQ transport, create a MQ Connection resource for the transport to use. Choose from the following security configuration settings:

    • SSL Required. Select the check box to use HTTPS for sending messages. Only server-side SSL (server authenticates to client) is supported when the 2-way SSL Required option is not selected.

    • Cipher Suite. This option is available only when the SSL Required check box is selected. Select the Cipher Suite algorithm to be used by SSL.

      A cipher suite is an SSL encryption method that includes the key exchange algorithm, the symmetric encryption algorithm, and the secure hash algorithm. A cipher suite is used to protect the integrity of a communication.

      The Cipher Suite algorithm is used to encrypt and decrypt message communications between the WebSphere MQ server and the MQ Transport.

    • 2-way SSL Required. This option is available only when the SSL Required check box is selected. Select the check box to force the use of both client-side and server-side SSL authentication.

    • Reference to the Service Key Provider. If you select 2-way SSL Required, you must provide a reference to the service key provider for obtaining the appropriate key manager for client-side SSL.

      Enter the path (project/folder) and name of a service key provider, or click Browse to select one from the Select Service Key Provider page.

    • Reference to the Static Service Account. Required for user name and password authentication. Enter the path (project/folder) and name of a static service account, or click Browse to select a service account.

  2. When you create a business service, on the Transport Configuration page select mq.

49.9 Transport-Level Security Elements in the Message Context

If you configure a proxy service to authenticate clients, then you can access the client's identity and the security groups to which the client belongs from the proxy service's pipeline. The identity and group information is located in the message context at

$inbound/ctx:security/ctx:transportClient/ctx:username

and

$inbound/ctx:security/ctx:transportClient/ctx:principals/ctx:group

(the message context contains one ctx:group element for each group the user belongs to)

If a proxy service does not authenticate clients, then the value of $inbound/ctx:security/ctx:transportClient/ctx:username is <anonymous> and there will not be any ctx:group elements.

For more information, see "Inbound and Outbound Variables" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus and Section 2.4, "Working with Proxy Service Message Flows."