{"id":26146,"date":"2024-02-29T15:40:07","date_gmt":"2024-02-29T14:40:07","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=26146"},"modified":"2024-02-29T18:03:34","modified_gmt":"2024-02-29T17:03:34","slug":"using-keycloak-as-iam-for-our-hosting-provider-service","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2024\/02\/29\/using-keycloak-as-iam-for-our-hosting-provider-service\/","title":{"rendered":"Using Keycloak as IAM for our hosting provider service"},"content":{"rendered":"\n

A variety of today’s applications require careful handling of user data. However, especially in student projects, due to time constraints or the focus of the project, there is a tendency to neglect or only superficially implement authentication and handling of user data.<\/p>\n\n\n\n

In the context of our project for the lecture ‘System Engineering and Management’ we have decided to create a hosting provider. Users should be able to book and start Docker container instances via a CLI application. For this project, it was important for us to integrate comprehensive Identity and Access Management (IAM) for our users.<\/p>\n\n\n\n

What is Keycloak!?<\/h2>\n\n\n\n

Keycloak is an open-source software for identity and access management developed by Red Hat. It provides a comprehensive solution for authentication, authorization, and user management for web applications and services. Essentially, Keycloak functions as a Single Sign-On (SSO) solution, allowing users to authenticate once and then access multiple applications and services without needing to log in again.<\/p>\n\n\n\n

Why did we decide to use Keycloak for IAM?<\/h2>\n\n\n\n

One of the main reasons why we chose Keycloak over other identity and access management systems is the fact that Keycloak is open-source and therefore free of cost. Since we already operate our own server for hosting the Docker instances, we can also host our Keycloak server on it. Another reason is the huge amount of features offered by Keycloak, which we may not fully utilize at the moment but could become relevant in future (larger) projects. Therefore, we wanted to gain experience with Keycloak already at this stage. Given that Keycloak is maintained by Red Hat and not just a community project, we have great confidence in the software.<\/p>\n\n\n\n

How do we utilize Keycloak in our application?<\/h2>\n\n\n\n


Since Keycloak provides a pre-built web interface for login, registration, and logout, we have decided to utilize this web-based OpenID Connect authentication flow. The concept behind it is as follows:<\/p>\n\n\n\n

    \n
  1. The user wants to log in or register via CLI. To do this, a local callback web server is started, and the browser is automatically opened with the corresponding Keycloak interface.
    <\/li>\n\n\n\n
  2. After successful login or registration on the Keycloak web interface, the browser is redirected to the local callback server. An authentication code is passed as a URL parameter.
    <\/li>\n\n\n\n
  3. The CLI or the callback server can request a Token Exchange using the authentication code. The authentication code is exchanged for a JWT Token Set. This typically consists of an Access Token, used for API requests against the backend, and a Refresh Token, which can be used when the Access Token expires to request a new JWT Token Set from Keycloak.
    <\/li>\n\n\n\n
  4. The CLI stores the Token Set locally on the device for future use.
    <\/li>\n\n\n\n
  5. When a request to the backend is made, the tokens are read again. If no tokens are present, it means the user is not logged in. The backend uses these tokens to identify the user.
    <\/li>\n\n\n\n
  6. In the case of an expired token, the CLI can use the Refresh Token to obtain a new Token Set from Keycloak and retry the request to the backend.<\/li>\n<\/ol>\n\n\n\n
    \"The<\/a>
    Fig. 1: The authentication flow for our CLI using Keycloak<\/figcaption><\/figure>\n\n\n\n

    Using Keycloaks SPI to listen to events<\/h2>\n\n\n\n

    In the implemented hosting provider application, user-related data such as the username, email address, and password are stored in Keycloak. Additionally, the application includes a simple payment model: Each user has a balance that can be topped up and is used to bill the services used by the hosting provider. These user-specific balance information is not stored in Keycloak but in a separate Amazon DynamoDB.

    A user is able to self-register using the keycloak web interface. Also there might be the case where a user contacts us in order to get his account deleted. In this context, depending on the event performed, it was necessary to create or remove a corresponding balance instance for the respective user in DynamoDB. The central challenge is to ensure that the data in both Keycloak and the standalone Amazon DynamoDB are consistent and data integrity is maintained.<\/p>\n\n\n\n

    How can we fix it?<\/h3>\n\n\n\n

    Approach 1<\/strong>: One solution could be the interval-based checking of the data in Keycloak and the separate database to detect and correct inconsistencies. This approach has two disadvantages though: Firstly, the update between Keycloak and the database does not occur in real-time but only at predefined intervals. Furthermore, the data synchronization between Keycloak and the database leads to long-term performance issues if the application is expected to be used by many users.<\/p>\n\n\n\n

    Approach 2<\/strong>: In addition to the interval-based solution, there is also a way to react in real-time to events such as the creation or deletion of a user. Keycloak provides Service Provider Interfaces (SPIs) which serve as interfaces for extensions or customizations.<\/p>\n\n\n\n

    Regarding our hosting provider service, an Event Listener SPI is used to react to specific Keycloak events and perform logging. This approach circumvents the performance problem of the first approach and also offers a real-time solution instead of an interval-based one. This results in the following flow:<\/p>\n\n\n\n

      \n
    1. A new user is created or deleted in Keycloak manually or via the CLI application.<\/li>\n\n\n\n
    2. A SPI event is triggered, which is captured by an event listener.<\/li>\n\n\n\n
    3. These events are transmitted to the backend via webhooks.<\/li>\n\n\n\n
    4. The backend responds accordingly to the events and creates or deletes a balance instance in the database for the respective user.<\/li>\n<\/ol>\n\n\n\n
      \"Event<\/a>
      Fig. 2: Event Listener SPI for Keycloak<\/figcaption><\/figure>\n\n\n\n

      Learnings and Tips for Reimplementation<\/h2>\n\n\n\n