Lessons Learned when implementing a Custom User Storage Provider for Keycloak

In this article, we present our findings and conclusions derived from our implementation of a “proof-of-concept” Keycloak extension. This extension integrates a relational database containing user information with the identity provider (abbreviated as “IdP”) Keycloak [1]. Within the Keycloak framework, such an extension is referred to as a “custom user storage provider,” which we will shorthand as “the custom provider” throughout this article.

The article begins by elucidating the motivation behind developing this custom provider, outlining its scope and objectives. Subsequently, it delves into the design decisions made and the intended data flow, accompanied by an explanation of the technical approach adopted. Finally, the article discusses the challenges and issues encountered during the implementation process.

Refactoring Part 3 - Spring Cleaning

As hinted in the second part of the series, code smells can be used as an indicator for a corresponding refactoring strategy. Some of these strategies seem like common knowledge, but shouldn’t be ignored as this is often the main cause of software issues.

Refactoring Part 2 - When code starts to smell fishy

After establishing the advantages and disadvantages of refactoring in my previous post, the next step is to understand when and where to begin the progress. Refactoring should be best applied to the regular programming workflow, to support the programmers in their everyday work routine:

Refactoring Part 1 - A Collyer's Mansion of code

It’s a common problem in software development that - all best intentions aside - the once clean and structured code base gets more and more complicated and messy over time. There are plenty of reasons for even the most cared for code to get to this state, e.g. technical debt. At this stage the designated developer is faced with at least two options to proceed further: Recreating the code from scratch or refactoring the code base over time.