![]() ![]() ![]() ![]() ![]() ![]() |
Message-level security applies security checks to a SOAP message after a Web services client establishes a connection with an AquaLogic Service Bus proxy service or business service and before the proxy service or business service processes the message. To provide message-level security, AquaLogic Service Bus implements the features that are defined in the OASIS standard for Web Services Security (WS-Security).
Inbound message-level security applies to messages between clients and AquaLogic Service Bus proxy services. It applies security to both the request from the client and the response message back to the client. Outbound message-level security applies to messages between AquaLogic Service Bus proxy services and SOAP-HTTP or SOAP-JMS business services. It applies security to both the request and the response.
The following sections describe configuring message-level security for a proxy service or a business service:
AquaLogic Service Bus supports message-level security for SOAP messages that are sent over the HTTP, HTTPS, or JMS protocols. Usually you use message-level security in addition to the transport-level security that these protocols offer. You can require Web services clients to provide credentials at the transport level, the message level, or both levels. If you require clients to provide credentials at both levels, AquaLogic Service Bus uses the message-level credentials for inbound authentication and authorization.
With message-level security, a proxy service or business service specifies which of its operations are secured and which of the following security measures a Web services client must apply to its SOAP messages, which contain requests to invoke operations:
Requires a client to present an identity that can be compared with user accounts in the domain's authentication provider.
Establishes the identity of the client that is requesting to invoke an operation and guarantees that no intermediary has altered the request. Also guarantees that the return values of the operation are returned to the client without being altered by an intermediary.
Encrypts the request and the return value in the response and guarantees that no intermediary has viewed the request or the response.
All of these security measures require a client to encode security tokens in its SOAP messages, and the proxy service or business service specifies which types of security tokens it requires to be encoded in the SOAP messages.
AquaLogic Service Bus supports the following WS-Security token profiles:
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf
To send a SOAP message to a proxy service that requires message-level security, a Web services client generates a SOAP header and adds the header to the SOAP message envelope. The header includes digital signatures, security tokens, and other constructs. When the proxy service processes the secured envelope, it decrypts the message, which removes the security header. The proxy service then verifies that the message conforms to its security requirements. For example, the proxy service confirms that the required message parts were signed and/or encrypted and that the required tokens are present with the required claims.
The entire process is repeated in reverse for the response from the proxy service to the client.
For more information about WS-Security (which is the OASIS standard that defines message-level security), see Web Services Security: SOAP Message Security 1.0 (WS-Security 2004) at the following URL:
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
While message integrity and message confidentiality guarantee that intermediaries do not view or modify messages, and while message authentication requires clients to prove that they are known users, they do nothing to specify which known users are allowed (authorized) to invoke proxy service operations.
To limit access to authorized users, you use the AquaLogic Service Bus Console to create message-level access control policies. These policies allow a proxy service to process only those SOAP messages that contain tokens that can be mapped to a specific list of authorized users.
You can configure a proxy service to support one of the following techniques for inbound message-level security:
The proxy service processes the header in the client's SOAP messages and enforces the message-level access control policy on the messages.
For example, a client encrypts and signs its SOAP message and sends it to a proxy service. The proxy service decrypts the message and verifies the digital signature, then routes the message. Before the proxy service sends the response back to the client, the proxy service signs and encrypts the message. The client then decrypts the message and verifies the proxy service's digital signature.
Instead of processing the header in the client's SOAP messages, the proxy service passes the message untouched to a business service. Although the proxy service does not process the secured sections of the SOAP message, it can route the message based on values in the header. When the business service receives the message, it processes the security header and acts on the request. Note that the business service must use the Web Services Policy (WS-Policy) framework to describe which of its operations are secured with message-level security. The business service sends its response to the proxy service, and the proxy service passes the response untouched to the client.
For example, the client encrypts and signs the message and sends it to the proxy service. The proxy service does not decrypt the message or verify the digital signature; it simply routes the message to the business service. The business service decrypts the messages and verifies the digital signature, and then processes the request. The response path is similar.
To create a proxy service to act as an active intermediary:
A WS-Policy statement is an XML statement that expresses a message-level security requirement (assertion). For example, one WS-Policy statement might contain an assertion that requires clients to supply a digital signature. AquaLogic Service Bus includes a set of WS-Policy statements that you can use.
If the AquaLogic Service Bus WS-Policy statements do not meet your security needs, you can write your own WS-Policy statements (custom WS-Policy statements) and import them into the AquaLogic Service Bus WS-Policy repository.
See Using Web Services Policy to Specify Inbound Message-Level Security.
See "Adding a WSDL" in WSDLs in the Using the AquaLogic Service Bus Console.
__SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN__
. See step 2 in Configuring the WebLogic Security Framework: Main Steps.See Proxy Services in Using the AquaLogic Service Bus Console.
To create a pass-through proxy service:
See Configuring Outbound Message-Level Security: Main Steps.
While you are creating the proxy service:
If you route to the business service based on the operation that the client's SOAP message is requesting to invoke, you must configure the routing so that it specifies an operation selection algorithm other than the SOAP body algorithm. Make sure the actions in the proxy service pipeline do not modify the WS-Security header or any parts of the SOAP envelope that are signed or encrypted. Changes to clear-text message parts covered by digital signatures almost always break the digital signature because the signature cannot be verified later.
See Proxy Services in Using the AquaLogic Service Bus Console.
Outbound message-level security applies to messages between AquaLogic Service Bus proxy services and SOAP-HTTP or SOAP-JMS business services. It applies security to both the request and the response.
To configure outbound message-level security for a business service that represents a SOAP-HTTP or SOAP-JMS Web service:
See "Adding a WSDL" in WSDLs in the Using the AquaLogic Service Bus Console.
The WSDL document must express message-level security requirements with one or more Web Services Policy (WS-Policy) statements. If the Web service requires digital encryption, you must create a custom WS-Policy statement that embeds the encryption certificate and this WS-Policy statement must be located in the Web service's WSDL document (it cannot be included by reference).
Caution: | Encrypted back-end response messages: If the response policy of the business service specifies encryption, the proxy service will send its encryption certificate to the business service on the request. The business service will encrypt its response using the proxy service's public key. The proxy service encryption credential must not be the same as the business service encryption credential. |
See Business Services in Using the AquaLogic Service Bus Console.
See Creating an Active Intermediary Proxy Service: Main Steps or Creating a Pass-Through Proxy Service: Main Steps.
Some infrequently used design patterns preempt a proxy service from automatically generating the outbound WS-Security SOAP envelope and instead use an XQuery expression to create the envelope. If you use this design pattern, to prevent a proxy service from automatically generating the outbound WS-Security SOAP envelope, you must create an action in the proxy service's message flow that sets the value of the ./ctx:security/ctx:doOutboundWss
element in the $outbound
message context variable to xs:boolean("false")
. You can create the action in either of the following places:
For information about the $outbound
message context variable, see
Message Context in AquaLogic Service Bus User Guide.
Under some circumstances, when you attempt to activate a session in which you have created or modified a proxy service with outbound message-level security disabled, the AquaLogic Service Bus Console reports validation errors (you cannot commit a session that contains errors). If your session validation reports errors because you have disabled outbound message-level security, modify the AquaLogic Service Bus startup command so that it sets the following system property to true
:com.bea.wli.sb.security.wss.LaxOutboundWssValidation
Then restart AquaLogic Service Bus. With this property set to true
, the AquaLogic Service Bus Console reports warnings instead of errors (you can commit a session that reports warning messages).
Future releases of AquaLogic Service Bus will provide an easier way to disable outbound message-level security.
![]() ![]() ![]() |