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.
Message-level security is categorized as follows:
You can think of this as proxy service security.
The following sections describe configuring message-level security for a proxy service or a business service:
Note: | The implementation of message-level security includes proxy services that have been configured with message-level custom authentication (either custom token or username/password). The message-level security mechanisms described in this section work alone or in concert with the message-level custom authentication mechanism, which is described in Configuring Custom Authentication. See Combining WS-Security with Custom Username/Password and Tokens for information about using both types of security. |
AquaLogic Service Bus supports message-level security for SOAP messages that are sent over the HTTP (including 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 proxy service authentication and authorization.
To express the message-level security requirements for a proxy service or business service that is a Web service, you use the Web Services Policy (WS-Policy) framework. The Web Services Policy (WS-Policy) framework is described in Configuring Message-Level Security for Web Services.
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-soap-message-security-1.0.pdf
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, the following actions occur:
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 from authorized clients.
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:
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.service name
entry. Click Add to search for and select your policies.operation name
entry. Click Add to search for and select your policies.To create a pass-through proxy service:
See Configuring Business Service Message-Level Security: Main Steps.
service name
entry. Click Add to search for and select your policies.operation name
entry. Click Add to search for and select your policies.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.
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.
service name
entry. Click Add to search for and select your policies. operation name
entry. Click Add to search for and select your policies.See Creating an Active Intermediary Proxy Service: Main Steps.
The following sections provide examples of custom WS-Policy statements written under the WS-Policy specification using the proprietary BEA schema for security policy:
If you need to specify that particular parts of the body of a SOAP message are encrypted or digitally signed, rather than the entire body, you must create a custom WS-Policy file.
Listing 7-1 is an abstract WS-Policy statement that does the following:
This policy cannot be used with a business service because it is abstract: its KeyInfo
element does not contain the certificate used for encryption. Instead, when you activate a proxy service that uses this WS-Policy statement, AquaLogic Service Bus binds to the WS-Policy statement the encryption certificate from the service key provider that you associate with the proxy service. See
Service Key Providers in Using the AquaLogic Service Bus Console.
Also in Listing 7-1:
KeyWrappingAlgorithm
element specifies that the client must use the RSA 1.5 algorithm to wrap symmetric keys.EncryptionAlgorithm
specifies that the client must use the Triple DES (Data Encryption Standard) algorithm perform encrypt the security header and message body. <wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd"
xmlns:m="http://example.org"
wsu:Id="encrypt-custom-body-element-and-username-token">
<!-- Require messages to provide a user name and password token
for authentication -->
<wssp:Identity>
<wssp:SupportedTokens>
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-username-token-profile-1.0#UsernameToken">
<wssp:UsePassword Type="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-username-token-profile-1.0#PasswordText"/>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Identity>
<wssp:Confidentiality>
<wssp:KeyWrappingAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<!-- Require the user name and password in the security header
to be encrypted -->
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(wsse:UsernameToken)
</wssp:MessageParts>
</wssp:Target>
<!-- Require the /definitions/message/CreditCardNumber element to
be encrypted -->
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts>
wsp:GetBody(.)/m:CreditCardNumber
</wssp:MessageParts>
</wssp:Target>
<!-- This is an abstract policy because the KeyInfo element is
empty. The KeyInfo data is bound to the policy at runtime -->
<wssp:KeyInfo/>
</wssp:Confidentiality>
</wsp:Policy>
If you want messages to a business service to be encrypted, you must create a custom WS-Policy. The policy must be concrete (it must contain the encryption certificate instead of using a certificate from a service key provider) and it must be located directly in a WSDL document instead of being included by reference.
Typically, you would require messages to a business service to be encrypted if the proxy service that sends messages to the business service is a pass-through proxy service. That is, the proxy service that receives messages from a client does not process the SOAP message. Instead, the proxy service routes the message to the business service, and the business service takes on the responsibility of Web Services Security. See Message-Level Access Control Policies for Proxy Services.
Listing 7-2 is a WSDL document that contains a concrete policy. Note the following about this example:
KeyInfo
element specifies the type of token that a client must provide to is the parent element that is used to describe and embed the encryption certificate. The BinarySecurityToken
element contains the base-64 encoded encryption certificate (the value is truncated in the example). If your certificate is in PEM format, the content of the PEM file (without the PEM prefix and suffix) is the base-64 encoded representation of the certificate. If your encryption certificate is stored in a JDK keystore, you can easily export it to a PEM file.<definitions name="WssServiceDefinitions"
targetNamespace="http://com.bea.alsb/tests/wss"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
...>
<wsp:UsingPolicy xmlns:n1="http://schemas.xmlsoap.org/wsdl/"
n1:Required="true"/>
<!-- The policy provides a unique ID -->
<wsp:Policy wsu:Id="myEncrypt.xml">
<wssp:Confidentiality
xmlns:wssp="http://www.bea.com/wls90/security/policy">
<wssp:KeyWrappingAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<!-- Require the user name and password in the security header
to be encrypted -->
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<!-- Embed the token type and encryption certificate -->
<wssp:KeyInfo>
<wssp:SecurityToken
TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-x509-token-profile-1.0#X509v3"/>
<wssp:SecurityTokenReference>
<wssp:Embedded>
<wsse:BinarySecurityToken
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-x509-token-profile-1.0#X509v3"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-wssecurity-secext-1.0.xsd">
MIICfjCCAeegAwIBAgIQV/PDyj3...
</wsse:BinarySecurityToken>
</wssp:Embedded>
</wssp:SecurityTokenReference>
</wssp:KeyInfo>
</wssp:Confidentiality>
</wsp:Policy>
<binding name="WssServiceSoapBinding" type="tns:WssService">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getPurchaseOrder">
<soap:operation soapAction="" style="document"/>
<input>
<soap:body parts="parameters" use="literal"/>
<!-- Use a URI fragment to refer to the unique policy ID -->
<wsp:Policy>
<wsp:PolicyReference URI="#myEncrypt.xml"/>
</wsp:Policy>
</input>
<output>
<soap:body parts="parameters" use="literal"/>
</output>
</operation>
</binding>
...
</definitions>
Listing 7-3 is an abstract WS-Policy statement that encrypts a custom header named CreditCardNumber
.
If you need to specify that particular parts of the body of a SOAP message are encrypted or digitally signed, rather than the entire body, you must create a custom WS-Policy file.
This policy cannot be used with a business service because it is abstract: its KeyInfo
element does not contain the certificate used for encryption. Instead, when you activate a proxy service that uses this WS-Policy statement, AquaLogic Service Bus binds to the WS-Policy statement the encryption certificate from the service key provider that you associate with the proxy service. See
Service Key Providers in Using the AquaLogic Service Bus Console.
Also of note in Listing 7-3:
KeyWrappingAlgorithm
element specifies that the client must use the RSA 1.5 algorithm to wrap symmetric keys.EncryptionAlgorithm
specifies that the client must use the Triple DES (Data Encryption Standard) algorithm perform encrypt the security header. <wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd"
wsu:Id="dig-sig-for-get-header">
<wssp:Confidentiality>
<wssp:KeyWrappingAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<!-- Require the custom CreditCardNumber header to be encrypted -->
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
wsp:GetHeader(.)/n:CreditCardNumber
</wssp:MessageParts>
</wssp:Target>
<wssp:KeyInfo/>
</wssp:Confidentiality>
</wsp:Policy>
Listing 7-4 is a WS-Policy statement that requires a digital signature to access the following in the SOAP message:
header1
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd"
wsu:Id="sign-custom-header-policy">
<wssp:Integrity>
<wssp:SignatureAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<wssp:CanonicalizationAlgorithm
URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<!-- Require the custom header header1 to be signed -->
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd"
xmlns:n="http://example.org">
wsp:GetHeader(.)/n:header1
</wssp:MessageParts>
</wssp:Target>
<!-- Require the system headers to be signed -->
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SystemHeaders()
</wssp:MessageParts>
</wssp:Target>
<!-- Require the Timestamp header to be signed -->
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(wsu:Timestamp)
</wssp:MessageParts>
</wssp:Target>
<!-- Require the message body to be signed -->
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
</wssp:Integrity>
<wssp:MessageAge/>
</wsp:Policy>
Listing 7-5 is a WS-Policy statement that requires the SAML asserter to use the holder-of-key method to sign the message body. The purpose of a SAML token with "holder-of-key" subject confirmation is to allow the subject to use an X.509 certificate that may not be trusted by the receiver to protect the integrity of the request messages.
For more information about the two SAML confirmation methods (sender-vouches or holder-of-key), see SAML Token Profile Support in WebLogic Web Services.
The WebLogic Server Security Policy Assertion Reference describes the policy elements in detail.
Note the following about this example:
Integrity
specifies that part or all of the SOAP message must be digitally signed, as well as the algorithms and keys that are used to sign the SOAP message. SignatureAlgorithm
specifies the cryptographic algorithm used to compute the digital signature.CanonicalizationAlgorithm
specifies the algorithm used to canonicalize (use in simple or standard form) the SOAP message elements that are digitally signed. You can specify only http://www.w3.org/2001/10/xml-exc-cl4n#.
DigestAlgorithm
specifies the digest algorithm that is used when digitally signing the specified parts of a SOAP message. You can specify only http://www.w3.org/2000/09/xmldsig#sha1
.MessageParts
specifies the parts of the SOAP message that should be signed, in this case the body. Dialect
identifies the dialect used to identify the parts of the SOAP message that should be signed. SupportedTokens
specifies the list of supported security tokens that can be used for digital signatures. SecurityToken
specifies the security token that is supported for digital signatures.
IncludeInMessage
specifies whether to include the token in the SOAP message. Valid values are true or false. The default value of this attribute is true when used in the <Integrity> assertion.TokenType
specifies the type of security token, in this case http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID
to specify a SAML token. Claims
specifies additional metadata information that is associated with a particular type of security token. For SAML tokens, you must define a <ConfirmationMethod> child element to specify the type of SAML confirmation (sender-vouches or holder-of-key). ConfirmationMethod
specifies the type of confirmation method, either sender-vouches or holder-of-key, that is used when using SAML tokens for identity. <ConfirmationMethod>
assertion within an <Integrity>
assertion. The reason you put the SAML token in the <Integrity>
assertion for this confirmation method is that the Web Service runtime must prove the integrity of the message, which is not required by sender-vouches. <wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
wsu:Id="saml-holder-of-key-signed">
<wssp:Integrity>
<wssp:SignatureAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<wssp:CanonicalizationAlgorithm
URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:SupportedTokens>
<wssp:SecurityToken IncludeInMessage="true"
</wssp:Claims>
TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-
token-profile-1.0#SAMLAssertionID">
<wssp:Claims>
<wssp:ConfirmationMethod>holder-of-key</wssp:ConfirmationMethod>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Integrity>
</wsp:Policy>
Listing 7-6 is a WS-Policy statement that requires the SAML asserter to use the sender-vouches method to sign the message body and headers.
In sender-vouches the asserting party (different from the subject) vouches for the verification of the subject. The receiver must have a trust relationship with the asserting party.
For more information about the two SAML confirmation methods (sender-vouches or holder-of-key), see SAML Token Profile Support in WebLogic Web Services.
The WebLogic Server Security Policy Assertion Reference describes the policy elements in detail.
Note the following about this example:
Identity
specifies the type of security tokens. SupportedTokens
specifies the list of supported security tokens that can be used for digital signatures. SecurityToken
specifies the security token that is supported for digital signatures.
IncludeInMessage
is not specified because the value of this attribute is always true when used in the <Identity>
assertion, even if you explicitly set it to false. TokenType
specifies the type of security token, in this case http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID
to specify a SAML token. Claims
specifies additional metadata information that is associated with a particular type of security token. For SAML tokens, you must define a <ConfirmationMethod> child element to specify the type of SAML confirmation (sender-vouches or holder-of-key). ConfirmationMethod
specifies the type of confirmation method, either sender-vouches or holder-of-key, that is used when using SAML tokens for identity. Integrity
specifies that part or all of the SOAP message must be digitally signed (in this example both the body and security headers), as well as the algorithms and keys that are used to sign the SOAP message. SignatureAlgorithm
specifies the cryptographic algorithm used to compute the digital signature.CanonicalizationAlgorithm
specifies the algorithm used to canonicalize (use in simple or standard form) the SOAP message elements that are digitally signed. You can specify only http://www.w3.org/2001/10/xml-exc-cl4n#.
Target
encapsulates information about which targets of a SOAP message are to be encrypted or signed, depending on the parent element. The child elements also depend on the parent element: DigestAlgorithm
specifies the digest algorithm that is used when digitally signing the specified parts of a SOAP message. You can specify only http://www.w3.org/2000/09/xmldsig#sha1
.MessageParts
specifies the parts of the SOAP message that should be signed, in this case the body and security header.Dialect
identifies the dialect used to identify the parts of the SOAP message that should be signed. Confidentiality
specifies that part or all of the SOAP message must be encrypted, as well as the algorithms and keys that are used to encrypt the SOAP message. The example requires that the body and security headers must be encrypted using triple-DES. <wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
wsu:Id="samlPolicy-sender-vouches-signed-encrypted">
<wssp:Identity>
</wssp:ConfirmationMethod>
<wssp:SupportedTokens>
<wssp:SecurityToken
TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-
saml-token-profile-1.0#SAMLAssertionID">
<wssp:Claims>
<wssp:ConfirmationMethod>
sender-vouches
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Identity>
<wssp:Integrity>
<wssp:SignatureAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<wssp:CanonicalizationAlgorithm
URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
</wssp:MessageParts>
<wssp:DigestAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts
</wssp:Target>
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(Assertion)
</wssp:MessageParts>
</wssp:Integrity>
<wssp:Confidentiality>
<wssp:KeyWrappingAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts
</wssp:MessageParts>
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(Assertion)
</wssp:Target>
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts
</wssp:MessageParts>
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:Target>
<wssp:KeyInfo/>
</wssp:Confidentiality>
</wsp:Policy>
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.