Colruyt Group

As a result of this evaluation, Colruyt started with two brand new initiatives:

• The Web Service Security project, which was all about exposing & consuming secured web services.
• The Authentication project, which was all about making a shift towards modern end-user authentication and access control.

Colruyt’s focus point was mainly required on the Authentication and Authorization aspects.

Defining the right security for your API is more than just saying… “OAuth2.0 on ALL our services!” It is important to find API characteristics, which will help you in defining the right security levels.

Colruyt Groups’ approach to characterizing security has three characteristics: confidentiality, integrity, and availability* (CIA). They focused on confidentiality and integrity only as the availability aspect was already covered in their API Management program. Based on that, Colruyt Group defined their requirements, which goes from a simple identification vs. full blown security with authentication and authorization.

This resulted in two security levels:

• Security Level 0: Client Identification, based on an API Key that will be used inside an API Gateway to identify a client.
• Security Level 1: Authentication and Authorisation by following the industry standard of OAuth2.0.

To face the challenges of OAuth2.0, Colruyt Group introduced a layered security funnel:

• Session Validation: implementation of a network firewall and WAF (Web Application Firewall) to validate the session.
• Coarse Grained Authorisation: performed on the API Gateway.
• Fine Grained Authorisation: performed on the API.

As stated before, it is not all about implementing the OAuth2.0 standard. Multiple crucial security decisions must be made. In the case of Colruyt, there were over 30 (!) architectural decisions: “we had to keep in mind the client, the STS Infrastructure (=client authentication and authorisation + end user authentication and authorisation), the API Gateway and the API Implementation.”

Some of their most important choices and decisions:

Besides, they picked a Bearer token over HoK token. Also, the granularity-audience was considered: do we use one token for all APIs, or one token per API? The choice fell for one token per API as they wanted to avoid token overload and limit risk.

However, it does not stop at the architectural level! Colruyt Group also defined 70+ Security Design Artifacts. As an example, Tom stated the following problem they ran into: “We started with one security pattern for our security level one, which was a perfect fit for our application services. Unfortunately, this wasn’t fully applicable for our Network/Infra services.”

Adding security controls will always come with a performance penalty. You should always keep on monitoring your performance and take the necessary actions on time. This way, you will be able to enhance the overall performance of your security approach. Colruyt Group implemented caching at certain levels, to come to a good balance of security vs. performance.

Adding security controls will always come with a performance penalty. You should always keep on monitoring your performance and take the necessary actions on time. This way, you will be able to enhance the overall performance of your security approach. Colruyt Group implemented caching at certain levels, to come to a good balance of security vs. performance.

It is an industry in a complex landscape, which comes with various challenges in the field of API implementation. For that reason, Colruyt implemented a protocol and security conversion. This way, the API Gateway can be at the front (REST coming in, Security OAuth2.0), but the implementation at the back-end can be accomplished by a specific protocol and security policy.