- SAP Managed Tags:
This blog describes how to configure Web Service Security (WSS) in the SOAP adapter. In the sender SOAP adapter, you can configure a Web Service Provider (WS Provider) with WSS on the WS-Security tab. You must select Via Manual Configuration in Channel in the WS-Security Configuration dropdown list. In the receiver SOAP adapter, you have the additional option of configuring WSS by using policies within the used WSDL. This is the most common use case. A WS Provider provides a WSDL, which can be used to configure the Web Service Consumer (WS Consumer).
If you configure WSS manually, there is a subset of possible WSS configurations. This option was introduced to enable WSS communication between Cloud Integration and the SOAP adapter of the on-premise solution SAP Process Orchestration (SAP PO). Since the on-premise SOAP adapter does not provide a WSDL to configure the WS-Consumer, the integration flow developer can use the manual configuration to enable interoperability.
For more information, see this blog.
If manual configuration is used in the Cloud Integration SOAP sender channel, a WSDL containing the WSS policies can be downloaded once the integration flow has been deployed. This WSDL can be used in a Cloud Integration SOAP receiver channel or a third party WS Consumer.
The current policy assertions are based on the WS Security Policy Specification 1.2.
The option to configure a WS Consumer based on policies in WSDL is offered within the receiver SOAP adapter. The examples in this blog are based on WS Security Policy Specification 1.2.
Cloud Integration supports the UsernameToken assertion and the signing and/or encryption of the message. Depending on the policies in the WSDL, the fields Credential Name, Public Key Alias for Signing and/or Public Key Alias for Encryption must be set.
Be aware, that in the case of a signed response message, the public certificate of the certificate, which was used by the WS Provider to sign the message must be uploaded to the keystore (system.jks) of your Cloud Integration cluster. This is required to verify the signature, even if the public certificate is included in the SOAP response message.
A WSDL can contain several policy elements, which can be assigned to the binding elements within the WSDL or to the input and output message of an operation.
In this case the policies are assigned to the input and output message of an operation.
It is also possible to assign the #my_Input_policy to the output message greetMeResponse. You should make yourself familiar with the structure of a WSDL.
The IncludeTimestamp policy adds a timestamp element into the SOAP envelope header section. You could add other policies such as SignBeforeEncrypting on the same level. Please check the WS Security Policy Specification 1.2.
If the WSDL contains a SignedParts element, you must set the value for the Public Key Alias for Signing. If the WSDL contains an EncryptedParts element, you must set the value for Public Key Alias for Encryption.
Using the policy assertions defined in my_Input_policy policy creates the SOAP message below. The value for Signature Algorithm within the channel configuration is SHA256/RSA.
Cloud Integration gives you the option to specify a user for the UsernameToken assertion. If you do not want the UsernameToken to be signed or encrypted, the WSDL policy should be SupportingTokens, which includes the UsernameToken assertion.
The policy HashPassword policy is an optional policy assertion. For details, please read the WSS specification.
If you want the UsernameToken to be signed, you must use the element SignedSupportingTokens instead of SupportingTokens. If the element SignedEncryptedSupportingTokens is used, the UsernameToken will be signed and encrypted.
If WSS is configured manually in the SOAP receiver channel, the UsernameToken is signed, if Sign Message is selected in the WS-Security Type field, and signed and encrypted if Sign and Encrypt Message is selected.
WSS via Manual Configuration in Channel
If you configure WSS manually, there is a subset of possible WSS configurations. This option was introduced to enable WSS communication between Cloud Integration and the SOAP adapter of the on-premise solution SAP Process Orchestration (SAP PO). Since the on-premise SOAP adapter does not provide a WSDL to configure the WS-Consumer, the integration flow developer can use the manual configuration to enable interoperability.
For more information, see this blog.
If manual configuration is used in the Cloud Integration SOAP sender channel, a WSDL containing the WSS policies can be downloaded once the integration flow has been deployed. This WSDL can be used in a Cloud Integration SOAP receiver channel or a third party WS Consumer.
The current policy assertions are based on the WS Security Policy Specification 1.2.
WSS Based on Policies in WSDL
The option to configure a WS Consumer based on policies in WSDL is offered within the receiver SOAP adapter. The examples in this blog are based on WS Security Policy Specification 1.2.
Cloud Integration supports the UsernameToken assertion and the signing and/or encryption of the message. Depending on the policies in the WSDL, the fields Credential Name, Public Key Alias for Signing and/or Public Key Alias for Encryption must be set.
Be aware, that in the case of a signed response message, the public certificate of the certificate, which was used by the WS Provider to sign the message must be uploaded to the keystore (system.jks) of your Cloud Integration cluster. This is required to verify the signature, even if the public certificate is included in the SOAP response message.
WSDL Example with Signing and Encryption Assertions
A WSDL can contain several policy elements, which can be assigned to the binding elements within the WSDL or to the input and output message of an operation.
<wsdl:definitions xmlns="http://schemas.xmlsoap.org/wsdl/" ....
<wsp:Policy wsu:Id="my_Input_policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsp="http://www.w3.org/ns/ws-policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:AsymmetricBinding
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssX509V3Token10 />
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
<wsp:Policy>
<sp:WssX509V3Token10 />
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:Layout>
<wsp:Policy>
<sp:Lax />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:OnlySignEntireHeadersAndBody />
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256Sha256Rsa15 />
</wsp:Policy>
</sp:AlgorithmSuite>
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:Wss10 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier />
<sp:MustSupportRefIssuerSerial />
</wsp:Policy>
</sp:Wss10>
<sp:SignedParts
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<sp:Body />
</sp:SignedParts>
<sp:EncryptedParts xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<sp:Body/>
</sp:EncryptedParts>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<wsp:Policy wsu:Id="my_Output_policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsp="http://www.w3.org/ns/ws-policy">
<wsp:ExactlyOne>
....In this case the policies are assigned to the input and output message of an operation.
<wsdl:binding name="SOAPBinding" type="tns:Greeter">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
<wsdl:operation name="greetMe">
<soap:operation soapAction="" style="document" />
<wsdl:input name="greetMeRequest">
<wsp:PolicyReference URI="#my_Input_policy" />
<soap:body use="literal" />
</wsdl:input>
<wsdl:output name="greetMeResponse">
<wsp:PolicyReference URI="#my_Output_policy" />
<soap:body use="literal" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>It is also possible to assign the #my_Input_policy to the output message greetMeResponse. You should make yourself familiar with the structure of a WSDL.
The IncludeTimestamp policy adds a timestamp element into the SOAP envelope header section. You could add other policies such as SignBeforeEncrypting on the same level. Please check the WS Security Policy Specification 1.2.
If the WSDL contains a SignedParts element, you must set the value for the Public Key Alias for Signing. If the WSDL contains an EncryptedParts element, you must set the value for Public Key Alias for Encryption.
SOAP Envelope Example of the Policy my_Input_policy
Using the policy assertions defined in my_Input_policy policy creates the SOAP message below. The value for Signature Algorithm within the channel configuration is SHA256/RSA.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
soap:mustUnderstand="1">
<wsu:Timestamp wsu:Id="TS-064384e5-5e7d-4303-922d-2e245584f800">
<wsu:Created>2018-01-03T16:26:11.041Z</wsu:Created>
<wsu:Expires>2018-01-03T16:31:11.041Z</wsu:Expires>
</wsu:Timestamp>
<xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Id="EK-5c3257f6-3a16-4669-b55f-e11f0089ad04">
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<wsse:SecurityTokenReference>
<wsse:KeyIdentifier
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#X509SubjectKeyIdentifier">TGIW9gPUwjc=</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>ZSXEQwi/CVYIoOi07xPsubwfoX5E3Ar4Sout4D/7sa18886vZlQ6A1AHRMtzFD4ytOT2i1ysZhdAPpMRlKRkcGaNy9Iq+AvQEXxroUP8/rV1GZ5W+CFhz7mrhwcNqCjuD3kPIPey01ZlokeRiy1RCeO20R9HimSQDRnhQho4qGyEgAm+MrdGBHh8PjFooxxVivh5nb8yaYysMKAG649dN5aPbp7KHT7if4oXIPE31zX/Rc9OBA2H2cSDgzQbwPv/FRsZBzWaCN1ZLHhvlHyAxVXSa+MmX/fXtQeh/RtALKvhVfkOAs4Wtw3FwocjBNTVKIU5EcJd4UWPmRMrRcaVCA==
</xenc:CipherValue>
</xenc:CipherData>
<xenc:ReferenceList>
<xenc:DataReference
URI="#ED-10bdd544-8ab1-49e5-a671-f5c65b0bcd45" />
</xenc:ReferenceList>
</xenc:EncryptedKey>
<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"
wsu:Id="X509-2e11b7fb-8229-4270-bfb8-03e4ed7655e7">MIIF/jCCA+agAwIBAgIDAR/9MA0GCSqGSIb3DQEBCwUAMEQxCzAJBgNVBAYTAkRFMREwDwYDVQQHDAhXYWxsZG9yZjEMMAoGA1UECgwDU0FQMRQwEgYDVQQDDAtTQVBOZXRDQV9HMjAeFw0xNzA2MDYwNzA4NDRaFw0xOTA2MDYwNzA4NDRaMFwxCzAJBgNVBAYTAkRFMQwwCgYDVQQKEwNTQVAxHzAdBgNVBAsTFkhhbmEgQ2xvdWQgSW50ZWdyYXRpb24xHjAcBgNVBAMTFXBpY291c2VyLmhjaS5zYXAuY29ycDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKMi9y6QJRUYl21E9Bh2qu1pcAMCQMtDvt4H1m5Ex1jUXpPZ0B3oOtXv0B3IaltL30t8iV7dAOFs9424mHK1x5m7Y1kAKez72yEdARG+e0iQHl3E1IedYuSGHx1jb1bylEjKwgiUjsGHO38SSNjiAXnObmp5jPT0Qd/g5cDs3Y0mA3m/PonBFkilsBdG9jxNjt0C0v5co2dkV3spu4jdIVioffPpG3jWInNvJ6yoi+9bE8WKdLcVRvsmrbr8/lCl9B1imKWdr1ZF1qFavl1fkd1ZxpnH+w6oX9xYfxgkmKgP8Sfd4gaXB8Vb/FxmAm3hQyrbk0mcVfCVL/R6dFjpl2sCAwEAAaOCAd8wggHbMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAfBgNVHSMEGDAWgBQ4JK+NdRL8OD83gxCvkDz8GyFa/zBJBggrBgEFBQcBAQQ9MDswOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEucGtpLmNvLnNhcC5jb20vYWlhL1NBUE5ldENBX0cyLmNydDCB3wYDVR0fBIHXMIHUMIHRoIHOoIHLhi1odHRwOi8vY2RwLnBraS5jby5zYXAuY29tL2NkcC9TQVBOZXRDQV9HMi5jcmyGgZlsZGFwOi8vL0NOPVNBUE5FVENBRzIsIENOPVNBUE5FVENBRzIsIENOPUNEUCwgQ049UHVibGljIEtleSBTZXJ2aWNlcywgQ049U2VydmljZXMsIENOPUNvbmZpZ3VyYXRpb24sIERDPWdsb2JhbCwgREM9Y29ycCwgREM9c2FwP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3QwEQYDVR0OBAoECExiFvYD1MI3MA4GA1UdDwEB/wQEAwIFoDA7BgNVHREENDAyghVwaWNvdXNlci5oY2kuc2FwLmNvcnCBGUQwNDA0MDlAZXhjaGFuZ2Uuc2FwLmNvcnAwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAgEAOgC3XSo4xAF9uiAZ8R+foK2ZBi3O+7yi/UWgfOVV0Edo/DBsADNwK5+whztCSWzvcoufV6b9StJrBMcLlAQQ2Ot1KIN6BAO8MzuGW23pVPjlk1qR1fgQVw3QGHFbNfBXWso9uBXRO/WwV04+Xxs8BHE+dET40xu/PFUa85nF+MrujHO88uwLxIK62xhv01BnwDjtlIBfboZKpKr31FeHxZzn71cEOMBXrZMinzhFoH/6wxHh6xqDvEvf/MXUxYsM6ZJlcQ79waSGN4a8pd8/b3hndb/cwNPXKJ3pjAO04RpIB0E4NGapWtV3e8FS25JmOHCXPZbT30DX2tFp2HNzNjwwKr41PrlB5RGyeKN4LuezFrEfhrTScI8IgOPKZwsvP1rNqb4/i++PRiOqm/miYxqyq+gpqmwf9XTzLSVlQfHISnzAHkgaRtzg5dQ4lQJeMdT+IXKZJ2xlIjlArAbhdA3uNXDJ85DjgntitAcznqTH4LdAJE5MFRNoHDN6luqa9ep7Yd216EM8K8kt/uLmCzT/GmefyyQfFM/7kxEvKAr4jie1Ehq9HIHo8VCoSIIfINIX1UJgpB9oEygr/8mO3O0d2/IUKnGQdeDD0hhxVncEEdAc90MmA0PQiMaURoopdXMeje4Hm51i/VwUv3OPtnlgTGvI9OPhwvP3D9CF6dE=
</wsse:BinarySecurityToken>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Id="SIG-5b701f28-dbd2-48f1-8f3e-b74113c94042">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="soap" />
</ds:CanonicalizationMethod>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference
URI="#TS-064384e5-5e7d-4303-922d-2e245584f800">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="wsse soap" />
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>kQR0twmEOHENY/z7ALCkP/tw27pQl25K0Zg8Z56Qp8A=
</ds:DigestValue>
</ds:Reference>
<ds:Reference
URI="#_f523d99c-3f8e-4518-bbea-1f83e867b776">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>55jH2VN67EZddt35kO/4E4y5TWa4vFiXgpV02TVYg9o=
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>gsBkbcah//pJEGUi6rFmLZeB8LZfHDjg+HsFm4L5kEXZlAkMzKO78zn9HJFcHC1WMbyXau2kNzh1mQ9cF2tbGGYoej/n71FJog1xxN64iQni8KhOSGKcWk7H7wM1sdtU80ndWTLpT4n8qYOuYyKE21UbwCQdSEd3Hj08/jTQUDXNNzv2ON0DEuEIQi33D0JDTAfbXRZg6WJtErgf8GNfNo5WcFVgPg60lyZ12u3Tlxv98B9mBfvGL+lAGcb3mc/bmFxYCCHCVr9sH+wA8C0NCAEwfow2PJTCT7WFcz1CofTmV96OKKDL7dJDD9vTas9fKKxzDD8xSxI3yYd1+HBpJw==
</ds:SignatureValue>
<ds:KeyInfo Id="KI-c35638d1-da71-405b-916f-4687fb025f61">
<wsse:SecurityTokenReference
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="STR-8c0dc8b6-9e65-40b7-8a60-a5cd1540db5f">
<wsse:Reference
URI="#X509-2e11b7fb-8229-4270-bfb8-03e4ed7655e7"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</soap:Header>
<soap:Body
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="_f523d99c-3f8e-4518-bbea-1f83e867b776">
<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Id="ED-10bdd544-8ab1-49e5-a671-f5c65b0bcd45" Type="http://www.w3.org/2001/04/xmlenc#Content">
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<wsse:SecurityTokenReference
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
wsse11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKey">
<wsse:Reference
URI="#EK-5c3257f6-3a16-4669-b55f-e11f0089ad04" />
</wsse:SecurityTokenReference>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>bcxRXno1mb6aCpS6omnySXVv5eT9vSFsfy97UcVJHcmqsaxkr4o66QmzU9SRQ6nazTC8GSQ/tK6pugH/W+SfILFpxw30PoNMA0Nm6asGC1SzuSUTrqA+uaajoeZ29y8KR5wj6cIRk/35sN0ZenXIhHNiKm5bi8Jor2EfzRvZ2ts=
</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</soap:Body>
</soap:Envelope>UsernameToken Assertion
Cloud Integration gives you the option to specify a user for the UsernameToken assertion. If you do not want the UsernameToken to be signed or encrypted, the WSDL policy should be SupportingTokens, which includes the UsernameToken assertion.
<sp:SupportingTokens xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken10 />
<sp:HashPassword />
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SupportingTokens>The policy HashPassword policy is an optional policy assertion. For details, please read the WSS specification.
If you want the UsernameToken to be signed, you must use the element SignedSupportingTokens instead of SupportingTokens. If the element SignedEncryptedSupportingTokens is used, the UsernameToken will be signed and encrypted.
UsernameToken and Manual WSS Configuration
If WSS is configured manually in the SOAP receiver channel, the UsernameToken is signed, if Sign Message is selected in the WS-Security Type field, and signed and encrypted if Sign and Encrypt Message is selected.
