With Blueriq it is possible to add security to you web services, but before choosing which type of web service you use it is good to keep in mind which benefits and drawbacks they have.
Web service security layers
Security comes in three layers, which are stacked upon each other.
| Message Layer | Message Layer security is a security layer which adds to possibility to send and receive encrypted and signed messages. |
| Application Layer | Application Layer Security is security which can be configured in your application. Blueriq Model Security
Blueriq Runtime Security
Blueriq out-of-the box also adds several application security risks mitigations by default, which will be explained in either the SOAP or REST web services. |
| Transport Layer | Transport Layer Security(TLS), is designed to provide security at the transport layer, with Blueriq web services this would mean configuring your webservices to use HTTPS when communicating with 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.
- See Schema set editor on how to add validation to your model.
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.
- Cache-Control: Do not allow sensitive data to be cache
- Content-Type: Expect certain content types.
- Strict-Transport-Security: Enforce a secure transport layer
- 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).
- See REST Security on how to configure your message layer security.
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.
Overview
Content Tools