Gravitee.io access management

This tutorial deals with setting up Gravitee Access Managment for OAuth2 based authentication towards an API. It is the third part of the tutorial series

A Starter Guide for full stack development on Kubernetes

If you followed the tutorial, you meanwhile have an API in places with token based access control using Gravitee API management. Now, we will

• Deploy Gravitee Access Management onto Kubernetes to provide user based access to the API
• Configure OAuth2 / OIDC to allow user based access to our API
• Configure role based access to API functions

What you will need to run this tutorial

You will need to have:

• An internet accessible Kubernetes cluster onto which you can run kubectl commands (e.g. from the usual public cloud providers)
• Gravitee API Managmenet installed with a webapi against we build. You may follow the tutorial from start to achieve this
• As you will see in the tutorial, we will setup our own Identity provider. It is equally possible to use third party identity provider as Google, facebook, etc… to login users for our API usage.

Setting up Gravitee Access Management

The setup of the access manager of gravitee is quite the same as for the API manager of previous tutorial. Also here, we focus on the scope of this tutorial. Further use cases are covered in the documentation at

Open Source API Management Platform - Gravitee

Usually you should already have the helm repository in place. Get it with helm

helm repo add graviteeio https://helm.gravitee.io

Now, we need to download the configuration.

helm show values graviteeio/am > am.yaml

We need to perform changes as in previous tutorial on the configuration values. You may compare with my sample (line numbers refer to that file). https://github.com/TomSearcher/graviteeio_on_kubernetes/blob/main/graviteeio/am.yaml

Here in a nutshell:

• Change DB parameters inline to your DB deployment in section “mongo:” (Line 11). The settings on the github yaml files correspond
• Disable DB deployment by setting key “enabled” of mongodb-replicaset (Line 32) to false
• Change all “hosts” entries to your domain with a dedicated subdomain (e.g. api.yourdomain.com)
• Disable secretName entries if you use the default certificate of the ingress gateway. Otherwise specify the ssl certificate there
• Change password (Line 91)
• If you wish to keep the deployment small, change all replica values (various names like maxreplicas, replicacount,…) to 1.
• Change jwtSecret (Line 106 and 198) to anything you like.
• I had difficulties using the Access Manager with the default ingress of the gateway (Line 232, 240, 241) placing it behind path /auth. Hence I gave it a dedicated subdomain (Line 235, Line 251) and changed the configuration to use “/”.

Now we can deploy the Access Manager into the same namespace as the API Manager. There is a little hick in the helm repo in the latest version (1.0.13). Probably this is gone when you test and you can leave out the version parameter below:

helm install am --namespace apim -f am.yaml graviteeio/am --version 1.0.12

Now you can access the Access Manager behind URL https://subdomain.yourdomain.net . Initial user password for admin is adminadmin.

Follow the steps to create a first security domain:

Next we need to adjust some global settings (click your user on the top right) > Global settings:

Configure the Gateway’s url (Line 235 in the yaml) under settings > entrypoints:

Now we are ready to create an application to consume our API:

Use Single-Page App

Now specify the public domain of your later React web application. This is where users get redirected upon login (we will add localhost for debugging in later steps, for now just put the final public one).

Activate the Identity Provider to be used. We will just use the DB of our installation:

Create 2 Users. One will get admin rights later on. Here I use John and Jane Doe.

We will use OAuth2 scopes to control API access to functions, which allow changing date. Such scopes are tags, which are shipped together with the bearer token after login. We can use those tags later on in the frontend development to align the view relative to rights. The control of accessibility will however be on API level. So lets add a scope called “write” in settings > scope

Now we can add a Role “admin” and add the scope “write” as permission to that role:

Let’s assign Jane admin role:

Now go to the openid settings page. Activate localhost and http access temporarily, such that we can run our frontend on localhost. Disable those flags once the frontend application goes public:

Now it is time to configure OAuth2 plus OIDC for the application (settings > oauth2 > settings). Activate the Mongo DB identity provider if not already active (Identity provider tab).

Activate Authorization Code and Implicit and disable PKCE (Settings tab). Implicit gets actually replaced by PKCE, but I still need to check how this works. I will update once there.

Scroll down. Now we select those scopes, which must be present to allow user access (the user will have to approve on first login if he is ok to share the information). We need to have the openid scope. We do NOT need to add the custom “write” scope, since we also allow users read access to the application if this scope is not present.

Under “General” tab you will find allowed redirect URIs. Let’s add here http://localhost:3000 to test our React app locally before deploying (to be removed once public).

This completes our Access Management setup including configuration of a security domain for our API.

Configure API to use OAuth2

Visit the console of your API manager of previous tutorial. Go to API -> select your API -> and click Design. On the top right you find a tab called “resources”. Click it and select Gravitee AM.

Fill in the required information. Server URL is what is configured in Line 235 of the am.yaml file. Use the latest version.

All other information can be copy-pasted from the Access manager Settings overview of the security domain:

In previous tutorial, we created a plan to use an API key for authorization. Now add a new plan with Authentication type “Oauth2”.

Also, as we did in previous tutorial, we need to create a new Application. Same procedure as in previous tutorial, but here you need to add the client id, by copy pasting the value in the access manager configuration and select the new plan which we just created.

Our API has now 2 plans. If you return to the “Design” section, you will see both of them. We now need to configure the new plan to deal with OAuth2. By default, the new plan has one configuration for ALL http methods. We will alter this for non-administrative usage, which is in our API all types of GET requests (you may see all, but write nothing):

• Drag OAuth2 from the right list to the request arrow to enforce bearer token usage
• Change method to GET

Now add a second flow to the plan for administrative usage:

• Use all but “GET” methods for http methods
• Again drag Oauth2 to the request flow and enforce existence of the previously configured “write scope”

Final thing, which we have to do is to finally enable CORS to ensure that our frontend application is not rejected by the API gateway:

We are done. Now our API manager will allow us to use OIDC for accessing the API :-). In next and final tutorial we will develop a frontend application to consume our API.