...

Web service security layers

Security comes in three layers, which are stacked upon each other. 

SOAP web services

Transport Layer

Secure incoming messages

Transport Layer security can be configured in your application server and the Blueriq Runtime itself.
When hosting the Blueriq Runtime on a application server that is configured to only accept HTTPS request, the incoming SOAP requests are secured.

• See Security: Application Servers on enable security for you application server.

Secure outgoing messages

In the Blueriq Runtime itself you must configure your outgoing to requests.
By configuring your connections URLs to use the HTTPS protocol you outgoing SOAP requests are secured. 

• See Connections Properties on how configure you connections URLs.

Application Layer

For the Application Layer the following security measures should be configured in Blueriq: 

Access control, who can access the SOAP web service 

Configurable in Blueriq, via authentication and authorization

• See Security: Blueriq as a Service on how to configure authorization and authentication on your web service.

Input Validation, add validations to your incoming model 

Input validations can be directly modelled in your Blueriq application, when mapping a schema set to your domain model you have to option to set validation rules.

...

Note: Most of the security is handled in the transport or message Layer, as SOAP requests are POST requests and only allow XML content. A lot of the Security mitigations which are needed for REST services does not apply on SOAP services.

Message Layer

In Blueriq we use the WS-Security standards to add the options to encrypt and sign your SOAP messages. This can be configured for incoming and outgoing requests.

• See WS-Security on how to configure your message layer security

REST web services

Transport Layer

Secure incoming messages

Transport Layer security can be configured in your application server and the Blueriq Runtime itself. When hosting the Blueriq Runtime in a application server that is configured to only accept HTTPS request, the incoming REST requests are secured.

• See Security: Application Servers on enable security for you application server.

Secure outgoing messages

In the Blueriq Runtime itself you must configure your outgoing to requests. By configuring your connections URLs to use the HTTPS protocol you outgoing REST requests are secured.

• See Connections Properties on how configure you connections URLs.

Application Layer

For the Application Layer the following security measures should be configured in Blueriq.

Access control, who can access the REST service 

Configurable in Blueriq, via authentication and authorization

• See Security: Blueriq as a Service on how to configure authorization and authentication on your web service.

Using JWT tokens when giving out security tokens 

This can be achieved by using OpenID Connect as authentication provider.

• See OpenID Connect on how to configure OpenID Connect for your REST web services

Restrict HTTP methods, return an error when an incorrect HTTP is used 

Incorrect use of HTTP methods is mitigated by Blueriq, when an incorrect HTTP to a REST web service Blueriq will return an error and not process the message. 

We also support active HTTP method blocking.

Input Validation, add validations to your incoming model 

Input validations can be directly modelled in your Blueriq application, when creating a domain schema you have to option to set validation rules.

• See Domain schema editor on how to add validation to your model.

Validate Content Types 

Blueriq verifies whether the message can be parsed for the content type it receives.

Setup Security Header 

When modelling your REST web services you have the option to add Headers to your request with default values. 

...

• See Security for additonal security properties which can be configured in Blueriq
• See REST service editor to configure http headers in your Blueriq model

Message Layer

Since Blueriq 16.8, Blueriq supports Message Layer security for REST web services. Blueriq implements Message Layer Security in the form of Javascript Object Signing and Encryption (JOSE).

...

Prior to Blueriq 16.8, Blueriq did not support Message Layer Security for REST web services.

Using web services in different landscapes

When choosing the type of web services you use in your landscape, it is key to validate whether a REST or SOAP web service is the best fit for your scenario. Instead of always using SOAP services or REST services because you are used to doing so.

REST benefits

• Smaller learning curve
• Efficient, due to smaller message formats like JSON
• Free format

SOAP benefits

• Standardized message structure
• Built-in error handling
• Standardized security protocols
• Fixed contracts

Scenario 1: Non confidential data

When working with non confidential data, you can opt for REST as the type for your web services. Since it is not a security risk, when your data is read by a party which is not meant to read the data. By using REST web services over a secured transport layer you mitigate the risk of data being intercepted and read while it is in transport from one service to another.

Scenario 2: Highly confidential data

When working with highly confidential data, you should opt for SOAP as the type for you web services. While the communication in the transport layer is covered with REST with highly confidential data you also want to cover the message layer security.

Scenario 3: Untrusted third party mediator

When working with an untrusted third party mediator can opt to choose for a hybrid solution. While communicating with a third party mediator you should use secured SOAP web services to be certain that only the end user may read the message's contents. In your own infrastructure can you opt to choose for REST web services as risk of exposure is less likely, when the transport and application layer security is configured.

...