NOTE! this project is intended to be run from GitLab - hence the -gitlab-ci.yml. See the gitlab-ci file to understand what is needed; for example variables and secrets are picked up from GitLab CI/CD variables.

1 Introduction

Keycloak based access control layer solution with APISIX was designed to replace and give an alternative for Umbrella and Keyrock based solution.

Keycloak uses PostgreSQL to store users, groups and realms that contains access control related policies for users.

2 Configurations

Deployment is via GitLab CI/CD pipeline.

Deployment follows similar pattern like other components, Helm charts and substituting values to template files. We manually configured a client in Keycloack, and then imported that using Keycloak’s import mechanism. It’s recommended to follow this pattern, or then make regular backups of the database (postgres). User creation and management can be done via CI/CD pipe, but this is quite cumbersome and recommend manual approach, if there are not too many user requests.

If access from Internet is needed for Keycloak, replace DOMAIN in keycloak-ingress.yaml and execute kubectl command to apply it:

kubectl --namespace NAMESPACE apply -f keycloak-ingress.yaml

2.1 Intergration with APISIX

APISIX is configured to use authz-keycloak plugin. This allows us to user Keycloak as and IDM with APISIX.

3 User Management

There is one test users created in the CI/CD pipeline, and the repository has a test script, which can be used to test the deployment.

Users are managed by admin user. Self service features offered by Keycloak are not enabled.

4 Getting an access token

In order to get an access token, Keycloak provides a token endpoint:

curl --location --request POST 'https://keycloak.staging.odala.kiel.de/realms/apisix-realm/protocol/openid-connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=scorpio-client' \
--data-urlencode 'username=scorpiowriter' \
--data-urlencode 'password=xxx' \
--data-urlencode 'grant_type=password' \
--data-urlencode 'client_secret=xxx'

After that you can make a request towards Scorpio context broker:

curl --location --request GET 'https://scorpio-apisix.staging.odala.kiel.de/ngsi-ld/v1/entities/?type=TrafficFlowObserved' \
--header 'Authorization: Bearer eyJ...3A' \
--header 'Link: https://schema.lab.fiware.org/ld/context; rel=http://www.w3.org/ns/json-ld#context; type=application/ld+json'

and receive a response like:

[
    {
        "id": "urn:ngsi-ld:TrafficFlowObserved:61bb15be345c06d77f32e528",
        "type": "TrafficFlowObserved",
        "description": {
            "type": "Property",
            "value": "MQ13"
        },
        "address": {
            "type": "Property",
            "value": {
                "type": "PostalAddress",
                "streetAddress": "Alte Lu
                .
                .
                .

As an admin, you have access to the client application which holds the secrets needed for the requests. They also need to be in the CI/CD pipeline inorder the deployment to work.

5 Known issues / to be developed

Backups needs to be handled in case of data corruption.

Components- Keycloak

for the ODALA project.

© 2022 Contrasec Oy

License EUPL 1.2

The contents of this publication are the sole responsibility of the authors and do not necessarily reflect the opinion of the European Union. This project has received funding from the European Union’s “The Connecting Europe Facility (CEF) in Telecom” programme under Grant Agreement number: INEA/CEF/ICT/A2019/2063604