There are three reasons why we need Keycloak in API landscape:
Keycloak is an open source identity and access management system. It provides OAuth 2.0 standard to authorize our REST API calls. Every call that comes to API Bridge need to have header (Authorization) which contains Keycloak access token.
Authorization: "Bearer eyJhbGciO....ertree"
So, authorization of API reqeusts is one of the reasons we use Keycloak.
Token from Keycloak is used not only to autorize API calls. Each API call must be run on IBM i. Therfore we need to know which IBM i user to use on the backend system when calling APIs. As DC1 is a user-aware system, it is important to provide IBM i user profile togehter with API call to be sure how the IBM i should construct job etc… Information about IBM i user profile is stored also in Keycloak on user profile level. An attribute called “app_user_id” is kept on user profile level that specifies IBM i user ID. Additionally, Keycloak clients are configured to include this information in the token. There is mapping of this user attribute “app_user_id” for the client in Keycloak to include it in the access token. When API Bridge authorizes API call, it also extracts “app_user_id” from the token and then passes it to the backend IBM i. So, IBM i “knows” which user must be used to call API RPG program.
Most endpoints exposed by API Bridge are not controlled by Roles. But there is special group of endpoints exposed from API Bridge which are also secured by roles. These are all endpoints that start with “/admin/…”. To call any API from this group you need to have role=admin. Here Keycloak helps us. There is a possibility to set up roles and attach them to users in Keycloak. Just add role “admin” and attach it to your user profile in Keycloak. Since this moment you can run “/admin/…” endpoints.