Kanidm: Identity Provider Moderno Self-Hosted para PME
Neste artigo
1. Introdução — Kanidm vs FreeIPA
O Kanidm é um servidor de identidade moderno, escrito em Rust, desenhado desde o início para ser seguro por defeito, rápido e fácil de operar. Ao contrário de soluções legadas como o FreeIPA, que herda décadas de complexidade de 389-DS e Kerberos, o Kanidm oferece uma arquitectura limpa com API REST nativa, suporte integrado para WebAuthn e sem dependência de LDAP como protocolo primário.
Para PME que precisam de um identity provider self-hosted mas não querem a complexidade de um Directório Activo completo, o Kanidm preenche o espaço entre soluções minimalistas (como Authentik) e monolitos empresariais. O facto de ser escrito em Rust garante segurança de memória por construção — uma vantagem significativa face a componentes C herdados.
| Característica | Kanidm | FreeIPA |
|---|---|---|
| Linguagem | Rust (memory-safe) | C / Python |
| Protocolo primário | API REST + WebAuthn | LDAP + Kerberos |
| WebAuthn nativo | Sim, integrado | Não (requer OTP externo) |
| Replicação | Automática (backend DB) | 389-DS multi-master |
| Complexidade de instalação | Baixa (1 binário ou container) | Alta (vários serviços) |
| OAuth2 / OIDC | Integrado | Requer Keycloak adicional |
ℹ Kanidm não substitui Active Directory
O Kanidm foi desenhado para ambientes sem GPOs ou integração profunda com Windows. Para infraestruturas heterogéneas com estações Windows geridas, o FreeIPA com confiança de fé ou o próprio AD podem ser mais adequados. O Kanidm brilha em ambientes Linux/cloud-native.
2. Instalar Kanidm (Docker e Binário)
O Kanidm pode ser instalado de duas formas principais: via Docker (recomendado para produção) ou via binário nativo (ideal para testes e ambientes minimalistas). Ambas as formas requerem configuração através de um ficheiro server.toml ou client.toml.
2.1 Instalação com Docker
A imagem oficial do Kanidm está disponível no GitHub Container Registry. O método recomendado usa Docker Compose para gerir volumes e rede de forma declarativa.
# /etc/kanidm/server.toml
bindaddress = "0.0.0.0:8443"
ldapbindaddress = "0.0.0.0:3636"
db_path = "/data/kanidm.db"
tls_chain = "/data/chain.pem"
tls_key = "/data/key.pem"
domain = "idm.empresa.pt"
origin = "https://idm.empresa.pt"
# docker-compose.yml
version: "3"
services:
kanidm:
image: ghcr.io/kanidm/kanidmd:latest
ports:
- "8443:8443"
- "3636:3636"
volumes:
- /opt/kanidm/data:/data
- /opt/kanidm/config:/config
restart: unless-stopped
# Iniciar o servidor
docker compose up -d
# Verificar logs
docker compose logs -f kanidm
# Inicializar base de dados (primeira vez)
docker compose exec kanidm kanidmd server \
-c /config/server.toml
2.2 Instalação via Binário
Para distribuições Linux, o Kanidm fornece pacotes pré-compilados. Em Debian/Ubuntu, pode-se instalar directamente o binário a partir dos releases oficiais no GitHub.
# Descarregar binário (exemplo x86_64)
wget https://github.com/kanidm/kanidm/releases/\
download/v1.4.0/kanidm-linux-x86_64.tar.gz
tar xzf kanidm-linux-x86_64.tar.gz
sudo mv kanidmd /usr/local/sbin/
sudo mv kanidm /usr/local/bin/
# Criar estrutura de directórios
sudo mkdir -p /var/lib/kanidm /etc/kanidm
# Gerar certificados TLS (obrigatório)
sudo kanidmd cert generate \
--domain idm.empresa.pt \
--outpath /var/lib/kanidm
# Serviço systemd: /etc/systemd/system/kanidm.service
[Unit]
Description=Kanidm Identity Provider
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/sbin/kanidmd \
server -c /etc/kanidm/server.toml
Restart=on-failure
User=kanidm
[Install]
WantedBy=multi-user.target
# Activar e iniciar
sudo systemctl daemon-reload
sudo systemctl enable --now kanidm
sudo systemctl status kanidm
💡 Dica
O Kanidm exige TLS em todas as ligações. O comando kanidmd cert generate cria certificados auto-assinados para testes. Em produção, usar Let’s Encrypt ou CA interna com certificados válidos.
3. Configurar LDAP e OAuth2
O Kanidm suporta LDAP como protocolo legado para compatibilidade com aplicações existentes, mas a sua API primária é REST. O OAuth2/OIDC está integrado nativamente, permitindo configurar clientes SSO sem componentes adicionais como Keycloak.
3.1 LDAP para compatibilidade
O LDAP no Kanidm escuta na porta 3636 (LDAPS) e requer ligações cifradas. Não suporta bind anónimo — todas as ligações devem ser autenticadas.
# Testar ligação LDAP com ldapsearch
ldapsearch -H ldaps://idm.empresa.pt:3636 \
-D "[email protected]" \
-W \
-b "dc=idm,dc=empresa,dc=pt" \
"(objectClass=person)" cn mail
# Criar conta de serviço para LDAP
kanidm service-account create \
--name admin \
ldap_sync \
"Conta LDAP para sincronização"
# Gerar API token para a conta de serviço
kanidm service-account api-token generate \
--name admin \
ldap_sync \
"LDAP sync token"
3.2 OAuth2 / OpenID Connect
A configuração de clientes OAuth2 faz-se inteiramente via CLI ou API REST. Cada cliente recebe um client ID e secret, com URLs de redireccionamento explícitas.
# Criar cliente OAuth2 para aplicação web
kanidm system oauth2 create-basic \
--name admin \
grafana \
"Grafana SSO" \
https://grafana.empresa.pt/login
# Definir URL de redireccionamento
kanidm system oauth2 set-redirect-url \
--name admin \
grafana \
https://grafana.empresa.pt/login/generic_oauth
# Definir scopes permitidos
kanidm system oauth2 set-scope-map \
--name admin \
grafana \
grafana_users openid email profile
# Gerar secret do cliente
kanidm system oauth2 get-basic-secret \
--name admin \
grafana
# Endpoints OIDC expostos
# Authorization:
# https://idm.empresa.pt/ui/oauth2
# Token:
# https://idm.empresa.pt/oauth2/token
# UserInfo:
# https://idm.empresa.pt/oauth2/openid/grafana/userinfo
# Discovery:
# https://idm.empresa.pt/oauth2/openid/grafana/.well-known/openid-configuration
⚠ Atenção aos grupos
O Kanidm não envia grupos no token JWT por defeito. É necessário configurar set-claim-map para incluir informação de grupos nos claims, caso a aplicação dependa de membership para autorização.
4. WebAuthn e RADIUS
O WebAuthn é um cidadão de primeira classe no Kanidm — não um plugin ou extensão. Cada utilizador pode registar múltiplos autenticadores (YubiKey, Titan, Windows Hello, Touch ID) directamente através da interface web, sem intervenção do administrador. Isto elimina a necessidade de TOTP ou aplicações de autenticação separadas.
4.1 Registo de autenticadores WebAuthn
O registo é feito através do portal web do Kanidm. O utilizador navega para as definições de conta e adiciona um security key. O servidor gera o desafio WebAuthn e o browser faz a mediação com o autenticador.
# Listar autenticadores registados (CLI admin)
kanidm person credential-status \
--name admin \
[email protected]
# Forçar registo de security key via CLI
kanidm person credential-register \
--name admin \
--method securitykey \
[email protected]
4.2 RADIUS com Kanidm
O Kanidm inclui um servidor RADIUS nativo que pode autenticar ligações Wi-Fi (WPA2-Enterprise), VPN e switches de rede. A integração usa as credenciais do utilizador no Kanidm, com suporte para WebAuthn quando o cliente suporta EAP-TEAP.
# /etc/kanidm/radius.toml
bindaddress = "0.0.0.0:1812"
origin = "https://idm.empresa.pt"
kanidm_url = "https://idm.empresa.pt"
[authentication]
# Tipo de autenticação RADIUS
auth_type = "password"
[clients]
# Cliente RADIUS (access point / VPN)
[clients.wifi-ap]
secret = "raioSecretForte123!"
ipaddr = "192.168.10.0/24"
# Iniciar servidor RADIUS
kanidmd radius -c /etc/kanidm/radius.toml
# Testar com radclient
echo "User-Name=joao.silva, \
User-Password=senha123" | radclient \
idm.empresa.pt:1812 auth \
raioSecretForte123!
ℹ Grupos para autorização RADIUS
Crie um grupo radius_users e atribua-o aos utilizadores que devem ter acesso Wi-Fi/VPN. Configure o filtro RADIUS para negar autenticação a utilizadores fora do grupo, garantindo controlo de acesso centralizado.
5. Integração com PAM/NSS e SSO
A integração com sistemas Linux para autenticação de sessão (login, sudo, SSH) faz-se através do Kanidm Unix Client, que fornece módulos PAM e NSS. Para SSO web, as aplicações usam OAuth2/OIDC directamente. A tabela seguinte resume os métodos de integração disponíveis.
| Método | Protocolo | Casos de uso | Configuração |
|---|---|---|---|
| PAM/NSS | Unix socket + API | Login SSH, sudo, sessão local | kanidm_unixd + nss_kanidm |
| OAuth2/OIDC | HTTPS / OIDC | Grafana, Nextcloud, Gitea | Client ID + secret + redirect |
| LDAP | LDAPS (porta 3636) | Aplicações legadas, impressoras | Service account + bind DN |
| RADIUS | RADIUS (porta 1812) | Wi-Fi WPA2-Enterprise, VPN | radius.toml + cliente RADIUS |
| SCIM | REST / SCIM 2.0 | Sincronização com HR/IdP externo | API token + endpoint SCIM |
5.1 Configurar PAM/NSS
O kanidm_unixd é o daemon que faz a ponte entre o Kanidm e os módulos PAM/NSS do Linux. Corre como serviço local e mantém um cache de utilizadores e grupos.
# /etc/kanidm/unixd.toml
pam_allowed_login_groups = ["linux_admins"]
cache_timeout = 15
default_shell = "/bin/bash"
home_prefix = "/home/"
home_attr = "uuid"
home_alias = "spn"
# Configurar NSS: /etc/nsswitch.conf
passwd: files kanidm
group: files kanidm
shadow: files kanidm
# PAM: /etc/pam.d/common-auth (Debian/Ubuntu)
auth sufficient pam_kanidm.so
auth required pam_unix.so try_first_pass
# PAM: /etc/pam.d/common-account
account sufficient pam_kanidm.so
account required pam_unix.so
# Iniciar daemon
sudo systemctl enable --now kanidm-unixd
# Verificar utilizadores remotos
getent passwd [email protected]
id [email protected]
5.2 SSO web com OAuth2
Para aplicações web, o SSO configura-se apontando a aplicação para os endpoints OIDC do Kanidm. Exemplo para Grafana:
# /etc/grafana/grafana.ini
[auth.generic_oauth]
enabled = true
client_id = grafana
client_secret =
scopes = openid email profile
auth_url = https://idm.empresa.pt/ui/oauth2
token_url = https://idm.empresa.pt/oauth2/token
api_url = https://idm.empresa.pt/oauth2/openid/grafana/userinfo
allow_sign_up = true
role_attribute_path = contains(groups[*], 'grafana_admins') && 'Admin' || 'Viewer'
✓ Resumo da configuração
Para uma PME típica: (1) instalar Kanidm via Docker, (2) criar utilizadores e grupos via CLI, (3) registar autenticadores WebAuthn no portal web, (4) configurar PAM/NSS nos servidores Linux, (5) ligar aplicações web via OAuth2. Em poucas horas, toda a infraestrutura passa a ter identidade centralizada sem palavras-passe partilhadas.
O Kanidm representa uma abordagem moderna a identity management: segura por construção (Rust), sem palavras-passe (WebAuthn nativo), com API REST como protocolo primário. Para PME que operam principalmente em Linux e cloud, é uma alternativa séria ao FreeIPA com significativamente menos complexidade operacional.