|  | Home | Documentation | The WS-Security plugin updated Tue Jun 27 2023 by Robert van Engelen |

- Main Page
- Related Pages
- Classes
- Files

The WS-Security plugin

# Standards compliance

The WS-Security plugin conforms to:

- WS-Security 1.1 (and backward compatibility with WS-Security 1.0)
- XML Signature Syntax and Processing (XMLDSIG)
- XML Encryption Syntax and Processing (XMLENC)
- SAML 1.0 and 2.0

WS-Security 1.1 with the following 1.1.1 additions:

- Web Services Security SOAP Message Security 1.1.1
- Web Services Security Username Token Profile 1.1.1
- Web Services Security Kerberos Token Profile 1.1.1
- Web Services Security SAML Token Profile 1.1.1
- Web Services Security X.509 Certificate Token Profile 1.1.1
- Web Services Security Rights Expression Language (REL) Token Profile 1.1.1

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.

# Security Header

The material in this section relates to the WS-Security specification.

## Getting started

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:

1. Run wsdl2h -t typemap.dat on a WSDL of a service that requires WS-Security headers. The typemap.dat file is used to recognize and translate Security header blocks for XML signature and encryption. The generated file also includes WS-Policy instructions with WS-Security requirements to follow, when WS-Policy is typically present in the WSDL.
2. Run soapcpp2 on the header file produced by wsdl2h. The generated header file must include WS-Security declarations imported with `#import "wsse.h"` or a similar import (see further below).
3. (Re-)compile stdsoap2.c/pp, dom.c/pp, smdevp.c, mecevp.c, wsseapi.c and the generated source files with the `-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.
4. Use the wsse plugin API functions described below to add and verify Security headers, sign and verify messages, and to encrypt/decrypt messages.

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.

Warning
  The security token handler callback function parameters have changed in 2.8.34 and greater with the addition of KeyIdentifier information `keyid` and `keyidlen`. To register your own security token handler function with the plugin, make sure that your callback functions matches these function parameters:
  const void *security_token_handler(struct soap *soap, int *alg, const char *keyname, const unsigned char *keyid, int keyidlen, int *keylen);

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++).
- compile all source code files with `-DWITH_OPENSSL` and `-DWITH_DOM`.
- if you have zlib installed, compile all source code files with `-DWITH_GZIP` to support compressed XML.
- link with `-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:

#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:

#import "wsse11.h"

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:

[
#import "wsse.h"
]

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.

## Warning

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.

## Introduction

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:

- Section 6 Security Tokens
- Section 7 Token References
- Section 8 Signatures
- Section 9 Encryption
- Section 10 Security Timestamps
- WS-Security and HTTPS
- Miscellaneous
- Limitations and Security Considerations
- WS-SecureConversation and WS-Trust

The API is introduced below.

To add an empty Security header block to the SOAP header, use:

soap_wsse_add_Security(soap);

To delete a Security header, use:

soap_wsse_delete_Security(soap);

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.

Note
  The soap context includes an actor value soap.actor that is populated and rendered as the SOAP-ENV:actor (SOAP 1.1) or SOAP-ENV:role (SOAP 1.2) attribute in XML within the generic SOAP Header. The attribute is optional, but should be used to target a recipient such as an intermediate node to process the SOAP header. In contrast, actor or role attributes within Security header blocks target specific recipients to process the Security header block. The gSOAP implementation does not automate this feature and application should set and check the actor/role attribute when necessary. In addition, the current implementation supports the inclusion of a single Security header block in the SOAP header.

To populate the SOAP-ENV:actor or SOAP-ENV:role attribute within the Security header, use:

soap_wsse_add_Security_actor(soap, "recipient");

To obtain the actor or role value (e.g. after receiving a message), use:

_wsse__Security *security = soap_wsse_Security(soap);
if (security)
{
... = security->SOAP_ENV__actor; // SOAP 1.1
... = security->SOAP_ENV__role; // SOAP 1.2

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.

# Security Tokens

The material in this section relates to the WS-Security specification section 6.

## User Name Tokens

To add a user name token to the Security header block, use:

soap_wsse_add_UsernameTokenText(soap, "Id", "username", NULL);

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 `Id`s, 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:

soap_wsse_add_UsernameTokenText(soap, "Id", "username", "password");

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:

soap_wsse_add_UsernameTokenDigest(soap, "Id", "username", "password");

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:

time_t when = ...;
soap_wsse_add_UsernameTokenDigest_at(soap, "Id", "username", "password", when);

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:

int ns__myMethod(struct soap *soap, ...)
{
const char *username = soap_wsse_get_Username(soap);
const char *password;
if (!username)
{
soap_wsse_delete_Security(soap); // remove old security headers
return soap->error; // no username: return FailedAuthentication (from soap_wsse_get_Username)
}
password = ...; // lookup password of username
if (soap_wsse_verify_Password(soap, password))
{
int err = soap->error;
soap_wsse_delete_Security(soap); // remove old security headers
// if it is required to return signed faults, then add the following six lines here:
if (soap_wsse_add_BinarySecurityTokenX509(soap, "X509Token", cert)
|| soap_wsse_add_KeyInfo_SecurityTokenReferenceX509(soap, "#X509Token")
|| soap_wsse_sign_body(soap, SOAP_SMD_SIGN_RSA_SHA256, rsa_private_key, 0)
{
soap_wsse_delete_Security(soap); // remove security headers (failed construction)
return soap->error;
}
return err; // password verification failed: return FailedAuthentication
}
... // process request, then sign the response message:
if (soap_wsse_add_BinarySecurityTokenX509(soap, "X509Token", cert)
|| soap_wsse_add_KeyInfo_SecurityTokenReferenceX509(soap, "#X509Token")
|| soap_wsse_sign_body(soap, SOAP_SMD_SIGN_RSA_SHA256, rsa_private_key, 0)
{
soap_wsse_delete_Security(soap); // remove security headers (failed construction)
return soap->error;
}
return SOAP_OK;
}

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.

## Binary Security Tokens

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:

soap->cafile = "cacerts.pem"; // use this
soap->capath = "dir/to/certs"; // and/or point to CA certs
soap->crlfile = "revoked.pem"; // use CRL (optional)

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:

X509 *cert = soap_wsse_get_BinarySecurityTokenX509(soap, "Id");

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:

if (cert)
X509_free(cert);
cert = NULL;

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:

soap_wsse_add_BinarySecurityTokenPEM(soap, NULL, "mycert.pem")

A binary security token can be automatically signed by setting its `Id` attribute:

soap_wsse_add_BinarySecurityTokenPEM(soap, "X509Token", "mycert.pem")

Repeatedly loading a certificate from a PEM file is inefficient. To reuse a certificate loaded from a PEM file for multiple invocations, use:

FILE *fd = fopen("mycert.pem", "r");
X509 *cert = PEM_read_X509(fd, NULL, NULL, NULL);
fclose(fd);
if (soap_wsse_add_BinarySecurityTokenX509(soap, "X509Token", cert))
... // an error occurred

Other types of binary security tokens can be added to the Security header block using:

soap_wsse_add_BinarySecurityToken(soap, "Id", "valueType", data, datalen);

# SAML and Other Tokens

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:

saml1__AssertionType *assertion1 = soap_wsse_get_saml1(soap);
saml2__AssertionType *assertion2 = soap_wsse_get_saml2(soap);

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:

saml2__AssertionType *assertion2 = soap_wsse_get_saml2(soap);
if (!assertion2 || soap_wsse_verify_element(soap, SOAP_NAMESPACE_OF_saml2, "Assertion") == 0)
... error // no Assertion or Assertion not signed by WS-Security signature (zero Assertion elements signed)

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:

if (saml2->saml2__Conditions)
{
time_t now = time(NULL);
if (saml2->saml2__Conditions->NotBefore && *saml2->saml2__Conditions->NotBefore > now)
... error // not valid yet
if (saml2->saml2__Conditions->NotOnOrAfter && *saml2->saml2__Conditions->NotOnOrAfter <= now)
... error // expired
}
if (saml2->ds__Signature)
if (soap_wsse_verify_with_signature(soap, saml2->ds__Signature))
... error // Assertion has signature but token is invalid

The above assumes that a WS-Security message was received that was signed and decrypted (when applicable).

Note
  The resolution of the dateTime values of `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)`:

time_t now = time(NULL);
saml1__AssertionType *assertion1 = soap_wsse_add_saml1(soap, "SAML1");
if (!assertion1)
... // error
assertion1->IssueInstant = now;
assertion1->Issuer = (char*)"MyCompany";
assertion1->saml1__Conditions = soap_new_saml1__ConditionsType(soap, -1);
if (!assertion1->saml1__Conditions)
... // error
// valid from now for up to one hour
assertion1->saml1__Conditions->NotBefore = soap_new_dateTime(soap, -1)
if (!assertion1->saml1__Conditions->NotBefore)
... // error
*assertion1->saml1__Conditions->NotBefore = now;
assertion1->saml1__Conditions->NotOnOrAfter = soap_new_dateTime(soap, -1)
if (!assertion1->saml1__Conditions->NotOnOrAfter)
... // error
*assertion1->saml1__Conditions->NotOnOrAfter = now + 3600;
...

and, respectively:

time_t now = time(NULL);
saml2__AssertionType *assertion2 = soap_wsse_add_saml2(soap, "SAML2");
if (!assertion2)
... // error
assertion2->IssueInstant = now;
assertion2->saml2__Issuer = (struct saml2__NameIDType*)soap_malloc(soap, sizeof(struct saml2__NameIDType));
soap_default_saml2__NameIDType(soap, assertion2->saml2__Issuer);
assertion2->saml2__Issuer->__item = (char*)"MyCompany";
// valid from now for up to one hour
assertion2->saml2__Conditions->NotBefore = soap_new_dateTime(soap, -1)
if (!assertion2->saml2__Conditions->NotBefore)
... // error
*assertion2->saml2__Conditions->NotBefore = now;
assertion2->saml2__Conditions->NotOnOrAfter = soap_new_dateTime(soap, -1)
if (!assertion2->saml2__Conditions->NotOnOrAfter)
... // error
*assertion2->saml2__Conditions->NotOnOrAfter = now + 3600;
...

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:

EVP_PKEY *rsa_private_key; // private key
X509 *cert; // certificate (e.g. in "cacert.pem")
...
saml2__AssertionType *assertion2 = soap_wsse_add_saml2(soap, "SAML2");
if (!assertion2)
... // error
... // set SAML issuer, subject, conditions, statements, and attributes
if (soap_wsse_sign_saml2(soap, assertion2, SOAP_SMD_SIGN_RSA_SHA256, private_key, 0, cert))
... error // could not sign and/or add cert to X509Data
soap->cafile = "cacert.pem"; // file that contains the public certificate
if (soap_wsse_verify_saml2(soap, assertion2))
... error // coult not verify the signature, e.g. invalid key-certificate pair

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:

struct somens__SomeTokenType { @char *wsu__Id; ... };
typedef struct _wsse__Security
{ ...
struct saml1__AssertionType* saml1__Assertion;
struct saml2__AssertionType* saml2__Assertion;
struct somens__SomeTokenType* somens__SomeToken; // added an optional token
... // add more if needed
@char* SOAP_ENV__actor;
@char* SOAP_ENV__role;
} _wsse__Security;

The tokens can be set with:

_wsse__Security *security = soap_wsse_Security(soap);
security->somens__SomeToken = (struct somens__SomeTokenType*)soap_malloc(soap, sizeof(struct somens__SomeTokenType));
soap_default_somens__SomeTokenType(soap, security->somens__SomeToken);
security->somens__SomeToken->wsu__Id = "myToken"; // allows for auto-signing this element
...

For tokens in DOM XML form, use the `xsd__anyType` DOM element:

typedef struct _wsse__Security
{ ...
xsd__anyType* somens__SomeToken; // added an optional token in DOM form
} _wsse__Security;

The token in DOM form can be signed if you set the wsu:Id attribute to a unique value say "MyToken":

_wsse__Security *security = soap_wsse_Security(soap);
security->somens__SomeToken = (xsd__anyType*)soap_malloc(soap, sizeof(xsd__anyType));
soap_default_xsd__anyType(soap, security->somens__SomeToken);
soap_att_text(soap_att(soap_add_security->somens__SomeToken, NULL, "wsu:Id"), "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):

typedef struct _wsse__Security
{ ...
_XML somens__SomeToken; // added an optional token in string form
} _wsse__Security;

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).

# Token References

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:

soap_wsse_add_KeyInfo_SecurityTokenReferenceURI(soap, "URI", "valueType");

and:

soap_wsse_add_KeyInfo_SecurityTokenReferenceX509(soap, "URI");

For X509 certificates we use this to add a binary security token with the certificate and a reference to the local token:

if (soap_wsse_add_BinarySecurityTokenX509(soap, "X509Token", cert)
|| soap_wsse_add_KeyInfo_SecurityTokenReferenceX509(soap, "#X509Token"))
... // an error occurred

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:

soap_wsse_add_KeyInfo_SecurityTokenReferenceKeyIdentifier(soap, "Id", "valueType", data, datalen);

Embedded references are added with:

soap_wsse_add_KeyInfo_SecurityTokenReferenceEmbedded(soap, "Id", "valueType");

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:

soap_wsse_add_KeyInfo_KeyName(soap, "name");

# Signatures

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:

soap_register_plugin(soap, soap_wsse);

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:

struct soap *soap = soap_new1(SOAP_XML_CANONICAL);
soap_register_plugin(soap, soap_wsse);

To send messages with inclusive canonicalization, in addition to the `SOAP_XML_CANONICAL` flag also use:

soap_wsse_set_InclusiveNamespaces(soap, "*");

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).

Warning
  Interoperability with WCF WS-Security is not guaranteed when `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 uses a secret key (also known as a shared key in symmetric cryptography) to sign the SHA digest of the SignedInfo element.
- DSA-SHA uses a DSA private key to sign the SHA digest of the SignedInfo element.
- RSA-SHA uses a RSA private key to sign the SHA digest of the SignedInfo element.
- ECDSA-SHA uses a Elliptic Curve DSA private key to sign the SHA digest of the SignedInfo element.

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-sha1
- `SOAP_SMD_HMAC_SHA224` http://www.w3.org/2001/04/xmldsig-more#hmac-sha224
- `SOAP_SMD_HMAC_SHA256` http://www.w3.org/2001/04/xmldsig-more#hmac-sha256
- `SOAP_SMD_HMAC_SHA384` http://www.w3.org/2001/04/xmldsig-more#hmac-sha384
- `SOAP_SMD_HMAC_SHA512` http://www.w3.org/2001/04/xmldsig-more#hmac-sha512

DSA-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-sha1
- `SOAP_SMD_SIGN_DSA_SHA256` http://www.w3.org/2000/09/xmldsig-more#dsa-sha256
- `SOAP_SMD_SIGN_RSA_SHA1` http://www.w3.org/2000/09/xmldsig#rsa-sha1
- `SOAP_SMD_SIGN_RSA_SHA224` http://www.w3.org/2001/04/xmldsig-more#rsa-sha224
- `SOAP_SMD_SIGN_RSA_SHA256` http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
- `SOAP_SMD_SIGN_RSA_SHA384` http://www.w3.org/2001/04/xmldsig-more#rsa-sha384
- `SOAP_SMD_SIGN_RSA_SHA512` http://www.w3.org/2001/04/xmldsig-more#rsa-sha512
- `SOAP_SMD_SIGN_ECDSA_SHA1` http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1
- `SOAP_SMD_SIGN_ECDSA_SHA224` http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha224
- `SOAP_SMD_SIGN_ECDSA_SHA256` http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256
- `SOAP_SMD_SIGN_ECDSA_SHA384` http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384
- `SOAP_SMD_SIGN_ECDSA_SHA512` http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512

An 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:

soap_register_plugin(soap, soap_wsse);
soap_wsse_set_security_token_handler(soap, security_token_handler);
const void *security_token_handler(struct soap *soap, int *alg, const char *keyname, const unsigned char *keyid, int keyidlen, int *keylen)
{
// Get the user name from UsernameToken in message
const char *uid = soap_wsse_get_Username(soap);
switch (*alg)
{
case SOAP_SMD_VRFY_DSA_SHA1:
case SOAP_SMD_VRFY_DSA_SHA256:
case SOAP_SMD_VRFY_RSA_SHA1:
case SOAP_SMD_VRFY_RSA_SHA224:
case SOAP_SMD_VRFY_RSA_SHA256:
case SOAP_SMD_VRFY_RSA_SHA384:
case SOAP_SMD_VRFY_RSA_SHA512:
case SOAP_SMD_VRFY_ECDSA_SHA1:
case SOAP_SMD_VRFY_ECDSA_SHA224:
case SOAP_SMD_VRFY_ECDSA_SHA256:
case SOAP_SMD_VRFY_ECDSA_SHA384:
case SOAP_SMD_VRFY_ECDSA_SHA512:
if (uid)
{
// Lookup uid to retrieve the X509 certificate to verify the signature
const X509 *cert = ...;
return (const void*)cert;
}
return NULL; // no certificate: fail
case SOAP_SMD_HMAC_SHA1:
case SOAP_SMD_HMAC_SHA224:
case SOAP_SMD_HMAC_SHA256:
case SOAP_SMD_HMAC_SHA384:
case SOAP_SMD_HMAC_SHA512:
if (uid)
{
// Lookup uid to retrieve the HMAC SHA key to verify the signature
const void *key = ...;
*alg = ...;
*keylen = ...;
return key;
}
return NULL; // no certificate: fail
case SOAP_MEC_ENV_DEC_DES_CBC:
case SOAP_MEC_ENV_DEC_AES128_CBC:
case SOAP_MEC_ENV_DEC_AES192_CBC:
case SOAP_MEC_ENV_DEC_AES256_CBC:
case SOAP_MEC_ENV_DEC_AES512_CBC: // reserved for future use
case SOAP_MEC_ENV_DEC_AES128_GCM: // GCM requires OpenSSL 1.0.2 or higher
case SOAP_MEC_ENV_DEC_AES192_GCM: // GCM requires OpenSSL 1.0.2 or higher
case SOAP_MEC_ENV_DEC_AES256_GCM: // GCM requires OpenSSL 1.0.2 or higher
case SOAP_MEC_ENV_DEC_AES512_GCM: // GCM requires OpenSSL 1.0.2 or higher
if (keyname)
{
// use this to get key or X509 certificate from a key store using the keyname value:
// 1. keyname is set to the subject name of the certificate, if a
// certificate is present in the SecurityTokenReference/KeyIdentifier
// when ValueType is http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3
// 2. keyname is set to the string concatenation
// "{X509IssuerName}#{X509SerialNumber}" of the X509IssuerName
// and X509SerialNumber present in X509Data/X509IssuerSerial
// 3. keyname is set to X509Data/X509SubjectName
return ...;
}
else if (keyid)
{
// use this to get the key from a key store using the keyid[0..keyidlen-1]:
// 1. keyid and keyidlen are set to the data in
// SecurityTokenReference/KeyIdentifier when the ValueType is
// http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier
return ...;
}
break;
case SOAP_MEC_DEC_DES_CBC:
case SOAP_MEC_DEC_AES128_CBC:
case SOAP_MEC_DEC_AES192_CBC:
case SOAP_MEC_DEC_AES256_CBC:
case SOAP_MEC_DEC_AES512_CBC: // reserved for future use
case SOAP_MEC_DEC_AES128_GCM: // GCM requires OpenSSL 1.0.2 or higher
case SOAP_MEC_DEC_AES192_GCM: // GCM requires OpenSSL 1.0.2 or higher
case SOAP_MEC_DEC_AES256_GCM: // GCM requires OpenSSL 1.0.2 or higher`
case SOAP_MEC_DEC_AES512_GCM: // GCM requires OpenSSL 1.0.2 or higher
if (keyname)
{
// use the keyname to get the shared secret key associated for decryption
*keylen = ... // length of the shared secret key
return ...;
}
break;
}
return NULL; // fail
}

Warning
  The security token handler callback function parameters have changed in 2.8.34 and greater with the addition of KeyIdentifier information `keyid` and `keyidlen`.

## Signing Messages

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:

static char hmac_key[16] =
{ 0xff, 0xee, 0xdd, 0xcc, 0xbb, 0xaa, 0x99, 0x88,
0x77, 0x66, 0x55, 0x44, 0x33, 0x22, 0x11, 0x00 };
struct soap *soap = soap_new1(SOAP_XML_CANONICAL);
soap_register_plugin(soap, soap_wsse);
if (soap_wsse_sign_body(soap, SOAP_SMD_HMAC_SHA1, hmac_key, sizeof(hmac_key))
... // an error occurred
else if (soap_call_ns__myMethod(soap, ...))
... // a transmission error occurred

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:

FILE *fd;
EVP_PKEY *rsa_private_key;
X509 *cert;
struct soap *soap = soap_new1(SOAP_XML_CANONICAL);
soap_register_plugin(soap, soap_wsse);
fd = fopen("privkey.pem", "r");
rsa_private_key = PEM_read_PrivateKey(fd, NULL, NULL, "password");
fclose(fd);
fd = fopen("cert.pem", "r");
X509 *cert = PEM_read_X509(fd, NULL, NULL, NULL);
fclose(fd);
if (soap_wsse_add_BinarySecurityTokenX509(soap, "X509Token", cert)
|| soap_wsse_add_KeyInfo_SecurityTokenReferenceX509(soap, "#X509Token")
|| soap_wsse_sign_body(soap, SOAP_SMD_SIGN_RSA_SHA256, rsa_private_key, 0))
... // an error occurred
else if (soap_call_ns__myMethod(soap, ...))
... // a transmission error occurred

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:

1. Register the wsse plugin.
2. Obtain an HMAC secret key or a DSA/RSA/ECDSA private key.
3. For DSA or RSA, obtain the X509 certificate with the public key signed by a certificate authority.
4. Add the X509 certificate as a BinarySecurityToken to the header.
5. Add a KeyInfo BinarySecurityTokenReference.
6. Invoke `soap_wsse_sign_body` and/or `soap_wsse_sign` with `soap_wsse_sign_only` to sign the message.
7. Always check the function return values for errors. You don't want to produce and accept messages with an invalid Security headers.

## Signing Message Parts

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:

struct ns__myContract
{
@char* wsu__Id = "Contract";
char* name;
char* title;
char* terms;
};
int ns__myMethod(struct ns__myContract agreement, bool* accepted);

The default value of the wsu:Id is "Contract" so that we can instantiate the struct, automatically sign it, and send it as follows:

struct ns__myContract contract;
bool accept;
soap_default_ns__myContract(soap, &contract);
contract.name = ...;
contract.title = ...;
contract.terms = ...;
if (soap_wsse_add_BinarySecurityTokenX509(soap, "X509Token", cert)
|| soap_wsse_add_KeyInfo_SecurityTokenReferenceX509(soap, "#X509Token")
|| soap_wsse_sign(soap, SOAP_SMD_SIGN_RSA_SHA256, rsa_private_key, 0))
... // an error occurred
else if (soap_call_ns__myMethod(soap, contract, &accept))
... // a transmission error occurred

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:

soap_wsse_set_wsu_id(soap, "ns:myContract"); // <ns:myContract wsu:Id="ns:myContract">...
soap_wsse_set_InclusiveNamespaces(soap, "ns xsd"); // QNames have 'ns' and 'xsd' values
if (soap_wsse_add_BinarySecurityTokenX509(soap, "X509Token", cert)
|| soap_wsse_add_KeyInfo_SecurityTokenReferenceX509(soap, "#X509Token")
|| soap_wsse_sign(soap, SOAP_SMD_SIGN_RSA_SHA256, rsa_private_key, 0))
... // an error occurred
soap_wsse_set_wsu_id(soap, NULL); // reset
soap_wsse_set_InclusiveNamespaces(soap, NULL); // reset

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.

Note
  To reset the automatic wsu:Id attributes addition, pass NULL to `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).
  It is generally known that QName content of elements and attribute values may lead to verification issues with exclusive canonicalization (`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, "+")`.
  When signing parts of the body as outlined above, use `soap_wsse_sign` (do NOT use `soap_wsse_sign_body`).

Warning
  Do not attempt to sign an element with a wsu:Id that is a subelement of another element with a wsu:Id, that is, do not sign inner nested wsu:Id elements. The element that you will try to sign will not be canonicalized and will lead to a failure of the signature verification. When elements with wsu:Id are nested, sign the outermost element.

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):

#include "wsaapi.h"
#include "wsseapi.h"
soap_register_plugin(soap, soap_wsa);
soap_register_plugin(soap, soap_wsse);
...
soap_wsse_set_wsu_id(soap, "wsa5:From wsa5:To wsa5:ReplyTo wsa5:FaultTo wsa5:Action wsa5:MessageID");
if (soap_wsa_request(soap, RequestMessageID, ToAddress, RequestAction)
|| soap_wsa_add_From(soap, FromAddress) // optional: add a 'From' address
|| soap_wsa_add_FaultTo(soap, FaultToAddress))
... // error: out of memory
if (soap_wsse_add_BinarySecurityTokenX509(soap, "X509Token", cert)
|| soap_wsse_add_KeyInfo_SecurityTokenReferenceX509(soap, "#X509Token")
|| soap_wsse_sign_body(soap, SOAP_SMD_SIGN_RSA_SHA256, rsa_private_key, 0))
... // an error occurred
else if (soap_call_ns__myMethod(soap, ...))
... // a transmission error occurred
soap_wsse_set_wsu_id(soap, NULL);

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(soap, "wsa:From wsa:To wsa:ReplyTo wsa:FaultTo wsa:Action wsa:MessageID");

Note
  `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.

Warning
  Never use `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.

## Signing Security Headers and Tokens

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:

soap_wsse_add_Timestamp(soap, "Time", 600);
soap_wsse_add_UsernameTokenDigest(soap, "User", "username", "password");
... // the rest of the signing code

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:

soap_wsse_add_Timestamp(soap, "Time", 600);
soap_wsse_add_UsernameTokenDigest(soap, "User", "username", "password");
soap_wsse_add_BinarySecurityTokenX509(soap, "X509Token", cert);
soap_wsse_add_KeyInfo_SecurityTokenReferenceX509(soap, "#X509Token");
soap_wsse_sign_body(soap, SOAP_SMD_SIGN_RSA_SHA256, rsa_private_key, 0);
soap_wsse_sign_only(soap, "Time User Body"); // OK to use after soap_wsse_sign_body

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_wsa_request(soap, RequestMessageID, ToAddress, RequestAction);
soap_wsse_set_wsu_id(soap, "wsa5:To wsa5:From wsa5:ReplyTo wsa5:Action");
soap_wsse_add_UsernameTokenDigest(soap, "User", "username", "password");
soap_wsse_add_BinarySecurityTokenX509(soap, "X509Token", cert);
soap_wsse_add_KeyInfo_SecurityTokenReferenceX509(soap, "#X509Token");
soap_wsse_sign_body(soap, SOAP_SMD_SIGN_RSA_SHA256, rsa_private_key, 0);
soap_wsse_sign_only(soap, "wsa5:To wsa5:From wsa5:ReplyTo wsa5:Action User Body");

Note
  `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.
  To reset the filtering of signed tokens and elements, pass NULL to `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).

## Signature Validation

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:

struct soap *soap = soap_new1(SOAP_XML_CANONICAL);
soap_register_plugin(soap, soap_wsse);
soap_wsse_verify_auto(soap, SOAP_SMD_NONE, NULL, 0);
soap->cafile = "cacerts.pem"; // file with CA certs of peers
soap->capath = "dir/to/certs"; // and/or point to CA certs directory
soap->crlfile = "revoked.pem"; // use CRL (optional)
// server:
if (soap_serve(soap))
... // an error occurred
// client:
if (soap_call_ns__myMethod(soap, ...))
... // an error occurred

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:

soap_wsse_verify_auto(soap, SOAP_SMD_NONE, NULL, 0);
soap->cafile = "cacerts.pem"; // file with CA certs of peers
soap->capath = "dir/to/certs"; // and/or point to CA certs directory
soap->crlfile = "revoked.pem"; // use CRL (optional)
... // client call
if (soap_wsse_verify_element(soap, "namespaceURI", "tag") == 1)
... // only one element with matching tag and namespace is signed

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:

if (!soap_wsse_verify_Timestamp(soap))
{
soap_wsse_delete_Security(soap);
... // error
}
else if (soap_wsse_verify_element(soap, "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd", "Timestamp") > 0)
... // timestamp was signed

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:

static int ssl_verify(int ok, X509_STORE_CTX *store)
{
// put certificate verification here, return 0 when fails 1 when ok
return 1;
}
...
soap_wsse_verify_auto(soap, SOAP_SMD_NONE | SOAP_WSSE_IGNORE_EXTRA_REFS, NULL, 0);
soap->cafile = "cacerts.pem"; // file with CA certs of peers
soap->capath = "dir/to/certs"; // and/or point to CA certs directory
soap->crlfile = "revoked.pem"; // use CRL (optional)
soap->fsslverify = ssl_verify; // set certificate verification callback

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`):

static int ssl_verify(int ok, X509_STORE_CTX *store)
{
if (!ok)
{
char buf[1024];
int err = X509_STORE_CTX_get_error(store);
X509 *cert = X509_STORE_CTX_get_current_cert(store);
switch (err)
{
case X509_V_ERR_CERT_NOT_YET_VALID:
case X509_V_ERR_CERT_HAS_EXPIRED:
case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT:
case X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN:
case X509_V_ERR_UNABLE_TO_GET_CRL:
case X509_V_ERR_CRL_NOT_YET_VALID:
case X509_V_ERR_CRL_HAS_EXPIRED:
X509_STORE_CTX_set_error(store, X509_V_OK);
ok = 1;
break;
default:
fprintf(stderr, "SSL verify error %d or warning with certificate at depth %d: %s\n", err, X509_STORE_CTX_get_error_depth(store), X509_verify_cert_error_string(err));
X509_NAME_oneline(X509_get_issuer_name(cert), buf, sizeof(buf)-1);
fprintf(stderr, " certificate issuer: %s\n", buf);
X509_NAME_oneline(X509_get_subject_name(cert), buf, sizeof(buf)-1);
fprintf(stderr, " certificate subject: %s\n", buf);
}
}
return ok;
}
...
soap_wsse_verify_auto(soap, SOAP_SMD_NONE | SOAP_WSSE_IGNORE_EXTRA_REFS, NULL, 0);
soap->cafile = "cacerts.pem"; // file with CA certs of peers
soap->capath = "dir/to/certs"; // and/or point to CA certs directory
soap->crlfile = "revoked.pem"; // use CRL (optional)
soap->fsslverify = ssl_verify;

To verify the HMAC signature of an inbound message, the HMAC key must be supplied:

static char hmac_key[16] = // the same secret key that was used to sign
{ 0xff, 0xee, 0xdd, 0xcc, 0xbb, 0xaa, 0x99, 0x88,
0x77, 0x66, 0x55, 0x44, 0x33, 0x22, 0x11, 0x00 };
struct soap *soap = soap_new1(SOAP_XML_CANONICAL);
soap_register_plugin(soap, soap_wsse);
soap_wsse_verify_auto(soap, SOAP_SMD_HMAC_SHA1, hmac_key, sizeof(hmac_key));
soap->cafile = "cacerts.pem"; // file with CA certs of peers
soap->capath = "dir/to/certs"; // and/or point to CA certs directory
soap->crlfile = "revoked.pem"; // use CRL (optional)
// server:
if (soap_serve(soap))
... // an error occurred
// client:
if (soap_call_ns__myMethod(soap, ...))
... // an error occurred

To summarize the signature verification process:

1. Register the wsse plugin.
2. For HMAC, obtain the HMAC secret key
3. Use `soap_wsse_verify_auto` to verify inbound messages.
4. Set the cafile (or capath) to verify certificates of the peers and crlfile (optional)
5. After receiving a message, the DOM in soap->dom can be traversed for further analysis.
6. Always check the function return values for errors. You don't want to accept a request or response message with an invalid Security header.
7. Use `soap_wsse_verify_done` to terminate verification, e.g. to consume plain messages more efficiently.

# Encryption

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:

struct soap *soap = soap_new1(SOAP_XML_CANONICAL);
soap_register_plugin(soap, soap_wsse);

To send messages with inclusive canonicalization, in addition to the `SOAP_XML_CANONICAL` flag also use:

soap_wsse_set_InclusiveNamespaces(soap, "*");

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).

Warning
  Interoperability with WCF WS-Security is not guaranteed when `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.

## Encrypting Messages

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:

X509 *cert = ...; // from PEM file or local secure store as shown above
if (soap_wsse_add_EncryptedKey(soap, SOAP_MEC_ENV_ENC_DES_CBC, "Cert", cert, NULL, NULL, NULL))
soap_print_fault(soap, stderr);

`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 CBC
- `SOAP_MEC_ENV_ENC_AES256_CBC` RSA-1_5 envelope encryption with AES256 CBC
- `SOAP_MEC_ENV_ENC_AES256_GCM` envelope authenticated encryption with AES256 GCM
- `SOAP_MEC_ENV_ENC_AES256_CBC | SOAP_MEC_OAEP` OAEP envelope encryption with AES256 CBC

where, 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:

X509 *cert = ...; // from PEM file or local secure store as shown above
if (soap_wsse_add_EncryptedKey(soap, SOAP_MEC_ENV_ENC_DES_CBC, "Cert", cert, "Subject Key ID", NULL, NULL))
soap_print_fault(soap, stderr);

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:

X509 *cert = ...; // from PEM file or local secure store as shown above
if (soap_wsse_add_EncryptedKey(soap, SOAP_MEC_ENV_ENC_DES_CBC, "Cert", cert, NULL, "CN=Root Agency", "-79441640260855276448009124614332182350"))
soap_print_fault(soap, stderr);

The issuer name and serial number (must be in decimal for `soap_wsse_add_EncryptedKey`) of a certificate can be obtained as follows:

X509 *cert = ...; // from PEM file or local secure store as shown above
BIGNUM *bn = BN_new();
char issuer[256], *serial;
X509_NAME_oneline(X509_get_issuer_name(cert), issuer, sizeof(issuer)-1);
ASN1_INTEGER_to_BN(X509_get_serialNumber(cert), bn);
serial = BN_bn2dec(bn);
OPENSSL_free(bn);
...
if (soap_wsse_add_EncryptedKey(soap, SOAP_MEC_ENV_ENC_DES_CBC, "Cert", cert, NULL, issuer+1, serial))
soap_print_fault(soap, stderr);
...
OPENSSL_free(serial);

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:

X509 *cert = ...; // from PEM file or local secure store as shown above
// the SOAP Body contains one <ns:myContract> and one <ns:myPIN> (not nested)
soap_wsse_set_wsu_id(soap, "ns:myContract ns:myPIN");
if (soap_wsse_add_EncryptedKey_encrypt_only(soap, SOAP_MEC_ENV_ENC_DES_CBC, "Cert", cert, NULL, NULL, NULL, "ds:Signature ns:myContract ns:myPIN"))
soap_print_fault(soap, stderr);

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:

X509 *cert = ...; // from PEM file or local secure store as shown above
if (soap_wsse_add_EncryptedKey_encrypt_only(soap, SOAP_MEC_ENV_ENC_DES_CBC, "Cert", cert, NULL, NULL, NULL, "ds:Signature SOAP-ENV:Body"))
soap_print_fault(soap, stderr);

This means that you should not combine `soap_wsse_encrypt_body` with `soap_wsse_encrypt_only` to encrypt the SOAP Body.

Note
  The `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`.
  The elements identified by the tag names in `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:

char des_key[20] = ...; // 20-byte (160-bit) DES shared secret key
if (soap_wsse_encrypt_body(soap, SOAP_MEC_ENC_DES_CBC, des_key, sizeof(des_key)))
soap_print_fault(soap, stderr);

The symmetric encryption options are:

- `SOAP_MEC_ENC_DES_CBC` symmetric encryption with triple DES CBC
- `SOAP_MEC_ENC_AES256_CBC` symmetric encryption with AES256 CBC
- `SOAP_MEC_ENC_AES256_GCM` symmetric authenticated encryption with AES256 GCM

where, in the above, AES256 can also be replaced with AES128 or AES192.

For example, symmetric encryption with AES256:

char aes256_key[32] = ...; // 32-byte (256-bit) AES256 shared secret key
if (soap_wsse_encrypt_body(soap, SOAP_MEC_ENC_AES256_CBC, aes256_key, sizeof(aes256_key)))
soap_print_fault(soap, stderr);

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:

char des_key[20] = ...; // 20-byte (160-bit) secret key
// the SOAP Body contains one <ns:myContract> and one <ns:myPIN> (not nested)
soap_wsse_set_wsu_id(soap, "ns:myContract ns:myPIN");
if (soap_wsse_encrypt_only(soap, SOAP_MEC_ENC_DES_CBC, des_key, sizeof(des_key), "ds:Signature ns:myContract ns:myPIN"))
soap_print_fault(soap, stderr);

Note
  The `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).
  The elements identified by the tag names in `soap_wsse_set_wsu_id` to encrypt MUST occur EXACTLY ONCE in the SOAP Body.

## Decrypting Message Parts

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:

soap_register_plugin_arg(soap, soap_wsse);
soap_wsse_set_security_token_handler(soap, security_token_handler);
const void *security_token_handler(struct soap *soap, int *alg, const char *keyname, const unsigned char *keyid, int keyidlen, int *keylen)
{
// Get the user name from UsernameToken in message
const char *uid = soap_wsse_get_Username(soap);
switch (*alg)
{
case SOAP_SMD_VRFY_DSA_SHA1:
case SOAP_SMD_VRFY_DSA_SHA256:
case SOAP_SMD_VRFY_RSA_SHA1:
case SOAP_SMD_VRFY_RSA_SHA224:
case SOAP_SMD_VRFY_RSA_SHA256:
case SOAP_SMD_VRFY_RSA_SHA384:
case SOAP_SMD_VRFY_RSA_SHA512:
case SOAP_SMD_VRFY_ECDSA_SHA1:
case SOAP_SMD_VRFY_ECDSA_SHA224:
case SOAP_SMD_VRFY_ECDSA_SHA256:
case SOAP_SMD_VRFY_ECDSA_SHA384:
case SOAP_SMD_VRFY_ECDSA_SHA512:
if (uid)
{
// Lookup uid to retrieve the X509 certificate to verify the signature
const X509 *cert = ...;
return (const void*)cert;
}
break;
case SOAP_SMD_HMAC_SHA1:
case SOAP_SMD_HMAC_SHA224:
case SOAP_SMD_HMAC_SHA256:
case SOAP_SMD_HMAC_SHA384:
case SOAP_SMD_HMAC_SHA512:
if (uid)
{
// Lookup uid to retrieve the HMAC SHA key to verify the signature
const void *key = ...;
*alg = ...;
*keylen = ...;
return key;
}
return NULL; // no certificate: fail
case SOAP_MEC_ENV_DEC_DES_CBC:
case SOAP_MEC_ENV_DEC_AES128_CBC:
case SOAP_MEC_ENV_DEC_AES192_CBC:
case SOAP_MEC_ENV_DEC_AES256_CBC:
case SOAP_MEC_ENV_DEC_AES512_CBC: // reserved for future use
case SOAP_MEC_ENV_DEC_AES128_GCM: // GCM requires OpenSSL 1.0.2 or higher
case SOAP_MEC_ENV_DEC_AES192_GCM: // GCM requires OpenSSL 1.0.2 or higher
case SOAP_MEC_ENV_DEC_AES256_GCM: // GCM requires OpenSSL 1.0.2 or higher
case SOAP_MEC_ENV_DEC_AES512_GCM: // GCM requires OpenSSL 1.0.2 or higher
if (keyname)
{
// use this to get the key or certificate from a key store using the keyname value:
// 1. keyname is set to the subject name of the certificate, if a
// certificate is present in the SecurityTokenReference/KeyIdentifier
// when ValueType is http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3
// 2. keyname is set to the string concatenation
// "{X509IssuerName}#{X509SerialNumber}" of the X509IssuerName
// and X509SerialNumber present in X509Data/X509IssuerSerial
// 3. keyname is set to X509Data/X509SubjectName
return ...;
}
else if (keyid)
{
// use this to get the key from a key store using the keyid[0..keyidlen-1]:
// 1. keyid and keyidlen are set to the data in
// SecurityTokenReference/KeyIdentifier when the ValueType is
// http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier
return ...;
}
break;
case SOAP_MEC_DEC_DES_CBC:
case SOAP_MEC_DEC_AES128_CBC:
case SOAP_MEC_DEC_AES192_CBC:
case SOAP_MEC_DEC_AES256_CBC:
case SOAP_MEC_DEC_AES512_CBC: // reserved for future use
case SOAP_MEC_DEC_AES128_GCM: // GCM requires OpenSSL 1.0.2 or higher
case SOAP_MEC_DEC_AES192_GCM: // GCM requires OpenSSL 1.0.2 or higher
case SOAP_MEC_DEC_AES256_GCM: // GCM requires OpenSSL 1.0.2 or higher`
case SOAP_MEC_DEC_AES512_GCM: // GCM requires OpenSSL 1.0.2 or higher
if (keyname)
{
// use the keyname to get the shared secret key associated for decryption
*keylen = ... // length of the shared secret key
return ...;
}
break;
}
return NULL; // fail
}

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.

Warning
  The security token handler callback function parameters have changed in 2.8.34 and greater with the addition of KeyIdentifier information `keyid` and `keyidlen`.

To set the default private key for envelope decryption, use:

EVP_PKEY *rsa_private_key = ...;
soap_wsse_decrypt_auto(soap, SOAP_MEC_ENV_DEC_DES_CBC, rsa_private_key, 0);

The envelope decryption options are:

- `SOAP_MEC_ENV_DEC_DES_CBC` RSA-1_5 envelope decryption with triple DES CBC
- `SOAP_MEC_ENV_DEC_AES256_CBC` RSA-1_5 envelope decryption with AES256 CBC
- `SOAP_MEC_ENV_DEC_AES256_GCM` envelope authenticated decryption with AES256 GCM
- `SOAP_MEC_ENV_DEC_AES256_CBC | SOAP_MEC_OAEP` OAEP envelope decryption with AES256 CBC

where, in the above, AES256 can be replaced with AES128 or AES192.

To set the default shared secret key for symmetric decryption, use:

char des_key[20] = ...; // 20-byte (160-bit) triple DES key
soap_wsse_decrypt_auto(soap, SOAP_MEC_DEC_DES_CBC, des_key, sizeof(des_key));

The symmetric decryption options are:

- `SOAP_MEC_DEC_DES_CBC` symmetric decryption with triple DES CBC
- `SOAP_MEC_DEC_AES256_CBC` symmetric decryption with AES256 CBC
- `SOAP_MEC_DEC_AES256_GCM` symmetric authenticated decryption with AES256 GCM

where, in the above, AES256 can be replaced with AES128 or AES192.

For example, symmetric decryption with AES256:

char aes256_key[32] = ...; // 32-byte (256-bit) AES256 key
soap_wsse_decrypt_auto(soap, SOAP_MEC_DEC_AES256_CBC, aes256_key, sizeof(aes256_key));

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:

soap_wsse_decrypt_auto(soap, SOAP_MEC_NONE, NULL, 0);

## Example Client and Server

The code for a client is shown below that uses signatures and encryption:

FILE *fd;
EVP_PKEY *rsa_private_key;
X509 *cert;
// create new context with recommended C14N enabled
struct soap *soap = soap_new1(SOAP_XML_CANONICAL);
// register the plugin(s)
soap_register_plugin(soap, soap_wsse);
// enable peer certificate verification
soap->cafile = "cacerts.pem"; // file with CA certs of peers
soap->capath = "dir/to/certs"; // and/or point to CA certs directory
soap->crlfile = "revoked.pem"; // use CRL (optional)
soap->fsslverify = ssl_verify; // optional, a callback to verify peer certificates
// get the private key for signing and decryption
fd = fopen("privkey.pem", "r");
rsa_private_key = PEM_read_PrivateKey(fd, NULL, NULL, "password");
fclose(fd);
// get the certificate to include in the security header
fd = fopen("cert.pem", "r");
X509 *cert = PEM_read_X509(fd, NULL, NULL, NULL);
fclose(fd);
// enable decryption with the private key
soap_wsse_decrypt_auto(soap, SOAP_MEC_ENV_DEC_DES_CBC, rsa_private_key, 0);
// enable signature verification
soap_wsse_verify_auto(soap, SOAP_SMD_NONE, NULL, 0);
// add the certificate X509 token and token reference, sign the Body using the private key
if (soap_wsse_add_BinarySecurityTokenX509(soap, "X509Token", cert)
|| soap_wsse_add_KeyInfo_SecurityTokenReferenceX509(soap, "#X509Token")
|| soap_wsse_sign_body(soap, SOAP_SMD_SIGN_RSA_SHA256, rsa_private_key, 0))
... // an error occurred
// encrypt the Body and the signature using the public key in cert (the cert of the peer loaded from PEM)
soap_wsse_set_wsu_id(soap, "ds:Signature");
if (soap_wsse_add_EncryptedKey_encrypt_only(soap, SOAP_MEC_ENV_ENC_DES_CBC, "Cert", cert, NULL, NULL, NULL, "ds:Signature SOAP-ENV:Body"))
... // an error occurred
if (soap_call_ns__myMethod(soap, ...))
... // a transmission error occurred
...
EVP_PKEY_free(rsa_private_key);
X509_free(cert);

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:

EVP_PKEY *rsa_private_key; // OK to declare global
X509 *cert; // OK to declare global
..
FILE *fd;
// create new context with recommended C14N enabled
struct soap *soap = soap_new1(SOAP_XML_CANONICAL);
// register the plugin(s)
soap_register_plugin(soap, soap_wsse);
// enable peer certificate verification
soap->cafile = "cacerts.pem"; // file with CA certs of peers
soap->capath = "dir/to/certs"; // and/or point to CA certs directory
soap->crlfile = "revoked.pem"; // use CRL (optional)
soap->fsslverify = ssl_verify; // optional, a callback to verify peer certificates
// get the private key for signing and decryption
fd = fopen("privkey.pem", "r");
rsa_private_key = PEM_read_PrivateKey(fd, NULL, NULL, "password");
fclose(fd);
// get the certificate to include in the security header
fd = fopen("cert.pem", "r");
X509 *cert = PEM_read_X509(fd, NULL, NULL, NULL);
fclose(fd);
...
if (!soap_valid_socket(soap_bind(soap, NULL, port, 100)))
... // an error occurred
while (soap_valid_socket(soap_accept(soap)))
{
// enable signature verification
soap_wsse_verify_auto(soap, SOAP_SMD_NONE, NULL, 0);
// enable decryption with the private key
soap_wsse_decrypt_auto(soap, SOAP_MEC_ENV_DEC_DES_CBC, rsa_private_key, 0);
// serve one request
if (soap_serve(soap))
{
soap_wsse_delete_Security(soap);
soap_print_fault(soap, stderr);
}
}
...
EVP_PKEY_free(rsa_private_key);
X509_free(cert);

where an example service operation could be:

int ns__myMethod(struct soap *soap, ...)
{
...
// remove old security headers
soap_wsse_delete_Security(soap);
// encrypt the Body and the signature using the public key in cert (the cert of the peer loaded from PEM)
soap_wsse_set_wsu_id(soap, "ds:Signature");
// add the certificate X509 token and token reference, sign the Body using the private key
// encrypt the Body and the signature using the public key in cert (the cert of the peer loaded from PEM)
if (soap_wsse_add_BinarySecurityTokenX509(soap, "X509Token", cert)
|| soap_wsse_add_KeyInfo_SecurityTokenReferenceX509(soap, "#X509Token")
|| soap_wsse_sign_body(soap, SOAP_SMD_SIGN_RSA_SHA256, rsa_private_key, 0)
|| soap_wsse_add_EncryptedKey_encrypt_only(soap, SOAP_MEC_ENV_ENC_DES_CBC, "Cert", cert, NULL, NULL, NULL, "ds:Signature SOAP-ENV:Body"))
{
soap_wsse_delete_Security(soap); // remove incomplete security headers
return soap->error;
}
return SOAP_OK;
}

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:

struct soap *soap = soap_new1(SOAP_XML_CANONICAL | SOAP_IO_KEEPALIVE);
soap_register_plugin(soap, soap_wsse);
...
soap->fserveloop = set_verify_decrypt_auto;
...
while (soap_valid_socket(soap_accept(soap)))
{
set_verify_decrypt_auto(soap);
// serve multiple requests (when keep alive)
if (soap_serve(soap))
{
soap_wsse_delete_Security(soap);
soap_print_fault(soap, stderr);
}
}
int set_verify_decrypt_auto(struct soap *soap)
{
// enable signature verification
soap_wsse_verify_auto(soap, SOAP_SMD_NONE, NULL, 0);
// enable decryption with the private key
soap_wsse_decrypt_auto(soap, SOAP_MEC_ENV_DEC_DES_CBC, rsa_private_key, 0);
return SOAP_OK;
}

# Security Timestamps

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:

soap_wsse_add_Timestamp(soap, NULL, 0); // 0 means no expiration

The lifetime of a message (in seconds) is passed as the third argument, which will be displayed as the timestamp expiration time:

soap_wsse_add_Timestamp(soap, NULL, 10); // 10 seconds lifetime

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:

soap_wsse_add_Timestamp(soap, "Time", 10); // timestamp will be signed

After receiving a message, the receiver can verify the presence and validity of the timestamp and whether it was signed with:

if (!soap_wsse_verify_Timestamp(soap))
{
soap_wsse_delete_Security(soap);
... // error, no timestamp or timestamp has expired
}
else if (soap_wsse_verify_element(soap, "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd", "Timestamp") > 0)
... // timestamp was signed

# WS-Security and HTTPS

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:

#include "wsseapi.h"
#include "threads.h"
struct soap *soap;
if (CRYPTO_thread_setup())
... // error
soap = soap_new1(SOAP_XML_CANONICAL);
soap_register_plugin(soap, soap_wsse);
if (soap_ssl_client_context(&soap,
SOAP_SSL_DEFAULT, // requires server authentication
NULL, // keyfile for client authentication to server
NULL, // the keyfile password
"cacerts.pem", // cafile CA certificates to authenticate the server
NULL, // capath CA directory path to certificates
NULL
))
... // error
soap->cafile = "cacerts.pem"; // same as above (or overrides the above)
soap->capath = "dir/to/certs"; // and/or point to CA certs
soap->crlfile = "revoked.pem"; // use CRL (optional)
... // set up WS-Security for signatures/encryption etc
if (soap_call_ns__myMethod(soap, "https://...", ...))
... // error
... // process response results
soap_destroy(soap);
soap_end(soap);
soap_free(soap);
CRYPTO_thread_cleanup();

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 used
- `SOAP_SSL_NO_AUTHENTICATION` disables server authentication
- `SOAP_SSL_SKIP_HOST_CHECK` disables server authentication host check
- `SOAP_SSL_ALLOW_EXPIRED_CERTIFICATE` to accept self-signed certificates, expired certificates, and certificates without CRL.

The server uses the following:

#include "wsseapi.h"
#include "threads.h"
SOAP_SOCKET m, s;
int port = 443;
struct soap *soap;
if (CRYPTO_thread_setup())
... // error
soap = soap_new1(SOAP_XML_CANONICAL);
soap_register_plugin(soap, soap_wsse);
if (soap_ssl_server_context(&soap,
SOAP_SSL_DEFAULT, // requires server to authenticate, but not the client
server.pem, // keyfile for authentication to client
"password", // the keyfile password
NULL, // CA certificates to authenticate the client
NULL, // CA directory path to certificates
NULL, // use RSA 2048 bits (or give file name with DH param)
NULL,
NULL
))
... // error
if (!soap_valid_socket(m = soap_bind(soap, NULL, port, 100))
... // error
for (;;)
{
if (!soap_valid_socket(s = soap_accept(soap)))
... // error
else
{
struct soap *tsoap = soap_copy(soap);
while (THREAD_CREATE(&tid, (void*(*)(void*))&process_request, (void*)tsoap))
sleep(1);
}
}
soap_destroy(soap);
soap_end(soap);
soap_free(soap);
CRYPTO_thread_cleanup();

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):

void *process_request(struct soap *soap)
{
... // set up WS-Security for signatures/encryption etc
if (soap_ssl_accept(soap)
|| soap_serve(soap))
... // error
soap_destroy(soap);
soap_end(soap);
soap_free(soap);
}

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 authentication
- `SOAP_SSL_REQUIRE_CLIENT_AUTHENTICATION` requires client authentication

We also should implement the mutex setup and cleanup operations as follows:

struct CRYPTO_dynlock_value
{
MUTEX_TYPE mutex;
};
static MUTEX_TYPE *mutex_buf;
static struct CRYPTO_dynlock_value *dyn_create_function(const char *file, int line)
{
struct CRYPTO_dynlock_value *value;
value = (struct CRYPTO_dynlock_value*)malloc(sizeof(struct CRYPTO_dynlock_value));
if (value)
MUTEX_SETUP(value->mutex);
return value;
}
static void dyn_lock_function(int mode, struct CRYPTO_dynlock_value *l, const char *file, int line)
{
if (mode & CRYPTO_LOCK)
MUTEX_LOCK(l->mutex);
else
MUTEX_UNLOCK(l->mutex);
}
static void dyn_destroy_function(struct CRYPTO_dynlock_value *l, const char *file, int line)
{
MUTEX_CLEANUP(l->mutex);
free(l);
}
void locking_function(int mode, int n, const char *file, int line)
{
if (mode & CRYPTO_LOCK)
MUTEX_LOCK(mutex_buf[n]);
else
MUTEX_UNLOCK(mutex_buf[n]);
}
unsigned long id_function()
{
return (unsigned long)THREAD_ID;
}
int CRYPTO_thread_setup()
{
int i;
mutex_buf = (MUTEX_TYPE*)malloc(CRYPTO_num_locks() * sizeof(pthread_mutex_t));
if (!mutex_buf)
return SOAP_EOM;
for (i = 0; i < CRYPTO_num_locks(); i++)
MUTEX_SETUP(mutex_buf[i]);
CRYPTO_set_id_callback(id_function);
CRYPTO_set_locking_callback(locking_function);
CRYPTO_set_dynlock_create_callback(dyn_create_function);
CRYPTO_set_dynlock_lock_callback(dyn_lock_function);
CRYPTO_set_dynlock_destroy_callback(dyn_destroy_function);
return SOAP_OK;
}
void CRYPTO_thread_cleanup()
{
int i;
if (!mutex_buf)
return;
CRYPTO_set_id_callback(NULL);
CRYPTO_set_locking_callback(NULL);
CRYPTO_set_dynlock_create_callback(NULL);
CRYPTO_set_dynlock_lock_callback(NULL);
CRYPTO_set_dynlock_destroy_callback(NULL);
for (i = 0; i < CRYPTO_num_locks(); i++)
MUTEX_CLEANUP(mutex_buf[i]);
free(mutex_buf);
mutex_buf = NULL;
}

For additional details and examples, see the user guide and examples in the gSOAP package directory gsoap/samples/ssl.

# Miscellaneous

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:

typedef struct _wsse__Security
{ struct _wsu__Timestamp* wsu__Timestamp;
struct _wsse__UsernameToken* UsernameToken;
struct _wsse__BinarySecurityToken* BinarySecurityToken;
struct xenc__EncryptedKeyType* xenc__EncryptedKey;
struct _xenc__ReferenceList* xenc__ReferenceList;
struct ds__SignatureType* ds__Signature;
@char* SOAP_ENV__actor;
@char* SOAP_ENV__role;
} _wsse__Security;

The `_wsse__Security` header is modified by a WS/WS-typemap.dat mapping rule to include additional details.

# Limitations and Security Considerations

- Encryption of simple content (CDATA content) directly with `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.
- Encryption is performed after signing (likewise, signatures are verified after decryption). Signing after encryption is not supported in the current plugin release. It is generally known that it is safer to perform encryption after signing as the wsse plugin performs, and 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. To this end, use `soap_wsse_add_EncryptedKey_encrypt_only(..., "ds:Signature SOAP-ENV:Body")`.
- Signing and encrypting XML containing QName content may lead to verification issues, because the W3C C14N exclusive canonicalization protocol has known limitations with QName content normalization. In fact, not signing the prefix bindings as in C14N exclusive canonicalization is a security risk, because the prefix-URI binding can be modified when placed at an ancestor node that is not included in the signed XML content. Use `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.

# Defending Against Signature Wrapping Attacks

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).

# WS-SecureConversation and WS-Trust

To use a WS-SecureConversation security context token (SCT) with WS-Security:

const char *identifier = "...";
soap_wsse_add_SecurityContextToken(soap, "SCT", identifier);

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`:

int psha1len = 32; // or greater
int n, m;
const char *client_secret = soap_base642s(soap, client_secret_base64, NULL, 0, &n);
const char *server_secret = soap_base642s(soap, server_secret_base64, NULL, 0, &m);
char psha1[psha1len];
char *psha1_base64;
if (soap_psha1(soap, client_secret, n, server_secret, m, psha1, psha1len))
.. error // insufficient memory
psha1_base64 = soap_s2base64(soap, (unsigned char*)psha1, NULL, psha1len);

Similarly, PSHA256 can be computed by calling `soap_psha256()`.