Keycloak — part 2

soIn the previous article, I created “phase 1” of the keycloak script:

This is our basic work to frame up the idea and get a handle on the key components for a new software service. Now we want to expand on the idea by cleaning up the code and adding a couple of new requirements.

Here’s the final version of the code to view:

Our new requirements that we want to bake in:

1. Reformat the code to make it easier and a little more reusable.
2. Pull the authorization information from AWS::SecretsManager, where our secrets are stored.
3. Open a file containing our client information, parse the JSON, and create a client in the Keycloak service for each client.
4. Inject secrets into certain clients that require it.

Formatting the code to a class-like structure is something I personally enjoy. I think it makes the code easier to read and follow, but different strokes for different folks. Formatting things in a flat function file is just as good. This project probably won’t expand beyond this scope, so we should be safe to keep everything in a single file.

This also makes unit/functional testing easier down the road, should we choose to expand on this idea.

Now that we have a cleaner, more organized based to work from we can start putting more functionality in place. We’ll start off with the secrets.

def get_secrets(self):
 sm_client = boto3.client("secretsmanager")
 return json.loads(
 sm_client.get_secret_value(SecretId=f"/company/projects/{project_name}/secrets/keycloak")["SecretString"])

This is an easy way to get the secrets from our vault, and store the values on the object to be used later. Now we can move away from having hard-coded values in the source code and most likely also checked into git.

Believe it or not, but this is a very common practice to happen in the beginning of most projects. The danger isn’t that we have dev secrets in git, instead, it’s more likely that production secrets are stored in the code because the second half of the work to store the secrets in a vault doesn’t ever happen. The tech dept is essentially never paid down, so you end up with the high cost of having production secrets in code.

Now we’re getting to the fun part. The entire point of this project was to be able to actually create clients and roles in the Keycloak service using the Keycloak API.

We start this by having a definition of what our client expectations are. In a small sense, we’re basically trying to create something that acts like Terraform or Chef ( or whatever ) where we have an expected state, reality, and something in between that takes our expectation and creates reality.

Lucky for us, what we have in etc/keycloak-client.json is exactly what the API expects as far as data. In some cases we might have to formulate exactly what the API requires with a little hit and miss.

In this case we can simply pass each object to the API and our clients get created.

There is a use case to have a secret pushed into the client object before it’s sent to the API:

if client["clientId"] == "mgmt-api":
 client["secret"] = self.secrets["master_realm_secret"]

If I were to expand on this idea, I would break this out into objects and have each client represented by an object, with generic interfaces for injecting secrets or building the URLs required for each client.

In this case, however, we’re keeping it simple and easy to keep the scope creep down to a minimum. Doing objects like this can also make things more difficult to read.

In the world of IT, it’s easy to get overwhelmed with whatever everyone else is doing and how well they’re doing it. Most of what you see started out as scratch pads and brain farts, and eventually became something more interesting.

The point of this series of articles is to show off that most of us don’t know everything, and even professionals with 20 years of experience need to start with scratch pads and poke at things until it’s right.

This is the truest form of “magic” in IT that I can think of. In that magic is the art of taking something in your mind and making it real.

Originally published at https://medium.com on January 21, 2020.