Page History

Configuration for BAAS SOAP services

Since Blueriq 14.9 you can configure SOAP services that are exposed as BAAS can be configured to verify WS-Security information of an incoming SOAP message and apply WS-Security profiles on the outgoing response.

Endpoint group configuration

Incoming SOAP messages can be processed using interceptors, which have to be configured per endpoint groups. Endpoint groups allow you to apply different WS-Security processing for different webservices and/or SOAP-Actions, which may be desirable if only a subset of endpoints have to apply a certain interceptor.

Endpoint groups have to be configured in property files as lists. The list enables you to configure multiple endpoint groups, where each endpoint group is matched in order: the first endpoint that matches an incoming message is used to determine the set of interceptors that are being used. Each endpoint group can specify the name(s) of webservices and/or soap-actions for which it should be activated. It is allowed to omit either or both of these properties, enabling you to activate the endpoint for all messages, all messages for certain webservices or all messages with certain SOAP-Action.

For example, the following configuration defines four endpoint groups, with the last group acting as a catch-all condition.

blueriq.baas.soap.endpoints[0].webservices=MySoapService,MySoapService2
blueriq.baas.soap.endpoints[0].soap-actions=MyAction,MyAction2
blueriq.baas.soap.endpoints[0].interceptors=MyInterceptor1,MyInterceptor2

blueriq.baas.soap.endpoints[1].soap-actions=MyAction
blueriq.baas.soap.endpoints[1].interceptors=MyInterceptor1

blueriq.baas.soap.endpoints[2].webservices=MySoapService
blueriq.baas.soap.endpoints[2].interceptors=MyInterceptor2

blueriq.baas.soap.endpoints[3].interceptors=DefaultInterceptor

Registering an interceptor

An interceptor has to be registered by name using properties, as follows:

blueriq.baas.soap.interceptors.security.MyInterceptorName.request.accept-unsecured-messages=false
blueriq.baas.soap.interceptors.security.MyInterceptorName.request.decryption.enabled=false
blueriq.baas.soap.interceptors.security.MyInterceptorName.request.signature.enabled=false
blueriq.baas.soap.interceptors.security.MyInterceptorName.request.timestamp.enabled=false
blueriq.baas.soap.interceptors.security.MyInterceptorName.response.encryption.enabled=false
blueriq.baas.soap.interceptors.security.MyInterceptorName.response.signature.enabled=false
blueriq.baas.soap.interceptors.security.MyInterceptorName.response.timestamp.enabled=false

In the above example you can see how each WS-Security profile can be enabled/disabled. A profile is disabled by default, so the above enabled  properties are redundant and are only shown to clarify the configuration. Properties that are marked as

General properties

Encryption/Decryption

http://www.w3.org/2001/04/xmlenc#aes128-cbc

Signing

UsernameToken*

* The UsernameToken profile cannot be configured together with signatures, as the signing key would conflict with the username. If both signing and the UsernameToken profile is needed then separate interceptors have to be configured and registered for the endpoint.

Timestamp

Anchor

client-configuration client-configuration

Configuration for AQ_SoapServiceClient

The configuration of AQ_SoapServiceClient allows for the exact same properties as documented above for BAAS webservices, however the request and response properties have been swapped.

Connection configuration

Security interceptors can be configured on a per-connection basis as described in the SOAP Connections Properties.

Registering an interceptor

An interceptor has to be registered by name using properties, as follows:

blueriq.soap.interceptors.security.MyInterceptorName.request.encryption.enabled=false
blueriq.soap.interceptors.security.MyInterceptorName.request.signature.enabled=false
blueriq.soap.interceptors.security.MyInterceptorName.request.timestamp.enabled=false
blueriq.soap.interceptors.security.MyInterceptorName.response.accept-unsecured-messages=false
blueriq.soap.interceptors.security.MyInterceptorName.response.decryption.enabled=false
blueriq.soap.interceptors.security.MyInterceptorName.response.signature.enabled=false
blueriq.soap.interceptors.security.MyInterceptorName.response.timestamp.enabled=false

In the above example you can see how each WS-Security profile can be enabled/disabled. A profile is disabled by default, so the above enabled  properties are redundant and are only shown to clarify the configuration. Properties that are marked as

General properties

Encryption/Decryption

http://www.w3.org/2001/04/xmlenc#aes128-cbc

Signing

UsernameToken*

* The UsernameToken profile cannot be configured together with signatures, as the signing key would conflict with the username. If both signing and the UsernameToken profile is needed then separate interceptors have to be configured and registered for the service call.

Timestamp

Anchor
keystore-configuration keystore-configuration

Keystore configuration

Since WS-Security is based on symmetric cryptography operations, a public/private key pair is used to encrypt/decrypt and to perform signing and signature validation. These keys have to be stored in a keystore in JKS format (Java KeyStore, .jks extension) or PKCS #12 format (.p12 extension) , which has to be configured as follows:

blueriq.security.keystore.location=file://client.jks
blueriq.security.keystore.password=

Anchor
parts-configuration parts-configuration

Parts configuration

Some WS-Security aspects can be applied to only a subset of the message. The relevant profiles provide a parts  property to configure this, which requires the following syntax:

• multiple part configurations must be separated by a semi-colon

• each value may be preceded by a mode specifier, either {Content} or {Element}. If not specified it defaults to {Content}

• the mode specifier may be followed by a namespace specifier. If omitted, it defaults to the SOAP namespace.

• the value must contain the name of the element which must be encrypted

For example, the value {Content}{http://example.org/paymentv2}CreditCard;{Element}{None}Username has the following meaning:

• the content of the CreditCard element in the http://example.org/paymentv2 namespace will be encrypted. The CreditCard element itself is not encrypted, so any attributes on this element will be in plain text 
• the Username element with no namespace is encrypted. The element itself is also encrypted, so any attributes will not be visible in plain text.