Janssen: an identity platform that ships its parts separately

A foundation project with one company setting the priorities

The Janssen Project describes itself as a home for open source IAM components, and the governance arrangement is stated plainly rather than left to inference.

It is a self-funded project chartered directly under the Linux Foundation, with the stated purpose of fostering the development of enterprise digital identity and access management infrastructure. As the lead Contributors, the Gluu team drives the priorities on a day to day basis, governed and guided by the Janssen community Technical Steering Committee.

That sentence contains the whole arrangement in miniature. The project sits under a neutral foundation charter, the community has a steering committee, and one company leads the contributors and sets the day to day work. The readme is explicit that if your enterprise needs Janssen for a production deployment, Gluu offers a commercial distribution of the components called Gluu Flex and Gluu Solo.

The commercial offering is worth being clear about, because it is not hidden and it is not the same thing as an open core with the good parts removed. The open source project is the upstream core, and the same components are what the commercial distribution ships. The auth server entry in the component table even says so, describing Jans Auth Server as the upstream open-source core of Gluu Flex.

The project also carries a Digital Public Goods verification badge, an OpenSSF Scorecard badge, an OpenSSF Best Practices badge, and an SLSA level 3 badge, plus an Artifact Hub badge for the container repositories. That set of badges is a good signal of what a procurement team will ask about, and its presence suggests the project expects to be evaluated by one.

The repository itself is Apache 2.0 licensed, and the release stream includes a nightly build tagged nightly alongside the versioned releases, which is the usual pattern for a project that wants both a stable channel and fast feedback on main.

The components and their lifecycle stages

The component table is the most useful part of the readme for anyone evaluating this, because it lists both what each piece does and where it sits in its maturity.

Jans Auth Server is a complete OAuth Authorization Server and a certified OpenID Connect Provider written in Java, and it is marked as graduated. Jans FIDO, in the jans-fido2 directory, enables end users to enrol and authenticate with passkeys and other FIDO authenticators, also graduated. Jans SCIM provides a SCIM JSON and REST API for user management including associated FIDO devices, graduated. Jans Config API exposes RESTful APIs that manage configuration for all Janssen components, also graduated. The Text UI, or TUI, is a user interface accessible from the command line, a text based interactive configuration tool that leverages the config API to configure Janssen Server modules, and it too is graduated.

Agama is described as offering an interoperable way to design authentication flows, coded in a DSL purpose-built for writing identity journeys, and it is marked as graduated. That one deserves a note. Authentication flows in most products are either a fixed set of screens or a pile of custom code, and a DSL purpose-built for identity journeys is a meaningfully different approach, with the design intent that a flow written in it can be moved between deployments that use the same components.

The other entry visible in the table is the Cedarling, a policy decision point, which appears in the repository as the jans-cedarling directory. The readme description calls the project a home for the Auth Server, Agama and the Cedarling, and the top-level listing also shows jans-core, jans-orm, jans-lock, jans-bom, jans-pycloudlib, jans-link, jans-shibboleth-idp, a shibboleth identity provider directory, a linux-setup directory, a terraform-provider-jans directory and an automation directory.

The lifecycle stage column matters more than it looks. The readme notes that there are several Janssen components in different stages of development, from demos to stable releases, and the maturity stages are documented in the contribution guide. A component marked graduated is a different commitment from one still in development, and the table is where you find that.

A repository that is mostly deployment assets

The top-level directory listing tells you how this project is actually consumed, and it is unusual.

There is a long run of Docker directories, one per component: docker-jans-all-in-one, docker-jans-auth-server, docker-jans-casa, docker-jans-cloudtools, docker-jans-config-api, docker-jans-configurator, docker-jans-fido2, docker-jans-link, docker-jans-persistence-loader, docker-jans-scim and docker-jans-shibboleth. Each of those is a runnable image for one component.

Then there are the source directories, which follow the same naming: jans-auth-server, jans-bom, jans-casa, jans-cedarling, jans-cli-tui, jans-config-api, jans-core, jans-fido2, jans-link, jans-linux-setup, jans-lock, jans-orm, jans-pycloudlib, jans-scim and jans-shibboleth-idp. The agama/ directory holds the flow designer.

The infrastructure side is present too, with charts/ for Helm charts, demos/, a terraform-provider-jans directory, an automation/ directory, a docs/ directory built with mkdocs as the mkdocs.yml at the root suggests, and a docs/ tree that includes the contribution guide, the community charter and the code of conduct, matching the links in the readme.

Two small files at the root are worth noticing. There is a context7.json and an llms.txt, both of which are conventions for making a codebase's documentation available to a language model, which tells you the project expects AI tooling to be part of how people read it.

There is also a debian-13-mysql.txt at the root, which looks like a list of MySQL packages for Debian 13, and a .pre-commit-config.yaml and a .trivyignore, the latter for the container vulnerability scanner. The Conventional Commits badge says the commit history follows a standard format, which matters for a project with this many contributors.

How to get it, and who to ask

The support and learning routes are laid out in the readme as a set of links, and the division between them is informative.

For releases there is a latest release link and a full releases list. For help there are GitHub Discussions and a chat server. For documentation there is the docs site at docs.jans.io. For contributing there is a contribution guide, a community charter in the documentation and a developer guide, with the code of conduct linked from the same block. The social links are LinkedIn and a YouTube channel, and for learning there is the Gluu Academy.

That last one, the Academy, tells you something about the project's shape. A training academy alongside a foundation project means the project expects users who need to be walked through it, which is a different posture from a component library that assumes you already know OpenID Connect.

The homepage is the documentation site rather than a marketing page, and the project description in the repository metadata is about the components rather than about a product. The Janssen Server distributions are described as bundling IAM components under one control plane, which is the middle ground between running fifteen separate services and running the commercial distribution.

For evaluation, the badges cover the usual ground: an Artifact Hub badge for the container repositories, an OpenSSF Scorecard, the OpenSSF Best Practices entry and an SLSA level 3 badge for build provenance. A DPG verification badge points to the Digital Public Goods registry, which is the framework for public-interest technology funding and which explains the foundation charter.

Editorial conclusion

Janssen suits a team that wants an identity provider with an open source core, a flow designer rather than hand written authentication code, and a control plane that can be run on Kubernetes or as an all in one container. It does not suit a team that wants a self contained product with one vendor behind it, since the community prioritisation is driven by Gluu and the supported path for production is a commercial distribution. Before deploying, read the component table to see which pieces are graduated and which are still in development, and plan for the fact that the release stream includes a nightly tag alongside the versioned releases.

Frequently asked questions

Official sources

1. JanssenProject/jans on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases