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 AquaLogic 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 secures the communication between clients and AquaLogic Service Bus proxy services. Outbound transport security secures all three techniques of sending outbound requests from AquaLogic Service Bus proxy services: route actions, publish actions, and callout actions.
The following sections describe configuring transport-level security:
Note: | Transport-level security secures only the connection itself. Even if you use the HTTPS or JMS protocols to encrypt the communication, if there is an intermediary between a Web services client and an AquaLogic Service Bus proxy service, such as a router, message queue or another proxy service, the intermediary gets the SOAP message in plain text. When the intermediary sends the message to the second receiver, the second receiver does not know who the original sender was. To prevent unintended intermediaries from viewing or modifying SOAP or JMS messages, configure message-level security in addition to transport-level security. See Configuring Message-Level Security for Web Services. |
Note: | In previous releases of ALSB, HTTPS was managed via the HTTPS transport. In this release of ALSB, HTTPS has been merged in to the HTTP transport. |
Note: | This section has been updated to reflect the new configuration model. |
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 WebLogic Server, see Configuring the WebLogic Security Framework: Main Steps.
The following sections describe configuring transport-level security for the HTTPS protocol:
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:
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 AquaLogic Service Bus sends its certificate to the client. In other words, the client authenticates AquaLogic Service Bus.
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 client’s credentials match a user account that you have created.
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 AquaLogic Service Bus sends its X.509 certificate to the client. Then, the client sends its certificate to AquaLogic Service Bus and AquaLogic 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 AquaLogic Service Bus Console.
For more information about SSL and identity assertion providers, see Security Fundamentals in Understanding WebLogic Security.
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 Configuring Custom Authentication.
To configure inbound transport-level security for a proxy service:
Note: | You must first configure, or create and configure, a WebLogic Server Identity Assertion provider as described in 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 AquaLogic Service Bus Console. |
See Configuring the WebLogic Security Framework: 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:
If you configured the proxy service such that AquaLogic Service Bus does not authenticate clients, configure the enterprise system to authenticate clients by selecting an authentication level of one-way SSL, BASIC authentication.
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 AquaLogic Service Bus user. If you configured the proxy service so that AquaLogic Service Bus does not authenticate clients, create a service account that passes through the credentials. See Service Accounts in Using the AquaLogic Service Bus Console.
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, BEA 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:
To configure inbound transport-level security for a proxy service:
The steps for configuring transport-level custom credentials are described in “Adding a Proxy Service” under Proxy Services in Using the AquaLogic Service Bus Console. Custom authentication concepts are described in 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, a WebLogic Server Identity Assertion provider as described in Configuring Identity Assertion Providers for Custom Tokens. |
Note: | If you want AquaLogic Service Bus to authenticate clients (Basic or Custom Authentication) you must create user accounts for the clients. See Configuring Administrative 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:
See “Adding a Business Service” under Business Services in Using the AquaLogic Service Bus Console.
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 AquaLogic Service Bus user. If you configured the proxy service so that AquaLogic Service Bus does not authenticate clients, create a service account that passes through the credentials. See Service Accounts in Using the AquaLogic Service Bus Console.
While transport-level security for JMS does not provide end-to-end security for JMS messaging, it does provide the following:
AquaLogic Service Bus can communicate with local JMS servers or foreign JMS servers. The connection to JMS servers can be secured using the T3S protocol (T3 over SSL). T3 and T3S are proprietary BEA protocols.
Note: | JMS administrators use the WebLogic Server Administration Console to create access control policies that restrict access to WebLogic JMS servers and destinations in the JNDI tree. For more information, see Configuring JMS System Resources in Configuring and Managing WebLogic JMS and Securing WebLogic Resources. |
Note: | If a JMS administrator configures or changes an access control policy for a JMS destination, WebLogic Server can take up to 60 seconds to recognize the changes. |
Note: | By default, WebLogic Server JMS checks the policy for each JMS destination every 60 seconds. To change this behavior, modify the WebLogic Server startup command so that it sets the following system property to the frequency (in seconds) that you want WebLogic Server JMS to check access control policies:weblogic.jms.securityCheckInterval A value of 0 (zero) for this property ensures that an authorization check is performed for every send , receive , and getEnumeration action on a JMS resource. |
The following sections describe configuring JMS transport-level security:
To configure inbound JMS transport-level security:
AquaLogic Service Bus configures the JMS proxy service to use the T3S protocol.
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 AquaLogic Service Bus user. See Service Accounts in Using the AquaLogic Service Bus Console.
To configure outbound JMS transport-level security:
AquaLogic Service Bus configures the JMS proxy service to use the T3S protocol.
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 AquaLogic Service Bus user. See Service Accounts in Using the AquaLogic Service Bus Console.
You can use the same service account for both the JMS server and the JNDI tree if both objects require the same credentials.
Tip: | Use the same service account for both the JMS Service Account and JNDI Service Account. That is, leave both fields blank, or use the same service account in both fields. This is the recommended best practice. |
As described in Using the SFTP Transport, this release of ALSB supports the SFTP transport for inbound and outbound transport-level security. The SFTP transport uses Secure Shell (SSH) version 2 to transfer files.
The SFTP authentication is two– way: both the SFTP server and SFTP client (ALSB service) authenticate each other, via different mechanisms:
known_hosts
file to authenticate the SFTP server. The known_hosts
file on the ALSB 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 ALSB 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 ALSB service using the information present in this file. This ensures that the ALSB service is connecting to a known server.
For example, in case of Username Password authentication, the SFTP Client (ALSB Service) authenticates the SFTP server against the SFTP server’s public key in the known_hosts file.
The SFTP server authenticates the client (ALSB service) with the username and password from the service account.
No matter which authentication method you choose in the Transport Configuration page, a known_hosts
file on the ALSB 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 ALSB 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 ALSB 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.
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.”
getafix,172.22.52.130 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAtR+M3Z9HFxnKZTx66fZdnQqAHQcF1vQe1+EjJ/HWYtgAnqsn0hMJzqWMatb/u9yFwUpZBirjm3g2I9Qd8VocmeHwoGPhDGfQ5LQ/PPo3esE+CGwdnCOyRCktNHeuKxo4kiCCJ/bph5dRpghCQIvsQvRE3sks+XwQ7Wuswz8pv58=
Multiple entries are supported, one entry per line.
known_hosts
file to the
<BEA_HOME>
\user_projects\domains\
alsb_domain
\alsb\transports\sftp
directory. The directories \transports\sftp
are not created automatically. You must create them.
The following general principles apply to the SFTP authentication process for both a proxy service and business service.
known_hosts
file.The SFTP authentication process is as follows:
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 ALSB 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 ALSB system.
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.
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.
For Host Based and Public Key authentication, the SFTP server uses the host name and public key of the business service to authenticate the ALSB system. For Username Password authentication, the SFTP server uses the username and password (from the service account) to authenticate the ALSB system.
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.
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.
To configure inbound transport-level security for a proxy service:
known_hosts
file, as described in Use of the known_hosts File, on the ALSB proxy service system.
known_hosts
keeps the information of the remote SFTP servers to which the ALSB 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.
sftp://hostname:port/directory
format, where: The authentication choices are summarized here. See Using the SFTP Transport for complete information.
The SFTP Server authenticates the proxy service with the public key of the proxy service.
Note: | The ALSB 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:
/etc/ssh/shosts.equiv
file and add the host name or IP address of the machine on which ALSB domain is running. /etc/ssh/ssh_known_hosts
file and add the host name or IP address of the machine on which ALSB domain is running, followed by space and the public key. The username is used to determine which directory on the SFTP server to poll.
The SFTP Server authenticates the proxy service with the public key.
Note: | The ALSB 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.
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.
To configure outbound transport-level security for a business service:
known_hosts
file, as described in Use of the known_hosts File, on the ALSB business service system.
known_hosts
keeps the information of the remote SFTP servers to which the ALSB 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.
sftp://hostname:port/directory
format, where: The authentication choices are summarized here. See Using the SFTP Transport for complete information.
The SFTP Server authenticates the business service with the public key of the business service.
Note: | The ALSB 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:
/etc/ssh/shosts.equiv
file and add the host name or IP address of the machine on which ALSB domain is running. /etc/ssh/ssh_known_hosts
file and add the host name or IP address of the machine on which ALSB domain is running, followed by space and the public key. The username is used to determine the upload directory on the SFTP server.
The SFTP Server authenticates the business service with the public key.
Note: | The ALSB 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.
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.
The following security attributes are preserved when Preserve Security and Policy Configuration Check Box is turned on during import:
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.
The following sections describe the security measures that are available for communication over the email, FTP, and file protocols:
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 in the AquaLogic Service Bus Console. The service will use the username and password to authenticate to the SMTP server.
To secure the FTP transport, in the AquaLogic Service Bus Console, 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 “Adding a Business Service” in Business Services in the Using the AquaLogic Service Bus Console.
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 Configuring Transport-Level Security for SFTP Transport, is the preferred mechanism to secure FTP.
The Service Bus (SB) transport allows client ALSB servers to invoke an ALSB proxy service synchronously via RMI. RMI is the only mechanism by which client ALSB servers can access the SB transport. In this release of ALSB 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 ALSB server. Specifically, the JNDI provider points to the ALSB 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 WebLogic Server. See Configuring the 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. |
Caution: | The ALSB server administrator must close all unsecured protocols on the server (t3, http, and so forth) to strictly enforce secured-client connections. |
If you are using SAML-based authentication with the SB transport, be sure to follow these configuration requirements:
http://openuri.org/<
ALSBProxyServiceURI
>, where ALSBProxyServiceURI
is the service URI of the SB proxy service./<
ALSBProxyServiceURI
>
.
Web service reliable messaging (WS-RM) functionality is available in ALSB as the WS transport. ALSB supports the specification submitted in February 2005. For more information about the specification, see Web Services Reliable Messaging Protocol (WS-ReliableMessaging).
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.
As described in Overview of Web Service Reliable Messaging, 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.
WS proxy services are visible from the WLS 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 WLS console and seemingly edit the security policy for the WS proxy service, as shown in Figure 4-1.
However, this policy will have no effect and it will not be evaluated at runtime.
The EAR application is auto-generated and deployed by ALSB when you activate the session. This is one EAR file for each WS proxy service.
You configure WS transport security through WS-Policy files, either from a WSDL or bound directly to the service.
ALSB 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 1.2 transport-level security assertions are supported for the WS transport only.
Note: | WSSP 1.2 message-level security assertions are not supported for any transport. 9.x BEA proprietary security assertions are not supported for the WS transport. |
ALSB 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 retransmisstion 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 Listing 4-1:
<?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>
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.
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.
The WS transport supports the following HTTPS security modes via WS-Policy files:
Table 4-1 shows the preconfigured security policies that implement these modes and indicates when you might use them.
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 Listing 4-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.
:
<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:
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 Service Accounts in Using the AquaLogic Service Bus Console.
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.
If the Preserve Security and Policy Configuration
flag is set, the WS transport provider preserves the following security configuration:
You configure WS transport security through WS-Policy, either from a WSDL or bound directly to the service.
ALSB 3.0 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 Adding MQ Client Libraries to Your Environment. |
The MQ Connection resource has two modes:
To configure inbound transport-level security for a proxy service:
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.
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.
mq
. To configure outbound transport-level security for a business service:
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.
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.
mq
.
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 Message Context in the AquaLogic Service Bus User Guide and “Message Flow” in Proxy Services in the Using the AquaLogic Service Bus Console.