Keycloak integration with OpenFGA (based on Zanzibar) for Fine-Grained Authorization at Scale (ReBAC)
This repository contains a PoC implemented with Keycloak integrated with OpenFGA on demostrating how to apply fine-grained access (FGA) control in a high performance and flexible authorization.
In this version of the PoC we have a direct integration between the Access Manager platform and the OpenFGA solution thanks to the use of the OpenFGA Java SDK to publish the events.
This workshop is based the following article Keycloak integration with OpenFGA (based on Zanzibar) for Fine-Grained Authorization at Scale (ReBAC). You will find there full details about the authorization architecture guidelines and involved components.
In the new version 🔥, I aimed to continue improving the authorization architecture and provide an agnostic approach for exposing and protecting APIs following best practices such as Policy as Code (PaC), decoupling authorization, and low-code authorization. Therefore, I added an identity-aware API gateway, Apache APISIX, as an API sidecar to the authorization architecture to enforce authorization and decouple it from the backend. The gateway uses a plugin I developed called authz-openfga that supports Relationship-Based Access Control (ReBAC) policies because it's integrated with OpenFGA platform. The details are explained in the following article Mastering Access Control: Implementing Low-Code Authorization Based on ReBAC and Decoupling Pattern.
The following diagram illustrates the solution architecture of this workshop:
- Core:
- Keycloak is responsible for handling the authentication with the standard OpenID Connect and manages user access with its Role Model.
- Keycloak is configured with a new custom extension ❤️: keycloak-openfga-event-publisher
- Listens to the Keycloak events (User Role Assignment, Role to Role Assignment, etc).
- Parses this event into an OpenFGA tuple key based on the Keycloak Authorization Schema.
- Publishes them to OpenFGA over HTTP using the OpenFGA Java SDK.
- OpenFGA is responsible for applying fine-grained access control. The OpenFGA service answers authorization checks by determining whether a relationship exists between an object and a user.
- Other components
- Store Web Application is integrated with Keycloak by OpenID Connect
- Store Authorization Gateway exposes and protects the Store API with ReBAC policies integrated with the OpenFGA Platform (Protection at API Gateway)🔥.
You can also have Store OpenFGA API is protected by OAuth 2.0 and it utilizes the OpenFGA SDK for FGA as example (Protection at API Level).
Another cool feature of custom extension is its capability to discover the OpenFGA authorization model and determine which events are handled. This gives you the flexibility to choose your authorization model, whether it’s RBAC, GBAC, or both 🙌.
- Install Git, Docker and Docker Compose in order to run the steps provided in the next section
-
Clone this repository
git clone https://github.com/embesozzi/keycloak-openfga-workshop cd keycloak-openfga-workshop
-
Execute following Docker Compose command to start the deployment
docker-compose -f docker-compose.yml -f docker-compose-apps.yml -f docker-compose-openfga.yml -f docker-compose-import.yml up
-
To be able to use this environment, you need to add this line to your local HOSTS file:
127.0.0.1 keycloak openfga store store-openfga-api store-authz-gateway
-
Access the following web UIs using URLs bellow via a web browser.
Component URI Credential Image Keycloak Console http://keycloak:8081 admin / password quay.io/keycloak/keycloak:25.0.1 OpenFGA Playground http://localhost:3000/playground openfga/openfga:v1.5.5 Store Portal http://store:9090 Custom image Store Authorization Gateway http://store-authz-gateway:9080 Custom image based Apache APISIX Gateway Store OpenFGA API http://store-openfga:9091 Custom image
In the latest version, the store portal calls the API exposed by the Store Authorization Gateway (
store-authz-gateway:9080
). If you want to call the Store OpenFGA API (store-openfga:9091
), just adjust the store portal configuration
In this new version of the workshop, we automatically import all the required configurations into the Keycloak and OpenFGA platforms 😄 🪄
-
You will find that the OpenFGA Event Listener 'openfga-events-publisher' extension in Keycloak is enabled.
- Administration console > Realm settings >
openfga-events-publisher
- Administration console > Realm settings >
-
The following roles and demo users have already been created in Keycloak.
The password for all the users is
demo1234!
-
You will see the following OpenFGA Authorization Model in the OpenFGA Playground Console and the Tuples tab:
-
Once the workshop is deployed, the Keycloak OpenFGA Event Publisher extension proceeds to send these events over HTTP to the OpenFGA solution. Here, all tuples are stored.
User Relation Object role:admin-catalog parent role:view-product role:analyst-catalog parent role:view-product role:admin-catalog parent role:edit-product user:paula assignee role:analyst-catalog user:richard assignee role:admin-catalog The users are identified by the value of the claim sub.
As an example, we will implement an Product Catalog web application that has the following requirements:
- Only authenticated user can access to the application
- Product can be viewed by their Analyst
- Product can be edited by their Admin
- Global Admin users can view or edit any Product
You can follow the test cases described in the Keycloak integration with OpenFGA (based on Zanzibar) for Fine-Grained Authorization at Scale (ReBAC).
And the article Mastering Access Control: Implementing Low-Code Authorization Based on ReBAC and Decoupling Pattern.
Nevertheless, the use cases are detailed below:
-
Access to the store web application store web application and proceed to login with Paula (paula / demo1234!) in Keycloak.
-
Keycloak will return the id_token and the access token to the application
-
The Store web application will show the product catalog
3.1. The app will call the product API sending the access token in the Authorization header
3.2. The API will apply the following steps:
3.3. It will validate the token following the OAuth 2.0 standard and it will extract the claim sub to identify the user
3.4. Then it will call the OpenFGA API to check if the user has the view-product role with the relationship assignee
3.5. OpenFGA will return the response “allowed”
3.6. The API will return the product information and the Store web app will show the product catalog to the user
-
Try to publish a product by clicking the button "Publish" but you will see that Paula is not allowed
4.1. The app will call the product API sending the access token in the Authorization header
4.2. The API will apply the following steps:
4.3. It will validate the token following the OAuth 2.0 standard and it will extract the claim sub to identify the user
4.4. Then it will call the OpenFGA API to check if the user has the edit-product role with the relationship assignee
4.5. OpenFGA will return the response “denied”
-
Access to the store web application store web application and proceed to login with Richard (richard / demo1234!) in Keycloak.
-
Keycloak will return the id_token and the access token to the application
-
The store web application will show the product catalog
-
Try to publish a product by clicking the button "Publish" but you will see that Richard is allowed
-
Access to the store web application store web application and proceed to login with Peter (peter / demo1234!) in Keycloak.
-
Keycloak will return the id_token and the access token to the application
-
The store web application will try to the products show but the user is not allowed