Page MenuHomeDevCentral

Evaluate Keycloak as identity and access management solution
Open, NormalPublic

Description

Keycloak offers an open source identity and access management solution. It's the upstream for RedHat IdM.

It seems fairly comprehensive as:

  • able to connect to a LDAP
  • expose a LDAP to help applications to authenticate users
  • offer SAML, a more modern way to do so
  • expose OIDC (OpenID connect)

The scope of evaluation would be:

  • do we need our own LDAP? (probably so not to be vendor-locked)
  • how to install and secure Keycloak?
  • how to connect applications and services to Keycloak?
  • can Keycloak be a source of truth for SSH keys? Is that desirable?
  • what UI do we expose to end users? Keycloak directly? an UI linked to Keycloak API? An UI linked to a LDAP or database, independent of Keycloak (not to be vendor-locked)?
  • how to manage multiple accounts?

Keycloak official site: https://www.keycloak.org/

Related Objects

Mentioned In
T2181: Onboard Sandrine in Nasqueron Operations SIG
T2179: Onboard philectro in Nasqueron Operations SIG
rOPS949369f27b20: Upgrade zenerre to PHP 8
D3606: Upgrade zenerre to PHP 8
T1791: Refresh Sentry installation
T338: Authenticate users against GitHub
T271: Deploy Auth Grove to login.nasqueron.org
T475: [Login capability] Discourse
T885: Offer a recover password feature for mailboxes
T270: Implement SSO on forum.nasqueron.org
T349: Add Wikimedia OAuth2 registration capability
T1472: Provide a 301 redirect for /.well-known/change-password
T343: Provide a migration path from Espace Win accounts to Nasqueron accounts
T344: Convert forum.nasqueron.org accounts into Nasqueron accounts
T345: Add registration capabilities
T468: Add account reset feature
T828: Implement local storage features
T336: Add login capabilities through external services
T480: CLI commands to manage accounts
T476: Implement subaccounts
T341: Authenticate users against BitBucket
T339: Authenticate users against Facebook
T342: Authenticate users against Google
T340: Authenticate users against Twitter
T348: Allow user accounts provisioning
T477: E-mail processing for subaccounts
T1399: Migrate from globalfunctions to OmniTools
T366: Implement mailcheck to check current mail error at register time
T1172: Generate HTML responsive transactional mails
T668: E-mail authentification
T1471: Set background-size cover CSS attribute to background images
T472: [Route] Print an error message on /auth/reset instead of return a 404.
T1501: Follow Chromium guidelines for password form fields
T471: Password reset token is only verified after a form with password is submitted
T478: Validate e-mail addresses
T1439: [Tests] Ensure tests have a database ource
T337: Authenticate users through OpenID
T1440: [Tests] Review installation procedure
T879: l10n: plural support
T347: Allow to register an account through a social login
T877: Validation rules hardcode 8 characters requirement for passwords
T905: UndoStack
T481: [CLI] Create new account
T1438: Fix tests to allow coverage reports for Laravel applications
Mentioned Here
T1772: Design LDAP schema for Nasqueron login and identity services

Event Timeline

dereckson triaged this task as Normal priority.Feb 16 2023, 19:20
dereckson created this task.
dereckson mentioned this in Unknown Object (Maniphest Task).Feb 16 2023, 19:30
dereckson mentioned this in T905: UndoStack.
dereckson moved this task from Backlog to Current focus on the Product evaluation board.

Assigning per previous comment: @MoustaphaAs is currently working on this.

One of the important thing to note is Keycloak federates user information from external storage.

https://www.keycloak.org/docs/latest/server_admin/index.html#_user-storage-federation

By default, that storage can be:

  • out of the box, LDAP
  • with custom development, any database

In T1772, we focus on a LDAP schema to adopt to store user account information.

The ideal road would be in that case to use that LDAP as primary external storage for Keycloak.

That can also explain the relationship between Auth Grove and Keycloak:

  • Auth Grove can be used to register and manage accounts, with LDAP as back-end
  • Keycloak then allow to login to other applications (direct keycloak login or auth grove login -> keycloak -> app)
  • Apps with LDAP support but without SAML/OIDC support can plug directly in the LDAP for login information

In that scenario:

  • Users interact primarily with Auth Grove UI
  • Keycloak is a bunch of redirect URLs between Auth Grove and the final app

Deployment plan would then be:

  • Design LDAP schema
  • Add LDAP storage back-end to Auth Grove code
  • Deploy Keycloak
  • Configure our LDAP as external storage