Like many other organisations, Colruyt is exposing more and more information and business assets through APIs to reach new markets, where speed to delivery and ease of consumption are the key to success. For that reason, they started to realise that controlling the access to their APIs was highly important as the number of APIs was only going to grow in the future.
“Not only did we want to take control on API level, but also on functionality level. In addition, we wanted to facilitate row-level security based on the interaction between the end-user and the client’s application. On top of these business aspects, a technology shift took place (JSF -> Angular Mobile) which came with new security requirements. Next to this the service landscape changed from SOAP to REST, which also influenced our API Security Architecture/ Approach. All of the above led to the awareness that we needed to evaluate our API Security approach” according to Tom, Security Architect at 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 Authorisation aspects.
Defining the right security approach
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 characterising 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 authorisation. 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.
More than just implementing OAuth2.0
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:
- Product selection: IBM Access Security Manager for the STS Infrastructure and Software AG’s API Gateway, which was a re-use of the existing products.
- Cross Platform Approach: this approach was chosen as they have both Java APIs as well as mainframe APIs as different COTS packages. Besides, they had to ask themselves questions as: when does a recalculation happen of the access refresh? Do we need consent out of scope?
- Token: in terms of token type, they chose an Opaque token before the API Gateway and by value tokens after the Gateway. This for two reasons:
- Occurrence of misuse and information abuse of the client.
- Avoidance of leakage of security information.
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.
- Remote Introspection: so called ‘boundary control’. In Colruyt Groups’ story, when a call is being made from the client to an API Gateway, a boundary component validates and the token is introspected towards the authorisation server.
- Token Translation: Not only from Opaque to a Bearer token, but also act as a mediator for migrations towards the API backend.
- Local introspection: implemented on the API itself as a signature check, but also for additional validations of the audience, expiration, issuer,… .
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.”
Performance Quality of the APIs
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.
Industry standard in a complex landscape
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.
“Don’t forget the other aspects! Our API Gateway is a key component in our API security approach, which required a newer version to support all features. Additionally, we needed to upscale on the infrastructure level, as more traffic will pass over this component. Governance wise, we made some security decisions that will be checked in these checkpoints as our governance process contains several quality checkpoints, linked to the API lifecycle. And for the embedding in our organisation, we embedded everything in our processes. We also provided guidelines on all levels and additional training for each role involved in the API lifecycle”, Tom states.
“If you want a shift in your landscape, you need a shift in mindset to achieve a secured API landscape”, Tom concludes.
Do you have any questions about this project, or would you like to know what we can do for you? Let us know!
Full video version: The road towards a secure API landscape - The Colruyt Group Story!