Categoria: Identitat i accés
Keycloak: inici de sessió únic (SSO) per a la vostra empresa
Un sol inici de sessió per a totes les aplicacions de la vostra empresa, amb doble factor, baixes que tallen l'accés a l'instant i un servidor d'identitat que és vostre.
- On es munta
- Al vostre compte, a nom vostre
- Còpies
- Amb restauració provada
- Actualitzacions
- Planificades i documentades
En resum
Keycloak és un servidor d'identitat de codi obert, amb llicència Apache 2.0, que ofereix inici de sessió únic (SSO) per OpenID Connect i SAML. L'instal·lem al vostre compte, organitzem els realms i les aplicacions, activem el doble factor, el federem amb el vostre LDAP, Active Directory, Google o Microsoft, el muntem en alta disponibilitat i ens ocupem de les actualitzacions i les còpies.
De què ens encarreguem?
Keycloak es converteix en la porta d’entrada a tota la resta: si va lent, tot va lent; si cau, no entra ningú. Per això el tractem com la peça més crítica de la plataforma.
Realms i clients
Cada aplicació connectada amb el seu protocol, els seus rols i les seues adreces de retorn permeses.
Doble factor
Codis d’un sol ús, claus de seguretat i passkeys, obligatoris on calga.
Federació
LDAP o Active Directory com a origen d’usuaris, o Google i Microsoft com a proveïdors d’identitat.
Base de dades
PostgreSQL replicat: guarda la configuració i, en les versions actuals, també les sessions.
Clúster
Diversos nodes amb la seua memòria cau distribuïda, darrere d’un balancejador.
Vigilància
Mètriques i registres d’inicis de sessió, errors i atacs de força bruta.
Quina arquitectura recomanem?
Per a una empresa, un únic clúster de Keycloak amb almenys dos nodes, repartits en zones de disponibilitat diferents si el proveïdor en té, i una base de dades amb replicació síncrona. Els nodes comparteixen una memòria cau distribuïda amb Infinispan, integrada en Keycloak, per a les sessions d’autenticació. La documentació oficial descriu també arquitectures amb diversos clústers en llocs diferents; només les proposem quan la caiguda d’un centre de dades sencer no és acceptable, perquè dupliquen la càrrega de la base de dades.
| Realm | Per a qui | Inici de sessió |
|---|---|---|
| Empleats | Plantilla i col·laboradors | Federat amb Active Directory, Google o Microsoft, amb doble factor obligatori |
| Clients | Usuaris del vostre producte o portal | Registre propi, inici de sessió social opcional i política de contrasenyes |
| Administració | Qui gestiona Keycloak | Molt pocs comptes, doble factor amb clau de seguretat |
Quins problemes trobem en autoallotjar Keycloak?
- Consola d’administració oberta a internet: el realm mestre accessible des de qualsevol lloc.
- Un sol node: cada reinici per actualització deixa tota l’empresa sense poder entrar.
- Configuració feta a mà: ningú no sap quin client es va crear per a què, ni pot tornar a crear-lo.
- Adreces de retorn amb comodins: un client accepta redireccions a qualsevol domini.
- Versions molt antigues: instal·lacions anteriors al canvi a Quarkus que ja no reben pegats.
- Base de dades sense còpia: la configuració de tots els realms viu en una sola màquina.
Com protegim, copiem i actualitzem Keycloak?
Copiem la base de dades de Keycloak fora del proveïdor i exportem la configuració dels realms al vostre repositori, per a poder tornar a crear-los encara que la base de dades no hi siga. Restaurem periòdicament en un entorn de prova i comprovem que es pot iniciar sessió en una aplicació de prova.
Keycloak trau versions sovint i, des que es basa en Quarkus, cada actualització migra l’esquema de la base de dades en arrancar. Abans d’actualitzar llegim la guia d’actualització de la versió, fem còpia, provem en un entorn a part amb la configuració real i després actualitzem node a node quan la versió ho admet; si no, amb una parada curta en una finestra avisada. Restringim la consola d’administració a xarxes concretes, activem la protecció contra força bruta i vigilem els inicis de sessió fallits des del monitoratge amb Grafana i Prometheus.
Quines aplicacions s’hi poden connectar?
Qualsevol que parle OpenID Connect o SAML: GitLab, Gitea, Grafana, Argo CD, SonarQube, les vostres aplicacions pròpies i molts serveis en el núvol. Per a les que no ho admeten, un proxy d’autenticació al davant fa el mateix paper. La llicència de Keycloak és Apache 2.0: no hi ha cost per usuari ni llicència per comprar.
Keycloak o Authentik?
Tots dos donen inici de sessió únic amb OpenID Connect i SAML i doble factor, i tots dos es munten al vostre compte. Les diferències reals són aquestes:
- Keycloak (Apache 2.0, projecte de la CNCF): més madur amb molts usuaris i en identitat de clients, amb alta disponibilitat ben documentada i suport comercial disponible si el necessiteu. La seua consola és més àrida i la configuració, més extensa.
- Authentik (nucli amb llicència MIT i una part Enterprise de pagament): consola més amable, fluxos d’inici de sessió que es dibuixen i un proxy integrat per a protegir aplicacions internes que no saben res de SSO, a més de servir LDAP a les que només parlen això.
La nostra recomanació: per a una empresa amb moltes eines internes i un equip xicotet que l’administrarà, Authentik sol encaixar millor. Si la identitat és crítica, hi ha milers d’usuaris o clients que inicien sessió en el vostre producte, Keycloak. Gestionem qualsevol dels dos amb la mateixa cura: còpies de la base de dades, actualitzacions provades i la consola d’administració tancada.
On ho muntem?
Al vostre compte, al proveïdor que ja feu servir o al que encaixe millor. Si les dades s'han de quedar a la UE, Hetzner i OVHcloud són les opcions europees.
Proveïdors on ho muntem
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propi
| Proveïdor | Com ho muntem | A tindre en compte |
|---|---|---|
| Hetzner | Diversos nodes de Keycloak en servidors cloud o en Kubernetes, amb PostgreSQL replicat gestionat per nosaltres, perquè Hetzner no té base de dades gestionada. | El balancejador de Hetzner reparteix entre nodes; la base de dades és la peça que més cuidem. |
| AWS | Keycloak en ECS o EKS, amb RDS o Aurora PostgreSQL darrere d'un balancejador d'aplicació. | Base de dades en diverses zones de disponibilitat. |
| Google Cloud | Keycloak en GKE o Compute Engine, amb Cloud SQL per a PostgreSQL en alta disponibilitat. | Encaixa si l'inici de sessió dels empleats ja va amb Google. |
| Azure | Keycloak en AKS o màquines virtuals, amb Azure Database for PostgreSQL. | Es federa amb Microsoft Entra ID perquè els empleats entren amb el seu compte. |
| DigitalOcean | Keycloak en Droplets o en DOKS, amb PostgreSQL gestionat de DigitalOcean. | |
| OVH | Keycloak en Public Cloud o Managed Kubernetes, amb base de dades gestionada d'OVHcloud. | |
| Servidor propi | Keycloak i PostgreSQL en els vostres servidors, al costat del vostre Active Directory. | Si Keycloak cau, ningú no entra enlloc: ací l'alta disponibilitat importa més que en cap altra aplicació. |
Què inclou
- Keycloak al vostre compte del núvol o en el vostre servidor, amb la configuració de realms i clients en codi.
- Realms separats per ús, per exemple empleats i clients, amb les seues pròpies polítiques.
- Doble factor amb aplicació de codis o claus de seguretat i passkeys (WebAuthn).
- Federació amb LDAP o Active Directory, o inici de sessió amb Google o Microsoft.
- Connexió de les vostres aplicacions per OpenID Connect o SAML, amb rols i grups.
- Alta disponibilitat amb diversos nodes i base de dades replicada.
- Còpies de la base de dades i exportació de la configuració dels realms, amb restauració de prova.
- Actualitzacions seguint la guia oficial, amb prova prèvia en un entorn a part.
Preguntes freqüents
Keycloak és una bona alternativa open source a Auth0 o Okta?
Per a la majoria d'usos d'empresa, sí: SSO, doble factor, federació i gestió de rols. La diferència és que l'heu d'operar vosaltres, o algú per vosaltres. A canvi, no pagueu per usuari actiu i les dades d'identitat es queden al vostre compte.
Com es migra d'Auth0 a Keycloak sense que la gent haja de canviar la contrasenya?
Hi ha dos camins. Si Auth0 us lliura els hashos de contrasenya, s'importen en Keycloak amb l'algorisme corresponent. Si no, es fa una migració progressiva: cada persona es valida contra el sistema antic la primera vegada que entra i queda creada en Keycloak. El que no es migra es resol amb un restabliment de contrasenya.
Keycloak ens ajuda amb NIS2 o amb l'ENS?
Ajuda amb una part: doble factor, control d'accés per rols, baixes centralitzades i registre d'inicis de sessió són mesures que demanen tots dos. Però cap eina no compleix la norma per si sola; també calen procediments, inventari i gestió d'incidents.
Qui dona d'alta els usuaris?
Si Keycloak està federat amb el vostre directori, les altes i baixes es fan allí i Keycloak les aplica. Si no, la persona administradora de la vostra empresa les gestiona des de la consola. Nosaltres mantenim el servidor i la configuració.
Expliqueu-nos el vostre cas
En una trucada gratuïta de 20 minuts veiem on sou i per on començar. Sense compromís.
Documentació oficial consultada
Les dades tècniques d'aquesta pàgina es basen en:
Revisat el