At JIDOKA we strongly believe in open source, this doesn’t mean we don’t believe in commercial software. Many of the projects we do result in software that end users have to pay for, this of course is the choice of the client. If the software that is being built is the differentiator in the market, it doesn’t make sense to give away your investment.
On the other hand, there is also plenty of code that is not part of the reason why a company is different compared to its competitors. A problem that every company has to face is authentication and authorization. Within JIDOKA we have been using Keycloak as our GOTO product. It’s a nice product that integrates well with many solutions and supports many standards.
In a number of applications, we identified two improvements over the regular use of Keycloak.
One was the automatic configuration of Keycloak clients and roles in the application. So that when we boot our application in a new environment with a fresh Keycloak instance, Keycloak does not need to be configured separately. This has the advantage that the roles for Keycloak are defined in the place where they are used, the application. Furthermore there is no need for the customer to administer Keycloak. With little setup, no changes are required when new versions of the application are deployed.
The second was user management from within the application. Which means that the application can provide its own REST-endpoints for creating users in Keycloak and managing the roles for those users. This has the benefit that the customer does not need to know how to operate Keycloak and you can provide a user friendly, simplified UI for managing users and user-roles within the application.
At the time we could have decided for a BDUF (Big Design Up Front), (e.g. creating a dedicated integration service for managing the roles and users. Change requests could come in over Rabbit/Kafka. This solution would cater for future applications being integrated via this integration pattern). However this seemed a bit overkill, so we decided for the KISS (Keep It Simple Stupid) approach. The result can be found here.
What does it do functionally?
It allows you to administer the realm
Clients
- Retrieving clients for the realm
- Creating clients for the realm
- Adding client roles
- Removing client roles
Users
- Creating a user
- Retrieving all users
- Get a user with client roles
- Add client role to user
- Remove client role from user
How does it work technically?
We need to set up a Keycloak admin client. This client should have the necessary rights to manage your realm. This user will communicate with the Keycloak API and do the heavy lifting for us. We just need to use the service that abstracts a lot of the complexity of dealing with the API.
Why did we open source it?
Some of our customers are using Keycloak as well. By open sourcing this project, they can use this library without the need for a dependency on JIDOKA. It also means we don’t have to create private builds that are hosted on private repositories. Hence the distribution of the libraries is much more easy in an open source solution versus a proprietary library. In the past we have seen many companies trying to create vendor lock-in situations with their own proprietary software. We at JIDOKA are fans of open communication and open solutions that work well.
