Goal (in few lines)
LINAGORA has used LemonLDAP as the SSO solution for several years now.
From Summer 2020, most of the solutions were upgraded to work with OIDC,
and LemonLDAP’s configuration was updated to become an OIDC provider.
However, LINAGORA keeps on having issues with LemonLDAP (configuration remains complicated) and some features are not well-supported (no JWT access tokens) or well-documented.
The goal of this study is to find a replacement solution to LemonLDAP and use another OIDC provider. This solution will work with several Software components, from Twake to LinShare, Apache James, etc.
Current Situation
Here is how we use LemonLDAP as an OIDC provider:
- LemonLDAP runs in K8s as Docker containers.
- LemonLDAP’s configuration is stored in files, loaded from a git repository and mounted as a volume from a config map.
- LemonLDAP sessions are stored in a MongoDB cluster, which guarantees the high availability of the data. Since they are only sessions and that they are replicated across the cluster, there is no backup for this database.
- These choices ease the scalability of LemonLDAP: we can easily increase or reduce the number of replicas.
- The configuration loaded as a volume is created separately (e.g. on a local machine). It means we do not perform hot-changes on the configuration (we tried this in the past, but the configuration then had to be stored in MongoDB => backups, restoration, etc). Instead, we create a new version of the configuration that can be reviewed in Git and we then apply it. This process would be nice if the configuration had been designed to be edited by hand. The fact is it only serializes what the “manager” console writes.
- The “manager” console is far from being intuitive and an internal documentation is used every time one has to create or modify a configuration.
- To support PKCE, a local patch had been applied, waiting for the LemonLDAP community integrates it.
- The Docker image for LemonLDAP is built internally. There are 2 processes inside, one for NGinx and one for the bridge with PERL scripts. Overall, we cannot say LemonLDAP was designed or upgraded to run in Docker, nor is it tailored for a gitops approach.
- Load tests run with around 1000 simulatenous users showed LemonLDAP was the bottleneck, while it had more instances than others (more than 10 instances). The fact it does not support JWT tokens widely explains these results. To be more precise, LemonLDAP supports JWT tokens but only for ID tokens and not access tokens.
- We also noticed issues with Single Log Out (SLO): sometimes, it does work correctly and a user cannot log in anymore.
Methodology and Criteria
This study is only about the choice of a technical solution.
Since we look for a solution for both our SaaS and on-premise deployments,
it cannot be a SaaS solution. We are looking for an open source technical component we can
install and manage on our own.
So, we can use the QSOS methodology, already used by LINAGORA for many customers. This methodology relies on a grid with invariant criteria (related to open source and maturity). It is completed by other criteria we will list below.
Every criteria is evaluated and results in a grade.
Some criteria can be more important than others and this is why each criteria gets
a weight. It allows to give a global grade to every solution. The one with the highest
score is retained.
There are few tools we can use.
LINAGORA generally uses Libre Office spreadsheets for the grid. One solution is to manage
everything in our OnlyOffice instance. Another one would be to only trust what we
put here, and generate the grid with Markdown.
Let’s detail the additional criteria.
There are several categories.
Constraints
Constraints are not part of QSOS studies but are often used in architecture documents. Constraints are rules solutions cannot break. If one constraint is not fulfilled, then the solution is excluded and not evaluated.
There are 2 constraints here:
-
The solution must be certified by the Open ID Foundation. Solutions that are not certified cannot be considered as mature and fully-supporting the OIDC specifications.
-
The solution must support SAML 2.0
Open Source Criteria
Normally, there are 16 criteria about open source.
We here only retain the few ones that matter for LINAGORA.
- Development history: the project’s maturity.
- Development team: is it made up of a single person, a same company or a real community?
- Popularity: how many people support this solution.
- Contributors community: how many people contribute to the solution and for which entities they work with.
- Bugs activity: whether bugs are used and solved or ignored.
- Roadmap: is there a roadmap and how is it managed.
- Project Management: how is managed the project.
- Intellectual Property: what entity has intellectual property over the code.
- Distribution: whether the project is full open source or if there are components only available after subscription.
Here is the scoring table for these criteria.
| Criteria | Weight | Scoring |
|---|---|---|
| Development history | 1 | 0 if it is less than 3 months old, 1 if it is between 3 months and 3 years old, 2 if it is older than 3. |
| Development team | 1 | 0 if there are very few developers, 1 if there are some active developers, 2 if there are several active developers. |
| Popularity | 1 | 0 if no known user, 1 if there are known users, 2 if there is a lot of users. |
| Contributors community | 1 | 0 if no community or activity on forums, mailing-lists…, 1 if there exists a community with few activity, 2 if there is a community with several solution supporters. |
| Bugs activity | 1 | 0 for a weak activity or no bug tracking or release note with bug fixes, 1 if there is activity around bugs but no clear process, 2 if bugs are managed and their resolution governed by a clear process. |
| Roadmap | 1 | 0 if no published roadmap, 1 for a roadmap without planning, 2 for a roadmap that is published along with a planning. |
| Project Management | 1 | 0 for no clear management, 1 if the project is managed by a single person or company, 2 if the project is managed by a community. |
| Intellectual Property | 1 | 0 if it is owned by few persons or companies, 1 if it is owned by several persons or companies in an homogenous manner, 2 if it is owned by a Foundation or neutral legal entity trusted by developers. |
| Distribution | 1 | 0 if there is a free version with limited features only, 1 if the core is fully open source but extensions are proprietary, 2 if it is fully open source. |
Functional Requirements
- Single Sign-On (SSO): a same instance should allow a user to sign in once and access all the referenced applications. The focus is on web applications.
- Single Log-Out (SLO): signing out should sign out the user from all the referenced applications. The focus is on web applications.
- OIDC: support for Auth Code flow with PKCE: this is the flow LINAGORA uses for applications where back-end and front-end are delivered separately (e.g. single-page applications with REST services).
- Support of JWT access tokens: JWT access tokens must be supported by the solution.
- Specifics for mobile devices: authentication is not mandatory the same for web applications (see above) and mobile devices. There are generally 2 strategies considered: one is that the application directly authenticates against the ID provider. The other one is that the application starts a web browser: the user logs in through this web browser and the token is retrieved by the application. In both cases SSO is harder, unless the token is saved in some shared space on the device. Depending on the solutions, there may be supported tools and integration for mobile devices.
- Groups information: the solution should be able to indicate the groups a user belongs to (when getting the user information - “/me”).
- Identity brokering: the ability of the solution to connect with multiple service providers with (potentially) different identity providers. As an example, we may allow a user to connect with Github, Twitter or an internal identity provider.
- Default identity provider (brokering): assuming identity brokering is supported, we would like to be able to force the user to use a single one while delegating the authentication. As an example, for a customer with a SAML portal, we would like the user to be redirected to the SAML portal directly, without any web interface shown by the OIDC provider.
- Native identity management: can the solution manage authentication for users without any other identity provider (this is the opposite of identity brokering).
- Users management: for native management, the solution should allow to add, remove, edit or list users in the organization.
- Groups management: for native management, the solution should allow to add, remove, edit or list groups in the organization.
- Multi-factor authentication: does the solution support multi-factor authentication? Is it compliant with identity brokering?
- Password reset: how can a user reset his password? Explain the possibilities for identity brokering and for native identity management.
- Password policy: for native management, can we force a password policy? On which criteria?
- Theme customization: can the look’n’feel of the solution be customized?
Notice the management of technical accounts (machine to machine) is out of the scope of this study. This would be part of the global design for identity management.
Here is the scoring table for these criteria.
| Criteria | Weight | Scoring |
|---|---|---|
| Single Sign-On (SSO) | 1 | 0 if we cannot protect application, 1 if we can protect only one, 2 if there is no limit. |
| Single Log-Out (SLO) | 1 | 0 if the solution does not support, 1 if we can log out from only one application, 2 otherwise. |
| OIDC: support for Auth Code flow with PKCE | 3 | 0 if not supported, 2 if fully-supported. |
| Support of JWT | 3 | 0 if not supported, 1 if only supported for ID or access tokens, 2 if fully-supported. |
| Specifics for mobile devices | 1 | 0 if nothing is planned, 1 if it is only available for Android or iOS, 2 if there are solutions for both platforms. |
| Groups information | 1 | 0 if not supported, 2 if supported. |
| Identity brokering | 2 | 0 if not supported, 1 if supported for SAML or OIDC, 2 if supported for both SAML and OIDC. |
| Default identity provider (brokering) | 2 | 0 if not supported, 1 if it possible indirectly, 2 if supported. |
| Native identity management | 2 | 0 if not supported, 2 if supported. |
| Users management | 1 | 0 if not supported, 1 if possible indirectly, 2 if supported directly by the tool. |
| Groups management | 1 | 0 if not supported, 1 if possible indirectly, 2 if supported directly by the tool. |
| Multi-factor authentication | 3 | 0 if not supported, 2 if supported. |
| Password reset | 1 | 0 if not supported, 2 if supported. |
| Password policy | 1 | 0 if not supported, 2 if supported. |
| Theme customization | 1 | 0 if not supported, 1 if feasible but requires to overwrite files in the distribution, 2 if theming is natively designed (through configuration or a specific themes folder). |
Sure, a solution that does not support native identity management will get a bad score. But this is a feature that would simplify test in development environments (see farther).
Technical Requirements
- LDAP synchronization: we have customers who manage their users and organization in an LDAP solution. Whatever LINAGORA selects, it should provide a way to synchronize the contents of the LDAP with the repository used by the solution. Synchronization can mean direct connection, delegation or batched.
- SAML support: we have customers who manage authentication with SAML. For identity brokering, SAML should be supported.
Here is the scoring table for these criteria.
| Criteria | Weight | Scoring |
|---|---|---|
| LDAP synchronization | 1 | 0 if not supported, 2 if supported. |
| SAML support | 1 | 0 if not supported, 2 if supported. |
Requirements for Developers
- Ease of configuration: the configuration should be as easy as possible so that developers can tune it and experiment things.
Native identity management is also very appreciated for tests, but this criteria is already defined in the functional requirements. Here is the scoring table for these criteria.
| Criteria | Weight | Scoring |
|---|---|---|
| Ease of configuration | 1 | 0 if there is no web administration console, 1 if it exists but the OIDC configuration is spread under different root menus, 2 if it is located under a same menu. |
Requirements for Operations
- Official Docker images: the solution should provide and maintain official Docker images.
- Compliance with Docker best practices: the solution must be compliant with Docker (i.e. one process = 1 Docker image), use environment variables to customize the content, rely on small base images, etc. The study must audit quickly the Dockerfiles.
- Scaling: the solution should be able to scale, either by clustering or replicating instances. Being stateless would be even better.
- Configuration: how can it be configured? Through files, REST services or through a web console?
- HTTPS: it should be easy to secure the solution with a certificate.
- Logging: logs can be configured and are relevant.
- Statistics: does the solution provides some business statistics? Example: number of authentication per day.
- Multi-tenancy: can the solution authenticate users for different organizations? Or should we plan an installation per tenant? Some may talk about users federation.
- Database: which database the solution can work with? Using one that is natively distributed and that we already use would be better.
- Monitoring: the solution can be monitored with Prometheus, our monitoring solution. More generally, health probes can be defined.
- Software Dependencies: what Software components are necessary for the solution to work?
- K8s: is there any existing package for K8s?
- Documentation: is the documentation well-written and kept up-to-date?
- Resource Consumption: what is the minimal hardware configuration to run it?
Here is the scoring table for these criteria.
| Criteria | Weight | Scoring |
|---|---|---|
| Official Docker images | 1 | 0 if no official Docker image is provided, 1 if it exists but is not maintained or from the community (no release over the last 6 months), 2 otherwise. |
| Compliance with Docker best practices | 3 | 0 if no existing Docker image, 1 if LINAGORA should create a better one, 2 if it looks good. |
| Scaling | 3 | 0 if the solution only supports 1 instances, 1 if the solution requires specific environment constraints (such as multicast), 2 if the solution itself is stateless (e.g. the state is in the DB or another shared component). |
| Configuration | 1 | 0 if the solution can only be customized from a web console, 1 if it supports either REST services and configuration files, 2 if it supports both. |
| HTTPS | 1 | 0 if HTTPS cannot be configured, 1 if certificates are mandatory for the solution to work, 2 otherwise. |
| Logging | 1 | 0 if logging cannot be configured, 1 if logging’s configuration is spread in different locations, 2 otherwise. |
| Statistics | 1 | 0 if not supported, 2 otherwise. |
| Multi-tenancy | 2 | 0 if it only supports a single organization, 2 if several ones. |
| Database | 2 | 1 if it requires a relational DB, 2 if it can work with MongoDB or Cassandra. 0 otherwise. |
| Monitoring | 1 | 0 if there is no existing health probe, 1 if possible but to implement by LINAGORA, 2 if they exist and the solution is compliant with Prometheus. Tip: for Java solutions, the JMX exporter exists. |
| Software Dependencies | 1 | 2 if it only requires a database, 1 if it requires a 2 components, 0 if it requires more than 2. |
| K8s | 1 | 0 if no package exists, 1 if the only package that exists is an operator (black-box), 2 if there is a Helm package. |
| Documentation | 1 | 0 if there is no documentation, 1 if documentation is not clear or help hard to find, 2 if documentation and support are clear and easy to find. |
| Resource Consumption | 1 | 0 if it requires more than 4 CPU and 16 GB of RAM, 2 if it requires less than 2 CPU and 2 GB of RAM, 1 if it is between these two levels. |
Solutions to Compare
All the solutions below must be evaluated against the defined criteria.
Evaluation is based on information available on Internet. The goal is to get
a short-list of solutions to experiment in a second time.
In addition to scoring, every solution should be veridied against an overlap with the Twake Console. Indeed, some solutions go beyond just being an OIDC provider. They manage identities in a more global fashion.
Here are the solutions:
- LemonLDAP - just to compare the solutions against the current one
- KeyCloak
- KeyCloak-X
- Hydra (ORY)
- Kratos (ORY)
- WSO2 Identity Server
- oxAuth (Gluu)
- OpenAM
Other candidates could be found here.
Notice we are only interested in open source features.
Study
See here.