 |
Home | Documentation |
The WS-Security plugin
updated Mon May 13 2024 by Robert van Engelen
|
|
Home | Documentation |
The WS-Security plugin
updated Mon May 13 2024 by Robert van Engelen
|
The WS-Security plugin conforms to:
WS-Security 1.1 with the following 1.1.1 additions:
Note on Basic Security Profile 1.1 compliance: the gSOAP wsse plugin cannot automatically verify that the wsse API calls made by an application comply with the profile's requirements. Users should verify the security considerations stated by the Basic Security Profile 1.1, in particular giving close attention to section 19.
The material in this section relates to the WS-Security specification.
The following requires the OpenSSL library 3.0 or 1.1 installed on your system. OpenSSL versions prior to 1.1.0 are also supported, but are not recommended.
To use the wsse plugin:
#import "wsse.h" or a similar import (see further below).-DWITH_DOM and -DWITH_OPENSSL compiler flags to set the WITH_DOM and WITH_OPENSSL defines. The smdevp.c, mecevp.c, and wsseapi.c files are located in the 'plugin' directory. If you used ./configure to configure the software, then it is recommended to use -DHAVE_CONFIG_H to compile stdsoap2.c/pp and all other source code by including the config.h settings.WS-Security applies to SOAP/XML messages, including SOAP document/literal and SOAP-RPC encoded messaging. SOAP-RPC encoded messages use id-ref attributes to reference XML elements (e.g. to serialize multi-referenced objects in XML). The digital signature algorithm signs and verifies XML messages with id-ref attributes, not the underlying object graph data structure, which could be cyclic for example. To remove id-ref serialization e.g. when using document/literal SOAP/XML messaging, use the runtim SOAP_XML_TREE flag or compile the source code with WITH_NOIDREF. The WS-Security protocol does not use SOAP-RPC encoded id-ref attributes.
An example WS-Security client/server application can be found in gsoap/samples/wsse that illustrates the use of the API to cover a wide range of WS-Security features. As a demo of the API, this example is not intended as a typical WS-Security client or server application.
Another example WS-Security client/server application that is designed to interoperate with WCF can be found in gsoap/samples/WCF/Basic/MessageSecurity.
keyid and keyidlen. To register your own security token handler function with the plugin, make sure that your callback functions matches these function parameters: The wsse engine is thread safe. However, if HTTPS is required then please follow the instructions in Section WS-Security and HTTPS to ensure thread-safety of WS-Security when combined with HTTPS.
The wsse API code is implemented in:
gsoap/plugin/wsseapi.h wsse API declarations.gsoap/plugin/wsseapi.c wsse API for C and C++.You will also need:
gsoap/custom/struct_timeval.c compile and link this file (C and C++).gsoap/plugin/smdevp.c compile and link this file (C and C++).gsoap/plugin/mecevp.c compile and link this file (C and C++).-DWITH_OPENSSL and -DWITH_DOM.-DWITH_GZIP to support compressed XML.-lssl -lcrypto -lz -lgsoapssl++ (or -lgsoapssl for C, or compile stdsoap2.cpp for C++ and stdsoap2.c for C).The gSOAP header file (generated with wsdl2h, and containing the data binding interface for soapcpp2) should import wsse.h:
This declaration supports WS-Security 1.0 by default and accepts WS-Security 1.1. Vice versa, to support WS-Security 1.1 by default and accept 1.0:
The wsdl2h tool adds the necessary import directives to the generated header file if the WSDL declares the use of WS-Security. If not, you may have to add the import directive shown above manually before running soapcpp2. Instead of manually adding the directive, you can let wsdl2h do this for you by adding the following lines to typemap.dat:
The wsdl2h tool uses typemap.dat to add or modify the generated code.
If you run soapcpp2 with option -p or -q to produce files with names prefixed as specified with these options, then you must define the macro SOAP_H_FILE when compiling wsseapi.c. Otherwise, wsseapi.c includes wsseapi.h that includes soapH.h by default, which is not present.
The following sections describe the wsse plugin API. The narrative must not be interpreted as a set of requirements to implement WS-Security, should not be used as a guide to select certain keys and key sizes, or as a recommendation in general. Rather, the API description explains which API functions are available to implement WS-Security operations vis-a-vis sections of the WS-Security standard. It is implicitly assumed that WS-Security API requirement policies are followed by the developers of the WS-Security Web API, such as defined by Basic Security Profiles.
When implementing WS-Security services, it is important to follow the WS-Policy instructions generated by the wsdl2h tool for WSDLs with WS-Policy elements. In any case, consult the latest basic security profiles for WS-Security, including important security considerations, see Basic Security Profile 1.1 section 19.
No guarantees are provided when the developer uses API calls of the wsse plugin to produce implementations that deviate from established policies and profiles or if he/she fails to check messages for the presence of headers that are required by policies, including but not limited to authentication requirements, message expiration validation, and verification that message parts are signed as required, using the API functions documented below. The developers of the wsse plugin took great care to validate and test its functionality in the field to ensure it operates properly when following security policies and profiles. The documentation, examples, and demos are meant to exemplify the API. Genivia and its developers waive any responsibility and liability when the software and examples are used by users or by third-parties in ways that modify their functionalities that deviate from established Web services security policies and Basic Security Profiles.
WS-Security is not a replacement of TLS. Secure transport with HTTPS is typically required to transport WS-Security messages.
The wsse API consists of a set of functions to populate and verify WS-Security headers and message body content. For more details, we refer to the following sections that correspond to the WS-Security specification sections:
The API is introduced below.
To add an empty Security header block to the SOAP header, use:
To delete a Security header from the SOAP Header:
To delete all headers from the SOAP Header:
code soap->header = NULL;
Adding an empty Security header block is not very useful. In the following, we present the higher-level functions of the wsse plugin to populate and verify Security header content.
To populate the SOAP-ENV:actor or SOAP-ENV:role attribute within the Security header, use:
To obtain the actor or role value (e.g. after receiving a message), use:
The SOAP-ENV:mustUnderstand attribute is automatically added and checked by the gSOAP engine. A gSOAP application compiled without Security support will reject Security headers.
Security header blocks are attached to the soap context, which means that the information will be automatically kept to support multiple invocations.
The material in this section relates to the WS-Security specification section 6.
To add a user name token to the Security header block, use:
The Id value is optional. When non-NULL the user name token is included in the digital signature to protect its integrity. It is common for the wsse plugin functions to accept such Ids, which are serialized as wsu:Id identifiers for cross-referencing XML elements. The signature engine of the wsse plugin is designed to automatically sign all wsu:Id attributed elements to simplify the code you need to write to implement the signing process.
To add a user name token with clear text password, use:
It is strongly recommended to use soap_wsse_add_UsernameTokenText only in combination with HTTPS encrypted transmission or not at all. A better alternative is to use password digests (and still use HTTPS as preferred). With password digest authentication, the digest value of a password (with message creation time and a random nonce) is compared on both sides, thus eliminating the need to exchange a password over the wire.
To add a user name token with password digest, use:
Although the password string is passed to this function, it is not rendered in XML or stored in a message log. Only digests are compared on both sides, not the passwords. This authentication method adds a timestamp and nonce to prevent message replay attacks.
It has been argued that this approach adopted by the WS-Security protocol is still vulnerable since the application retrieves the password in text form requiring a database to store passwords in clear text. However, a digest algorithm can be used to hash the passwords and store their digests instead, which eliminates the need to store clear-text passwords. This is a common approach adopted by Unix for decades.
By setting the Id value to a unique string, the user name token is also digitally signed by the signature engine further preventing tampering with its value.
You must use soap_wsse_add_UsernameTokenDigest for each message exchange to refresh the password digest even when the user name and password are not changed. Otherwise, the receiver might flag the message as a replay attack.
To specify a time stamp for the digest instead of the current time, use:
Clear-text passwords and password digests are verified with soap_wsse_verify_Password. To verify a password at the receiving side to authorize a request (e.g. within a Web service operation), use:
Here we used soap_wsse_delete_Security to remove the old security headers. To delete all headers from the SOAP Header is preferable if it contains old headers that we don't want to return to sender, i.e. back to the client:
code soap->header = NULL;
Note that the soap_wsse_get_Username functions sets the wsse:FailedAuthentication fault upon failure. It is common for the wsse plugin functions to return SOAP_OK or a wsse fault that should be passed to the sender by returning soap->error from service operations. The fault is displayed with the soap_print_fault function. To return signed faults back to the client, a signature is constructed as shown in the code snippet above. When the signature construction itself fails, we delete the partially constructed signature and return the fault to the client.
Password digest authentication prevents message replay attacks. The wsse plugin keeps a database of password digests to thwart replay attacks. This is the only part in the plugin code that requires mutex provided by threads.h. Of course, this only works correctly if the server is persistent, such as a stand-alone service. Note that CGI-based services do not keep state. Machine clocks must be synchronized and clock skew should not exceed SOAP_WSSE_CLKSKEW at the server side.
X509 certificates are commonly included in Security header blocks as binary security tokens. A certificate is used to verify the digital signature of a digitally signed message using the public key embedded within the certificate. The certificate itself is signed by a certificate authority (CA) that vouches for the authenticity of the certificate, i.e. to prove the identify of the message originator. This verification process is important, because digital signatures are useless without verification: an attacker could simply replace the message, sign it, and replace the certificate.
Certificates are automatically verified by the wsse plugin signature engine when received and accessed, which means that the certificates of the CAs must be made accessible to the wsse plugin as follows:
The soap_wsse_verify_X509 function checks the validity of a certificate. The check is automatically performed. The check is also performed when retrieving the certificate from a Security header block, either automatically by the wsse plugin's signature verification engine or manually as follows:
where Id is the identification string of the binary security token or NULL to get the first found in the Security header.
The X509 certificate returned by this function should be freed with X509_free to deallocate the certificate data:
The verification is an expensive process that will be optimized in future releases by caching the certificate chain.
To attach a binary security token stored in a PEM file to a Security header block for transmission, use:
A binary security token can be automatically signed by setting its Id attribute:
Repeatedly loading a certificate from a PEM file is inefficient. To reuse a certificate loaded from a PEM file for multiple invocations, use:
Other types of binary security tokens can be added to the Security header block using:
The use and processing rules for tokens such as SAML assertions is specific to an application. SAML 1.0 and 2.0 tokens are supported with the following functions to retrieve them from Security header blocks:
The pointers returned are non-NULL when these tokens are present. You can verify that a token is signed by the signature of the Security header with:
If the SAML token received contains a signature and/or time range conditions then you should verify that the SAML token is valid after receiving it in a Security header block of a WS-Security message:
The above assumes that a WS-Security message was received that was signed and decrypted (when applicable).
NotBefore and NotOnOrAfter is determined by the clock resolution of a time representation. The time_t resolution is seconds. Therefore, the struct timeval serializer is used to increase the resolution to microseconds (by using #import "custom/struct_timeval.h" in gsoap/import/saml2.h.To add a SAML token to the WS-Security headers, use soap_wsse_add_saml1(struct soap*, const char *id) or soap_wsse_add_saml2(struct soap*, const char *id):
and, respectively:
The code shown above adds an empty SAML token to the Security header block after which the SAML assertion issuer, subject, conditions, statements, and attributes should be set. Once these are set, the assertion can be signed with a ds:Signature and X509 certificate added to the assertion to create an enveloped signature:
It is a good habit to verify a SAML token that was created in memory with int soap_wsse_verify_saml1(struct soap*, saml1__AssertionType *saml1) or int soap_wsse_verify_saml2(struct soap*, saml2__AssertionType *saml2) as shown. This step is optional, but can be useful to detect if the private key and certificate are uncorrelated and should not be used.
The private key and certificate values can be obtained as shown in Section Signing Messages.
For implementing other types of tokens, you are encouraged to modify the import/wsse.h file to add more tokens to the _wsse__Security header block:
The tokens can be set with:
For tokens in DOM XML form, use the xsd__anyType DOM element:
The token in DOM form can be signed if you set the wsu:Id attribute to a unique value say "MyToken":
We recommend to use domcpp to generate code to set the token to send messages and get its values after receiving messages.
For tokens in XML "string" text form, use the _XML literal string (a char* type with XML content):
However, beware that XML text cannot be signed by the signature as a Security header (unless you embed it within a new element in the Security header block and set that element's wsu:Id attribute).
The material in this section relates to the WS-Security specification section 7.
To use a certificate for signature verification, add a direct security token reference URI for the token to the KeyInfo, for example:
and:
For X509 certificates we use this to add a binary security token with the certificate and a reference to the local token:
This follows the recommended practice to place Security token references in the KeyInfo element of a Signature. The KeyInfo is used to verify the validity of a signature value.
Key identifiers can be used as well:
Embedded references are added with:
Full support for embedded references requires coding to add tokens and assertions, as well as to consume embedded references at the receiving side. There is no automated mechanism to take the embedded references and process them accordingly.
The use of key names is not recommended, but in case they are required they can be added with:
The material in this section relates to the WS-Security specification section 8.
When signatures are used with encryption (Encryption), then encryption is always applied after signing. It is generally known that it is safe to perform encryption after signing, but not vice versa. In particular, this order allows for the encryption of the signature and its digests, as required by Basic Security Profile 1.1 section 19.4.
First, the wsse plugin must be registered to sign and verify messages:
XML signatures are usually computed over normalized XML (to ensure the XML processors of intermediate nodes can accurately reproduce the XML). To this end, the exclusive canonical XML standard (exc-c14n) is required, which is set using the SOAP_XML_CANONICAL flag:
To send messages with inclusive canonicalization, in addition to the SOAP_XML_CANONICAL flag also use:
However, exclusive canonicalization is recommended over inclusive canonicalization, or no canonicalization at all. WS Basic Security profiles 1.0 and 1.1 require exclusive canonicalization.
Flags to consider:
SOAP_XML_CANONICAL recommended to enable exc-c14n (exclusive canonicalization).SOAP_XML_INDENT optional, to emit more readable XML (see warning below).SOAP_IO_CHUNK efficient HTTP-chunked streaming messages.SOAP_ENC_GZIP for HTTP compression (also enables HTTP chunking).SOAP_XML_INDENT is enabled. Avoid using SOAP_XML_INDENT for interoperability. The implementation of canonicalization in WCF with respect to the normalization of white space between XML tags differs from the protocol standards.Next, decide which signature algorithm is appropriate to use:
HMAC-SHA is the simplest method, but relies on the fact that you have to make absolutely sure the key is kept secret on both the sending and receiving side. As long as the secret key is confidential, messages are securely signed. However, this is virtually impossible when exchanging messages with untrusted disparate parties. The advantage of HMAC-SHA is the speed by which messages are signed and verified.
Algorithms HMAC SHA1, SHA256, and SHA512 are supported:
SOAP_SMD_HMAC_SHA1 http://www.w3.org/2000/09/xmldsig#hmac-sha1SOAP_SMD_HMAC_SHA224 http://www.w3.org/2001/04/xmldsig-more#hmac-sha224SOAP_SMD_HMAC_SHA256 http://www.w3.org/2001/04/xmldsig-more#hmac-sha256SOAP_SMD_HMAC_SHA384 http://www.w3.org/2001/04/xmldsig-more#hmac-sha384SOAP_SMD_HMAC_SHA512 http://www.w3.org/2001/04/xmldsig-more#hmac-sha512DSA-SHA and RSA-SHA rely on public key cryptography. In simplified terms, a message is signed using the (confidential!) private key. The public key is used to verify the signature. Since only the originating party could have used its private key to sign the message, the integrity of the message is guaranteed. Of course, we must trust the public key came from the originator (it is often included as an X509 certificate in the message). To this end, a trusted certificate authority should have signed the public key, thereby creating a X509 certificate that contains the public key and the identity of the message originator.
The following DSA, RSA, and ECDSA algorithms are supported:
SOAP_SMD_SIGN_DSA_SHA1 http://www.w3.org/2000/09/xmldsig#dsa-sha1SOAP_SMD_SIGN_DSA_SHA256 http://www.w3.org/2000/09/xmldsig-more#dsa-sha256SOAP_SMD_SIGN_RSA_SHA1 http://www.w3.org/2000/09/xmldsig#rsa-sha1SOAP_SMD_SIGN_RSA_SHA224 http://www.w3.org/2001/04/xmldsig-more#rsa-sha224SOAP_SMD_SIGN_RSA_SHA256 http://www.w3.org/2001/04/xmldsig-more#rsa-sha256SOAP_SMD_SIGN_RSA_SHA384 http://www.w3.org/2001/04/xmldsig-more#rsa-sha384SOAP_SMD_SIGN_RSA_SHA512 http://www.w3.org/2001/04/xmldsig-more#rsa-sha512SOAP_SMD_SIGN_ECDSA_SHA1 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1SOAP_SMD_SIGN_ECDSA_SHA224 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha224SOAP_SMD_SIGN_ECDSA_SHA256 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256SOAP_SMD_SIGN_ECDSA_SHA384 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384SOAP_SMD_SIGN_ECDSA_SHA512 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512An optional callback function can be passed to the plugin that is responsible for providing a certificate or key to the wsse engine to verify a signed message. For example, when a security token is absent from an DSA-SHA or RSA-SHA signed message then the only mechanism to automatically verify the signature is to let the callback produce a certificate:
keyid and keyidlen.After the plugin is registered and a signature algorithm selected, the soap_wsse_sign function or the soap_wsse_sign_body function is used to initiate the signature engine to automatically sign outbound messages.
The code to sign the SOAP Body of a message using HMAC-SHA1 is:
The hmac_key above is some secret key you generated for the sending side and receiving side (don't use the one shown here). Instead of SHA1 above, you can also use the more secure SHA224, SHA256, SHA384 and SHA512 hashes.
As always, use soap_print_fault to display the error message.
To sign the body of an outbound SOAP message using RSA-SHA (DSA-SHA is similar), we include the X509 certificate with the public key as a BinarySecurityToken in the header and a KeyInfo reference to the token to let receivers use the public key in the trusted and verified (!) certificate to verify the authenticity of the message:
The private key and its certificate are often placed in the same file, see e.g. server.pem in the package.
To summarize the signing process:
soap_wsse_sign_body and/or soap_wsse_sign with soap_wsse_sign_only to sign the message.The soap_wsse_sign_body function signs the entire SOAP body but nothing else. If it is desirable to sign individual parts of a message the soap_wsse_sign_only and soap_wsse_sign functions should be used. All message parts with wsu:Id attributes are signed. These message parts should not be nested (nested elements will not be separately signed). By default, all and only those XML elements with wsu:Id attributes are signed. Therefore, the wsu:Id attribute values used in a message must be unique within the message. Although usually not required, the default signing rule can be overridden with the soap_wsse_sign_only function, see Signing Security Headers and Tokens.
For example, consider a transaction in which we only want to sign a contract in the SOAP Body. This allows us to modify the rest of the message or extract the contract in XML and pass it on with the signature.
The gSOAP header file includes a myContract declaration:
The default value of the wsu:Id is "Contract" so that we can instantiate the struct, automatically sign it, and send it as follows:
The above example shows a wsu:Id attribute embedded (hardcoded) in a struct. When it is not possible to add the wsu__Id member, for example when the type is a string instead of a struct, it is suggested to specify the XML element to be signed with the soap_wsse_set_wsu_id(soap, "space-separated string of
element names"). Use it before each call or in the server operation (when returning XML data from a service operation). This lets the engine add wsu:Id="tag" attribute-value pair to the element's tag name. For example:
This code adds the wsu:Id="ns-myContract" to the ns:myContract element. Here, the wsu__Id value in the struct MUST NOT be set. Otherwise, two wsu:Id attributes are present which is invalid. Also, the element signed must be unique in the message. That is, there cannot be more than one matching element, otherwise the resulting signature is invalid.
soap_wsse_set_wsu_id as shown above. This is automatically performed when a new message is received (but not automatically in a sequence of one-way sends for example).SOAP_XML_CANONICAL), because XML processors may not recognize prefixes in such QName contexts as visually utilized. With QName content in elements and attributes and SOAP_XML_CANONICAL enabled, we should use soap_wsse_set_InclusiveNamespaces(soap, "prefixlist") to define which namespace prefixes (space-separated in the string) should be considered inclusive. For example, xsi:type attribute values are QNames with xsd types (and perhaps other types), meaning we should add "xsd" to the inclusive namespace prefix list with soap_wsse_set_InclusiveNamespaces(soap, "xsd") to ensure xsi:type="xsd:TYPE" attributes with QName content are properly signed and not susceptible to certain wrapping attacks. A quick way to include all prefixes in the signed contents and thereby thwart signature wrapping attacks is to use soap_wsse_set_InclusiveNamespaces(soap, "+").soap_wsse_sign (do NOT use soap_wsse_sign_body).We recommend to sign the entire SOAP Body using soap_wsse_sign_body and reserve the use of soap_wsse_set_wsu_id for SOAP Header elements, such as WS-Addressing elements. For example, to add and sign WS-Addressing 2005 headers (which are activated with an #import "wsa5.h" in the header file for soapcpp2):
This code signs the wsa5 header elements that are set with soap_wsa_request, see the WS-Addressing "wsa" API in the gSOAP documentation for more information on the use of WS-Addressing). It is fine to specify more elements with soap_wsse_set_wsu_id than actually present in the XML payload. The other WS-Addressing headers are not present and are not signed.
If your are using WS-Addressing 2004 (which is activated with an #import "wsa.h" in the header file for soapcpp2) then change one line:
soap_wsse_set_wsu_id should only be set once for each soap_wsse_sign or soap_wsse_sign_body. Each new call overrides the previous setting.soap_wsse_set_wsu_id to set the wsu:Id for an element that occurs more than once in the payload, since each will have the same wsu:Id attribute that may lead to a WS-Signature failure.To sign security tokens such as user names, passwords, and binary security tokens, just assign their Id values with a unique string, such as "Time" for timestamps and "User" for user names. For example:
Note that by default all wsu:Id-attributed elements are signed. To filter a subset of wsu:Id-attributed elements for signatures, use the soap_wsse_sign_only function to specify a subset of the elements that have wsu:Id values as follows:
The wsu:Id values are provides with the add functions, such as "User" and "X509Token". The SOAP Body always has a wsu:Id value "Body" when soap_wsse_sign_body is used.
Note that in the above we MUST set the X509Token name for cross-referencing with a wsu:Id, which normally results in automatically signing that token unless filtered out with soap_wsse_sign_only. The SOAP Body wsu:Id is always "Body" and should be part of the soap_wsse_sign_only set of wsu:Id names to sign.
When using soap_wsse_set_wsu_id we need to use the tag name with soap_wsse_sign_only. For example:
soap_wsse_sign_only should only be set once for each soap_wsse_sign or soap_wsse_sign_body. Each new call overrides the previous.soap_wsse_sign_only. This is automatically performed when a new message is received (but not automatically in a sequence of one-way sends for example).To automatically verify the signature of an inbound message signed with DSA or RSA algorithms, assuming the message contains the X509 certificate as a binary security token, use:
All locally referenced and signed elements in the signed message will be verified with soap_wsse_verify_auto using the default settings set with SOAP_SMD_NONE. Elements that are not signed cannot be verified. Also elements referenced with absolute URIs that are not part of the message are not automatically verified. The received message is stored in a DOM accessible with soap->dom. This enables further analysis of the message content.
For a post-parsing check to verify if an XML element was signed in an inbound message, use:
The soap_wsse_verify_element function returns the number of matching elements signed.
The signed element nesting rules are obeyed, so if the matching element is a descendent of a signed element, it is signed as well.
Because it is a post check, a client should invoke soap_wsse_verify_element after the call completed. A service should invoke this function within the service operation routine, i.e. when the message request is accepted and about to be processed.
For example, to check whether the wsu:Timestamp element was signed, e.g. after checking that it is present and message expiration checked with soap_wsse_verify_Timestamp, use:
To check the SOAP Body (either using SOAP 1.1 or 1.2), simply use soap_wsse_verify_body.
The soap_wsse_verify_auto function keeps processing signed (and unsigned) messages as they arrive. For unsigned messages this can be expensive and the verification engine should be shut down using soap_wsse_verify_done.
There can be two problems with signature verification. First, some WS-Security implementations include SignedInfo/Reference/ without targeting an element, which will produce an error that a Reference URI target does not exist. To ignore these references, use SOAP_WSSE_IGNORE_EXTRA_REFS. Second, certificates provided by the peer are not verifiable unless the signing CA certificate is included in the cafile or capath. To disable peer certificate verification, set the fsslverify callback to return 1 as follows:
To reject peer certificates under all conditions except specific permitted conditions such as self-signed certificates in the chain, use the following code as a guide (see OpenSSL documentation on X509_STORE_CTX_get_error):
To verify the HMAC signature of an inbound message, the HMAC key must be supplied:
To summarize the signature verification process:
soap_wsse_verify_auto to verify inbound messages.soap_wsse_verify_done to terminate verification, e.g. to consume plain messages more efficiently.The material in this section relates to the WS-Security specification section 9.
When encryption is used with signing (Signatures), then encryption is always applied after signing. It is generally known that it is safe to perform encryption after signing, but not vice versa. In particular, this order allows for the encryption of the signature and its digests, as required by Basic Security Profile 1.1 section 19.4. The profile also requires the signature in the header to be encrypted and the entire SOAP Body, rather than parts of the SOAP Body. To this end, use soap_wsse_add_EncryptedKey_encrypt_only(..., "ds:Signature SOAP-ENV:Body") as described further below.
First, the wsse plugin must be registered:
To send messages with inclusive canonicalization, in addition to the SOAP_XML_CANONICAL flag also use:
However, exclusive canonicalization is recommended over inclusive canonicalization, or no canonicalization at all. WS Basic Security profile 1.0 requires exclusive canonicalization.
Flags to consider:
SOAP_XML_CANONICAL recommended to enable exc-c14n (exclusive canonicalization).SOAP_XML_INDENT optional, to emit more readable XML (see warning).SOAP_IO_CHUNK efficient HTTP-chunked streaming messages.SOAP_ENC_GZIP for HTTP compression (also enables HTTP chunking).SOAP_XML_INDENT is enabled. Avoid using SOAP_XML_INDENT for interoperability. The implementation of C14N in WCF with respect to the normalization of white space between XML tags differs from the protocol standards.Encryption should be used in combination with signing. A signature ensures message integrity while encryption ensures confidentially. Encrypted messages can be tampered with unless integrity is ensured. Therefore, the reader should be familiar with the material in Section Signatures should to sign and verify message content.
Messages are encrypted using either public key cryptography or by using a symmetric secret key. A symmetric secret key should only be shared between the sender and receiver (or any trusted communicating peer).
Encryption with public key cryptography uses an "envelope" process, where the public key of the recipient is used to encrypt a temporary (ephemeral) secret key that is sent together with the secret key-encrypted message to the recipient. The recipient decrypts the ephemeral key and uses it to decrypt the message. The public key is usually part of a X509 certificate. The public key (containing the subject information) is added to the Security header and used for encryption of the SOAP Body as follows:
SOAP_MEC_ENV_ENC_DES_CBC specifies envelope encoding with triple DES CBC and PKCS1 RSA-1_5. Use (SOAP_MEC_ENV_ENC_AES256_CBC | SOAP_MEC_OAEP) for AES256 CBC with OAEP padding (OAEP is recommended over RSA-1_5 or use GCM).
The envelope encryption options are:
SOAP_MEC_ENV_ENC_DES_CBC RSA-1_5 envelope encryption with triple DES CBCSOAP_MEC_ENV_ENC_AES256_CBC RSA-1_5 envelope encryption with AES256 CBCSOAP_MEC_ENV_ENC_AES256_GCM envelope authenticated encryption with AES256 GCMSOAP_MEC_ENV_ENC_AES256_CBC | SOAP_MEC_OAEP OAEP envelope encryption with AES256 CBCwhere, in the above, AES256 can also be replaced with AES128 or AES192.
The "Cert" parameter is a unique URI to reference the key from the encrypted SOAP Body. The above enables the encryption engine for the next message to be sent, either at the client or server side. The server should use this withing a server operation (before returning) to enable the service operation response to be encrypted.
To include a subject key ID in the Security header instead of the entire public key, specify the subject key ID parameter:
The difference with the previous example where no subject key ID was specified is that the Security header only contains the subject key ID and no longer the public key in base64 format.
To exclude the encrypted key certificate from the message and include a X509Data element with IssuerName and SerialNumber:
The issuer name and serial number (must be in decimal for soap_wsse_add_EncryptedKey) of a certificate can be obtained as follows:
Note that in the above code the leading slash in "/CN=Root Agency" is excluded from the issuer name.
When excluding the encrypted key certificate from the message, the token handler callback must be provided on the receiving end to obtain the certificate that corresponds to the issuer name and serial number.
To encrypt specific elements of the SOAP Header, such as the signature, and Body rather than just the SOAP Body alone, use soap_wsse_add_EncryptedKey_encrypt_only to specify elements to encrypt in combination with soap_wsse_set_wsu_id to specify these elements:
To encrypt the SOAP Body and SOAP Header element(s), such as ds:Signature, use "SOAP-ENV:Body" with soap_wsse_add_EncryptedKey_encrypt_only to specify these elements:
This means that you should not combine soap_wsse_encrypt_body with soap_wsse_encrypt_only to encrypt the SOAP Body.
soap_wsse_set_wsu_id MUST be used to specify all element tag names to encrypt. Additional elements MAY be specified in soap_wsse_set_wsu_id (for example elements to digitally sign). You do not have to use this function to set the wsu:Id of the SOAP Body which always has a wsu:Id with "Body". Likewise, the ds:Signature does not require to be specified with soap_wsse_set_wsu_id.soap_wsse_set_wsu_id to encrypt MUST occur NO MORE THAN ONCE in the XML message.For symmetric encryption with a shared secret key, generate a 160-bit triple DES key and make sure both the sender and reciever can use the key without it being shared by any other party (key exchange problem). Then use the soap_wsse_encrypt_body function to encrypt the SOAP Body as follows:
The symmetric encryption options are:
SOAP_MEC_ENC_DES_CBC symmetric encryption with triple DES CBCSOAP_MEC_ENC_AES256_CBC symmetric encryption with AES256 CBCSOAP_MEC_ENC_AES256_GCM symmetric authenticated encryption with AES256 GCMwhere, in the above, AES256 can also be replaced with AES128 or AES192.
For example, symmetric encryption with AES256:
To symmetrically encrypt specific elements of the SOAP Body rather than the entire SOAP Body, use soap_wsse_encrypt_only to specify the elements to encrypt in combination with soap_wsse_set_wsu_id to specify these elements:
soap_wsse_set_wsu_id MUST be used to specify all element tag names to encrypt. Additional elements MAY be specified in soap_wsse_set_wsu_id (for example elements to digitally sign).soap_wsse_set_wsu_id to encrypt MUST occur EXACTLY ONCE in the SOAP Body.The wsse engine automatically decrypts message parts, but requires a private key or secret shared key to do so. A default key can be given to enable decryption, but it will fail if a non-compatible key was used for encryption. In that case a token handler callback should be defined by the user to select a proper decryption key based on the available subject key name or identifier embedded in the encrypted message.
An example of a token handler callback:
The last two case-arms are used to return a key associated with the keyname paramater, which is a string that contains the subject key id from the public key information in an encrypted message or the subject key ID string that was set with soap_wsse_add_EncryptedKey at the sender side.
keyid and keyidlen.To set the default private key for envelope decryption, use:
The envelope decryption options are:
SOAP_MEC_ENV_DEC_DES_CBC RSA-1_5 envelope decryption with triple DES CBCSOAP_MEC_ENV_DEC_AES256_CBC RSA-1_5 envelope decryption with AES256 CBCSOAP_MEC_ENV_DEC_AES256_GCM envelope authenticated decryption with AES256 GCMSOAP_MEC_ENV_DEC_AES256_CBC | SOAP_MEC_OAEP OAEP envelope decryption with AES256 CBCwhere, in the above, AES256 can be replaced with AES128 or AES192.
To set the default shared secret key for symmetric decryption, use:
The symmetric decryption options are:
SOAP_MEC_DEC_DES_CBC symmetric decryption with triple DES CBCSOAP_MEC_DEC_AES256_CBC symmetric decryption with AES256 CBCSOAP_MEC_DEC_AES256_GCM symmetric authenticated decryption with AES256 GCMwhere, in the above, AES256 can be replaced with AES128 or AES192.
For example, symmetric decryption with AES256:
If a default key is not set, the token handler callback should be used as discussed above in this section. Do NOT set a default key if a token handler is used to handle multiple different keys. The default key mechanism is simpler to use when only one decryption key is used to decrypt all encrypted messages.
To remove the default key, use:
The code for a client is shown below that uses signatures and encryption:
When using HTTPS, the soap->cafile, soap->capath are already set with soap_ssl_client_context(). The explicit assignments shown above are not needed.
See Signature Validation on how to implement the optional ssl_verify callback to verify peer certificates.
You may want to register a token handler callback if the peer does not include its X509 certificate in the security header. The token handler callback should retrieve the certificate, e.g. given its id and serial number.
The server-side service is implemented as follows:
where an example service operation could be:
The service operation signs the Body using its private key and encrypts the response Body and signature using a public key from the peer's certificate.
To implement a server that supports HTTP keep-alive, a soap->fserveloop callback function should be assigned. This callback is executed in the soap_serve() loop to call soap_wsse_verify_auto() and soap_wsse_decrypt_auto() to ensure that the continuous inbound message stream can be verified and decrypted:
The material in this section relates to the WS-Security specification section 10.
To add a timestamp with the creation time to the Security header, use:
The lifetime of a message (in seconds) is passed as the third argument, which will be displayed as the timestamp expiration time:
Timestamps, like other header elements, are not automatically secured with a digital signature. To secure a timestamp, we add an identifier (wsu:Id) to each element we want the WS-Security plugin to sign thereby making it impossible for someone to tamper with that part of the message. To do this for the timestamp, we simply pass a unique identification string as the second argument:
After receiving a message, the receiver can verify the presence and validity of the timestamp and whether it was signed with:
HTTPS is used at the client side with the usual "https:" URL addressing, shown here with the registration of the wsse plugin and setting up locks for thread-safe use of SSL for HTTPS:
The CRYPTO threads should be set up before any threads are created.
The soap_ssl_client_context only needs to be set up once. Use the following flags:
SOAP_SSL_DEFAULT requires server authentication, CA certs should be usedSOAP_SSL_NO_AUTHENTICATION disables server authenticationSOAP_SSL_SKIP_HOST_CHECK disables server authentication host checkSOAP_SSL_ALLOW_EXPIRED_CERTIFICATE to accept self-signed certificates, expired certificates, and certificates without CRL.The server uses the following:
where we define a process_request() function that is executed by the thread to process the request (on a copy of the soap context struct):
The soap_ssl_server_context only needs to be set up once. Use the following flags:
SOAP_SSL_DEFAULT requires server authentication, but no client authenticationSOAP_SSL_REQUIRE_CLIENT_AUTHENTICATION requires client authenticationWe also should implement the mutex setup and cleanup operations as follows:
For additional details and examples, see the user guide and examples in the gSOAP package directory gsoap/samples/ssl.
The Security header block was generated from the WS-Security schema with the wsdl2h tool and WS/WS-typemap.dat:
wsdl2h -cegxy -o wsse.h -t WS/WS-typemap.dat WS/wsse.xsd
The same process was used to generate the header file ds.h from the XML digital signatures core schema, and the xenc.h encryption schema:
wsdl2h -cuxy -o ds.h -t WS/WS-typemap.dat WS/ds.xsd wsdl2h -cuxy -o xenc.h -t WS/WS-typemap.dat WS/xenc.xsd
The import/wsse.h file has the following definition for the Security header block:
The _wsse__Security header is modified by a WS/WS-typemap.dat mapping rule to include additional details.
soap_wsse_add_EncryptedKey_encrypt_only is not supported. You can encrypt elements with complex content (complexType and complexContent elements that have sub elements). This is not a limitation for decryption with the WSSE plugin, which is not limited to elements with complex content.EncryptedHeader elements (WS-Security 1.1.1) are not supported. Any or all subelements of a SOAP Header may be encrypted, but not the SOAP Header itself, replaced by <wsse11:EncryptedHeader> with encrypted contents.soap_wsse_add_EncryptedKey_encrypt_only(..., "ds:Signature SOAP-ENV:Body").soap_wsse_set_InclusiveNamespaces(soap, "prefixlist") to define all namespace prefixes (space-separated in the string) that should be considered inclusive. All prefixes used in QName content should be listed to mitigate the security risks outlined. The WSSE engine recognizes xsi:type, SOAP-ENC:arrayType, SOAP-ENC:itemType attribute QNames. Therefore, soapcpp2 option -t is always safe to use, but a non-gSOAP receiver may still fail.Signature wrapping attacks exploit a vulnerability in the XML DSig standard by tricking the signature verifier to verify the signature of the signed content but when this content is moved to a different place in the XML document, for example where the content is ignored. In this attack, a signed XML element identified with an id attribute is moved in the document and replaced with an unsigned replacement element with aribitrary content that the attacker created and the receiver will use instead. We refer to online articles and publications on signature wrapping attacks for more details.
To defend against signature wrapping attacks, it is recommended to sign the SOAP Body instead of individual elements of the SOAP Body. A receiver must verify that the SOAP Body received is indeed signed and verify that other parts of the message such as critical SOAP Headers are signed. You can do this on the receiving end by calling soap_wsse_verify_body(soap) and check that the return value is nonzero. This prevents signature wrapping attacks on the SOAP Body. If individual element(s) of the SOAP Body must be signed instead of the body itself, then make sure to use call soap_wsse_verify_element(soap, "namespaceURI", "tag") on the receiving end and check that the return value is nonzero to verify that all elements matching the namespaceURI and tag are signed.
If SOAP Headers are signed such as the timestamp and username token then make sure to verify that the timestamp was indeed signed by calling soap_wsse_verify_element(soap, SOAP_NAMESPACE_OF_wsu, "Timestamp") and check that the return value is nonzero. Likewise, to verify that the usernameToken authentication credentials are signed, call soap_wsse_verify_element(soap, SOAP_NAMESPACE_OF_wsse, "UsernameToken") and check that the return value is nonzero.
To prevent signature wrapping attacks on XML namespace prefixes used in QNames, which are vulnerable when the prefix is bound to a namespace URI in an ancester node to the signed content, use soap_wsse_set_InclusiveNamespaces(soap, "prefixlist"). This makes the namespace prefixes in the list (space-separated in the string) inclusive. Use soap_wsse_set_InclusiveNamespaces(soap, "+") to automatically add all prefixes defined in the namespace table (i.e. the .nsmap file) to the inclusive namespace list (this requires gSOAP 2.8.64 or greater).
To use a WS-SecureConversation security context token (SCT) with WS-Security:
In this example a context has been established and the secret that is identified by the 'identifier' string is known to both parties. This secret is used to sign the message body. The "SCT" is a wsu:Id, which is used as a reference to sign the token.
To compute PSHA1 with base64 input strings client_secret_base64 and server_secret_base64 to output a base64-encoded psha1[0..psha1len-1] string psha1_base64:
Similarly, PSHA256 can be computed by calling soap_psha256().