MFA obrigatório, SSO SAML/OIDC, SCIM (Preview)

Selo de estado: Preview (teto atual do produto) · Curso ACD-240 — Administração, segurança e governança · Aula 5 de 10 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai explicar JIT provisioning e limites — e separar o que já é obrigatório hoje (MFA) do que é Preview e depende de homologação com IdP real (SSO e SCIM).

Vídeo#

Identificador no manifesto: acd-240-05-mfa-sso-scim · duração-alvo 7 min · tela do produto: /settings.

Roteiro de gravação (5 capítulos):

#	Minutagem-alvo	Capítulo	Tela do produto
1	0:00–0:45	Abertura: autenticação (quem é você) × RBAC (o que faz) × RLS (quais linhas vê).	`/settings` → Acesso
2	0:45–2:30	MFA (TOTP) é obrigatório para todo acesso logado: QR Code, app autenticador, confirmação. E o limite duro: não há recuperação.	`/mfa/setup`
3	2:30–4:10	SSO SAML 2.0 / OIDC e JIT provisioning: o primeiro login cria o membro. Estado `Preview`, Scale+, inerte até ser ligado (503).	`/settings` → Acesso
4	4:10–5:50	SCIM 2.0: o IdP empurra criação/atualização/desativação; grupo → papel; `DELETE` desativa, nunca apaga dado. Exemplo sintético.	`/settings` → Integrações e chaves
5	5:50–7:00	Exemplo Aurora, erros comuns e o "faça você mesmo" (leitura do exemplo SCIM sintético).	`/settings` → Acesso

Conteúdo#

MFA não é opcional — e não tem volta

Autenticação decide quem é você. As formas disponíveis são Google (com restrição opcional por domínio Workspace), e-mail + senha (hash scrypt, definida no cadastro) e MFA por TOTP — além do login pelo udiApps e do SSO corporativo, os dois em Preview.

Na versão implementada, MFA é obrigatório para qualquer acesso logado: entrar sem segundo fator configurado leva direto à tela de configuração, e não há como sair dela para o produto. Cada pessoa configura o próprio autenticador — escaneia o QR Code, registra no app (Google Authenticator, Authy, 1Password…) e confirma o código de 6 dígitos. O segredo é guardado cifrado (AES-256-GCM) e nunca sai em relatório, DSAR ou log.

Três limites que mudam o seu runbook

1. Não existe recuperação de MFA — nem por autoatendimento, nem por ação de admin, owner ou suporte dentro do produto. Quem perde o app autenticador fica sem caminho de volta pela interface. Guarde a semente ao configurar. 2. Não existe troca nem redefinição de senha no produto: a senha é definida no cadastro; trocar depois é caso de suporte. 3. A marca "exigir MFA de um membro" existe no cadastro, mas não tem efeito: nenhum caminho de login a consulta, e ela não dispensa ninguém — o MFA já é obrigatório para todos.

Vale também saber que a cifra em repouso descreve o que é gravado hoje: o leitor ainda tolera semente legada em texto plano para não quebrar o login de quem registrou o MFA antes da cifra, e não há migração retroativa. Reativar o MFA (desativar e ativar de novo) regrava a semente cifrada.

SSO com JIT provisioning (Preview)

Com SSO (SAML 2.0 / OIDC), a pessoa entra pelo provedor de identidade da empresa (Okta, Microsoft Entra ID, Google Workspace…) sem senha local. O JIT provisioning é o detalhe que mais confunde: o primeiro login já cria o membro no workspace, com o papel resolvido pelo grupo do IdP — ninguém precisa convidar a pessoa antes. Grupo desconhecido no mapa cai em viewer (menor privilégio), e o papel do dono não é rebaixado por sincronização de grupo.

SCIM 2.0: o IdP empurra (Preview)

Enquanto o SSO resolve a entrada, o SCIM 2.0 mantém a base sincronizada: o IdP empurra criação, atualização e desativação de pessoas, e mapeia grupos → papéis. A autenticação do SCIM é por service principal (token sp_live_…), não por chave de dados, e o escopo do provisionamento é sempre o workspace/org do próprio service principal — nunca o que vier da URL ou do corpo. Isso é o anti-acesso-cruzado: um IdP não provisiona em organização alheia.

Método · rota	Efeito
`GET /Users` (+`?filter=`)	lista membros (filtro `userName`/`externalId eq`)
`POST /Users`	provisiona membro (papel resolvido pelos grupos)
`PUT` / `PATCH /Users/{id}`	substitui atributos; `active:false` → desativa
`DELETE /Users/{id}`	deprovisioning seguro → desativa (nunca apaga dados)
`GET /Groups` · `PATCH /Groups/{id}`	grupos mapeados; add → papel do grupo, remove → `viewer`

Deprovisioning é sempre não-destrutivo: DELETE e PATCH active:false desativam o membro — ele perde o acesso na hora — mas não apagam dados. Remoção de dados é o fluxo separado e explícito de exclusão, assunto da aula 9.

Exemplo: a Aurora ligando o IdP

Na Comércio Aurora, Maria (owner) entra com Google; João (admin) usa e-mail + senha e, por operar fontes e pessoas, tem MFA ativo — login pede senha e o código do momento. Quando o Grupo Aurora decide centralizar no IdP, o operador liga o SSO no ambiente, mapeia o grupo "BI-Admins" → admin e "BI-Leitores" → viewer. No primeiro login de ana@example.com pelo IdP, o JIT cria o membro com o papel do grupo dela. Desativada no IdP, Ana fica disabled no ingestia — o acesso cai, os dados permanecem.

Ação	viewer	member	admin	owner	org_admin
Configurar o próprio MFA (obrigatório)	✓	✓	✓	✓	✓
Gerir pessoas (`member.manage`)	—	—	✓	✓	—
Criar o service principal do SCIM (`apikey.manage`)	—	—	✓	✓	—
Configurar SSO/SCIM do workspace	—	—	—	✓	✓
Zerar o MFA de outra pessoa	—	—	—	—	—

A última linha não é erro de diagramação: nenhum papel zera o segundo fator de outra pessoa dentro do produto.

Erros comuns

Código TOTP sempre inválido: relógio do celular fora de hora. Sincronize a hora automática.
"Login recusado com a senha certa": MFA ativo e código ausente/errado.
Contar com recuperação de MFA num plano de continuidade. Ela não existe no produto.
Esperar que SSO/SCIM funcionem "porque estão documentados": ambos ficam inertes até serem ligados de propósito no ambiente — a rota responde 503 em produção, e nunca finge provisionar. 401 no SCIM significa token que não é service principal válido.
Pessoa entrou com papel errado: o grupo do IdP não está no mapa; grupo desconhecido cai em viewer por projeto.
Confundir desativar com excluir: o IdP desativa; dado só sai pelo fluxo de exclusão.

Estado do produto

Login por Google/e-mail-senha e o MFA TOTP são cobertos por testes; o teto público é Preview. SSO (SAML/OIDC com JIT) e SCIM 2.0 são Preview: funcionam, são documentados, são fail-closed e escopados por workspace — mas estão sem SLA e a homologação com IdP real (SAML com criptografia real e desprovisionamento de ponta a ponta) é um gate ainda pendente. Por plano, SSO/SCIM é Scale+. Enquanto a homologação não acontecer, trate os dois como caminho a ser planejado, não como garantia contratada.

Faça você mesmo#

No workspace de treino Aurora Varejo (abra /settings no console):

Confirme no seu próprio perfil que o MFA está ativo — e anote que não foi uma escolha: é obrigatório para qualquer acesso logado.
Escreva o seu procedimento de guarda da semente do autenticador (onde fica, quem tem acesso). Lembre: não há recuperação no produto.
Em Acesso, localize a marca "exigir MFA" no cadastro de um membro e anote por que ela não tem efeito.
Leia o exemplo SCIM sintético da doc de SSO e SCIM (POST /Users com userName: "ana@example.com"). Anote: qual credencial autentica a chamada e de onde vem o escopo do provisionamento.
Escreva o mapa de grupos do IdP → papéis para a Aurora: "BI-Admins" → admin, "BI-Leitores" → viewer. Anote o que acontece com um grupo fora do mapa.
Explique em duas frases o que o JIT provisioning faz no primeiro login — e por que isso dispensa o convite manual da aula 3.
Responda por escrito: o que acontece com os dados de alguém desativado via DELETE /Users/{id}?
Anote o estado de SSO e SCIM (Preview), o plano mínimo (Scale) e o gate pendente (homologação com IdP real).

Você terminou quando conseguir explicar, sem consultar a doc, o que o JIT provisioning cria, por que o deprovisioning do SCIM nunca apaga dado, e quais são os três limites do MFA (sem recuperação, sem troca de senha, marca sem efeito).

Checagem rápida#

Três perguntas no final da aula, corrigidas no servidor. A aula só conta como concluída depois da checagem.

Documentação relacionada#

Capacidades ensinadas#

C12.3 · C12.4 — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".