SSO (OIDC)

O RMM DataDike aceita login via OIDC (OpenID Connect) contra qualquer provedor compatível. Uma vez habilitado, os usuários da organização entram com o mesmo login que já usam para Microsoft 365, Google Workspace, Okta, etc. — sem senha extra pro RMM.

Aberta em /sso.

Provedores testados

• Microsoft Entra ID (Azure AD)

• Google Workspace

• Okta

• Keycloak (auto-hospedado)

• Qualquer IdP OIDC 1.0 com discovery (/.well-known/openid-configuration)

Setup rápido

1. No IdP: registre um novo aplicativo/client OIDC. Configure o redirect URI para o valor mostrado na página de SSO do RMM.

2. No RMM: em Platform Admin → Single Sign-On, escolha o provedor, cole o Issuer URL, Client ID e Client Secret. Marque Enable e salve.

3. Teste o botão "Sign in with SSO" na tela de login.

JIT Provisioning

Ligado por padrão. Quando um usuário faz login pela primeira vez via SSO e o email dele não existe no RMM, criamos a conta automaticamente com permission group default (configurável).

• Se você não quer que qualquer usuário do IdP entre, desmarque "Allow JIT provisioning" — só quem já tiver conta pré-criada consegue entrar.

• Se você quer restringir por domínio de email, preencha "Required domain" (acme.com) — só emails desse domínio são aceitos.

Segurança de trânsito

• Fluxo Authorization Code + PKCE

• State e nonce aleatórios validados na callback

• Client secret criptografado com AES-256-GCM em repouso (chave SETTINGS_ENCRYPTION_KEY)

• Token OIDC nunca sai do backend — o browser recebe apenas o cookie de sessão do RMM

O usuário nunca perde acesso pelo SSO

Mesmo com SSO habilitado, o login via senha + MFA continua funcionando — SSO é um caminho adicional, não substituto. Se o IdP cair, seus admins ainda entram pela via padrão.

Convivência com MFA

Se o IdP já força MFA, você pode desligar o MFA no RMM para usuários SSO. Alternativamente, o Conditional Access por grupo (requireMfa) obriga MFA independentemente do caminho de login — útil para admins de alto privilégio.

Multi-tenant

Cada organização configura seu próprio IdP. Não há SSO global. Um usuário que troca de organização precisa passar pelo fluxo de convite normal — não há cross-tenancy possível via SSO.

Auditoria

• Cada login SSO é gravado no Audit Log com IP, provider, timestamp e resultado

• Reinvocação: LOGIN_SSO

• JIT provisioning gera evento USER_JIT_PROVISIONED

• Falhas (nonce mismatch, domain mismatch, etc.) também são registradas