Kanidm: an open source identity management platform.

In the realm of identity management, Kanidm stands out as a well-built, fast, and fun-to-use solution for both self-hosting at home or in business environments. This open-source tool offers a modern approach to managing users, service accounts, applications, and even VM access. While it falls short of being user friendly due to some limitations, its strengths make it an excellent choice for those seeking a free and reliable identity provider.

🤘 Programmed in rust btw 🚀.

Kanidm

Kanidm

Kanidm

For those that don’t know Kanidm is something called an “Identity Provider” (Idp) that you self host. It provides you a way to manage your internal users; normally employees at a company or your friends and family as is the case for me. It provides the ability to centrally manage user and service accounts while also supporting permission (scopes and claims) you can place on them.

Written in Rust 🚀, Kanidm is fast (blazing fast) and runs very well in memory constrained environments, such as a raspberry pi. Kanidm comes out of the box with passwordless authentication, allowing users to configure authentication to internally hosted applications through biometric features that your phone or computer provides. This means users can use their face or finger print to login. What’s not to love!

Why use an Identity management platform?

Although Kanidm already has a great answer for their product on their documentation page, I'll try to convince you why you might consider running Kanidm (or any) Idp at all!

If you've ever had the pleasure problem of remembering more than one password to access an internal or job specific application at an organization then you might want to consider hosting an Idp. It provides users with the ability to remember just one password (or just use a piece of biometric information) to gain access to an internally hosted application. This provides an experience called "Single Sign-On" (SSO).

Not only is this a great experience for users, but it's also great for administrators, as they can control what applications are allowed to authenticate against the Idp as well as who has access to them.

SSO Integration

We'll take a moment to take a look at SSO, since it's the core features that that all identity providers have.

SSO is enabled by combining two protocols together; OpenID Connect and OAuth2. OpenID Connect is a specification that can be followed to allow users to authenticate who they are. It works together with OAuth2 by providing applications a way to get a the authentication token which can be used on behalf of the user.

Below is an example of this process in action. By using both protocols, a user can authenticate against a common application (kanidm in this case) and that authentication can be used in the application.

Other Solutions on the Market

Not all of the features Kanidm offers are unique, nor is it the most featureful authentication solution that exists. All identity providers enable you to configure SSO configuration. Therefore, you should consider other potential existing solutions if that is all you are looking for.

Pay to use

There are quite a few identity management solutions that you can pay for, such as Entea ID, auth0 and Okta. These solutions provide a lot more features then you could get from the FOSS (Free Open Source Software). However, a review of these products is out of scope of this post and blog. This is because the main focus here is self hosting software. Mostly cause I’m cheap and have a lot of compute at home with cheap power.

FOSS

I believe that when people look for identity providers that are free, they think they have only 2 options when looking for a similar product: Keyclock and Authelia. Actually there are quite a few more and Kanidm has already done a great job of arguing why you should use them instead of another product.

The popular open source Idp software provide many features out of the box but come with a bit of bloat to go along with it as they try and solve all the problems under the sun. With bloat also comes poor performance and large configure files that you'll need to read and understand.

Kanidm is a simpler product, that's easier to configure, that runs faster, with powerful capabilities. If you are resource constrained on lower power devices such as Raspberry Pis, or want to get something up and running quick, then Kanidm might be the application you are looking for.

The rest of the article will be on Kanidm. I know I didn’t give a detail over view of the other solutions, but that’s because I never tested them out and I haven’t had to, because of the amazing features and performance of Kanidm! 

Kanidm doesn't only offer SSO features. They provide quite a bit more out of the box. For instance, it can store users public SSH keys. Those keys can then be used against a VM (in the cloud for instance) for you to login with your existing private key. How cool!

The rest of this article will present administer and user experience of using Kanidm. It will then provide a brief overview of some of the features that it provides which makes it standout.

Administering Kanidm

One major difference that Kanidm has compared to other solutions on the market is that it doesn't have an administration UI to manage all of the data kept in the database. Instead admin's are expected to make changes in the application through kanidm command line tool.

From creating users, service accounts and groups, password resets, application registration and more, don't expect to be poking around a UI.

This is a bit of a pain for new administrators, but the CLI and system force persuade administrators to maintain their configuration through scripts and configuration rather than through a UI. Changes made to Kanidm are idempotent meaning that repeated calls to the same API endpoint, always has the same effect.  

Although it's possible for an administrator to use the CLI directly (I do this for my HomeLab), Kanidm exceeds when used through pipelines and scripts. This ends up making it a good companion to use with some popular infrastructure as code management strategies like git ops.

User Experience

The user experience of using Kanidm is delightful. It provides a simple web UI that users can log into. By providing their user ID (and depending on the way their account themselves configured), they are provided with different types of authentication.

However, the biometric one is my favourite. Once access has been granted, the user would be logged into the application. They can also login to kanidm directly. In the dashboard, they can view the applications they have access. Also they are able to self manage their account, like maintaining multiple forms of identification.

The UI may seem simple, but that's a feature, as it shows that Kanidm focuses more on its capabilities rather than bloat. The downside is that some things need to be configured through the CLI, even for user specific things, like SSH keys.

Account types

Kanidm offers your standard account types you expect from an identity provider.

• People accounts: for human users. These users manage their own passwords and authentication methods. Logs in through OpenID Connect and OAuth2 flow.
• Services accounts: for computers to dynamically access OAuth2 applications and/or read data from the Identity platform (such as for pipelines and scripts to manage Kanidm itself).
• Anonymous accounts: for querying public-ish data like users and service account public ssh keys. 

Authentication

All users would mainly interact with Kanidm authentication flow. The way a user would authenticate will differ depending on the way that user have configured their personal accounts. This is because password, TOTP (Time-based One-Time Password) and Web Auth are all viable options. 

There is also the possibility to configure account policy, which could then require users preform multiple types of authentication before gaining access to the application.

Buuut, if I had to require one form of authentication, it would be Web Auth! It’s a new standard that can use biometric information to give you access to your user account.

A demonstration of the WebAuthn specification

WebAuthn.io

Groups

Once logged in, users want to do something (otherwise, why would they login), in an application. They require access, and although you could add a particular user to an application, it best practice to always put access onto a group.

Groups can contain users, service accounts and believe it or not, other groups! Once created, you can assign permissions (claims and scopes) to them which will then be granted to all children inside of the group.

OAuth2 and OpenID Connect

Administrators can provide OAuth2 access to applications by creating a client ID and secret through Kanidm CLI. At the start of the article I gave a high level overview of authentication, but now we'll dive deep into how authorization, kinda works.

That can be done by adding scopes and claims to the generated JWT from the OAuth2 flow. These will need to be added to an application manually through the CLI.

Scopes

Scopes provides access to some type of information about the user that Kanidm has. That could be a users email, profile picture, their first / full name, ect.

Scopes are normally what is required for all users to use the platform. Kanidm will prompt you the first time you login to the application to check if you "sign off" on the app getting these details about you from the identity provider.

Claims

Claims are a bit different. They are a weak feature which provides an application an idea of what you should have access to. This is normally what would be known as authorization.

For example, admins could create 3 groups (read, write, admin) with their relevant scope values and put users in them. The scope names would then be included in the generated JWT and the application can then use them to determine the access the user would have in the application, such as the read group only having read only access to the data.

One of the downsides (or upsides) of kanidm is their lack of support for complex claims, where they only support space separated strings and json arrays. Sadly, some open source projects expect there to be complex json objects where the claim information is meant to be. This currently won’t work with kanidm because of a Regex that blocks it from being created successfully. 

Unix Services

So to review, as an administrator, I can create users, which can be placed in groups, where I can provide groups access to applications. This is already pretty cool but one thing missing that some technical users may appreciate is managing access to physical servers. 

You can manage users access to VMs using Kanidm too. Once the key is in the system, depending on how a VM is configured, you’ll be given access to SSH into it using the PAM (pluggable authentication module) that ssh provides. 

I've attempted to use this before when trying to build my git server. If you are looking for an example of this you'll need to wait, but feel free to read the docs as it provides a good overview of how to use the feature.

SSH Key Distribution - Kanidm Administration

Kanidm Administration

Other features

Application and SSH key access are the features that I've used heavily, so I can talk about them a bit more. However, Kanidm also supports nsswitch and RADIUS. I haven't used them so I won't provide any information on them.

In conclusion

Kanidm is a well built, fast, fun to use / learn identity management provider that is great for self hosting at home and for your business. It can access to manage users, service accounts, applications and VM access. It provides a (IMHO) great login experience supporting the latest authentication standards. It falls short of being an accessible for the less technically inclined as it can be difficult to configure the application.