Provisionamento com SCIM

Com SCIM, o provedor de identidade cria, atualiza e desprovisiona as contas do Ronne sozinho, e mantém os papéis nos espaços de trabalho em sintonia com os grupos dele. Quando alguém sai, o provedor desativa a conta da pessoa na próxima sincronização: as sessões e os tokens de acesso dela terminam na hora, sem que o root precise se lembrar de fazer isso. Desprovisionar desativa uma conta; nunca a apaga, então os itens que a pessoa publicou mantêm o registro deles.

O SCIM é configurado por provedor, na página do provedor em Admin › Settings › Authentication, na seção Provisioning (SCIM). Ele não exige que o login do provedor esteja ativo, mas quem é criado pelo SCIM não tem senha: faz login pelo provedor.

• Os e-mails batem. O provedor envia o e-mail de cada pessoa como userName. Quem tem no Ronne um e-mail diferente desse ganha uma segunda conta, em que não consegue fazer login, enquanto a primeira fica fora do SCIM. Mude esses e-mails em Usuários antes; se uma segunda conta foi criada mesmo assim, apague a segunda depois de corrigir o e-mail.
• Contas existentes só são adotadas quando é seguro. Quando o provedor cria alguém que já tem uma conta, o Ronne só assume essa conta se o e-mail dela for exatamente o userName, se a pessoa tiver feito login por este provedor nos últimos 30 dias, se a conta nunca tiver sido vinculada pelo SCIM antes, se a conta não for root e se estiver ativada. Caso contrário, o provedor recebe um conflito (409) e a conta fica como está. Por isso, peça que as pessoas façam login pelo provedor nos 30 dias antes de você começar o provisionamento.
• Os grupos são atribuídos no SCIM. De agora em diante, o SCIM é a única fonte dos grupos deste provedor (Grupos do SCIM e papéis nos espaços de trabalho). Os papéis que o login deu continuam até a primeira mudança de grupo do provedor que inclua a pessoa, então envie os grupos mapeados.
• Quem saiu já está desativado. Quem saiu antes do SCIM, ou não está atribuído a ele no provedor, nunca é desprovisionado por ele: desative essas pessoas em Users.

1. Turn on SCIM e confirme. A seção mostra a URL base, https://ronne.example.com/api/v1/scim/v2, com Copy.
2. Generate token. Ele começa com scim_ e aparece uma vez só: o Ronne guarda apenas o hash dele. Cole-o nas configurações de SCIM do provedor, como token Bearer.
3. Siga os passos do seu provedor abaixo e depois comece o provisionamento lá.

A seção diz quando o token foi criado, por quem e quando foi usado pela última vez. Rotate cria um token novo e mantém o atual funcionando por 24 horas, para você trocá-lo no provedor com calma. Revoke o invalida na hora, e também o anterior a uma rotação. Turn off SCIM recusa todas as requisições na hora e mantém as contas, os vínculos, os grupos e o token, para quando você o ativar de novo. Uma requisição com um token errado, revogado ou antigo é recusada com 401, e a recusa fica no log de auditoria.

• Criar: uma conta nova, um user no global com um espaço de trabalho pessoal e sem senha, nunca root. O nome e o e-mail dela vêm do provedor.
• Atualizar: o nome e o e-mail. Enquanto o SCIM estiver ativo, o provedor é a única fonte deles: Users não tem como editá-los, e a próxima sincronização do provedor põe de volta o que ele diz.
• Desativar (active: false): a conta é desativada, as sessões dela terminam e os tokens de acesso dela são revogados, em um só passo. A próxima página que ela abrir é a página de login, e o rmk recebe 401. Os papéis dela nos espaços de trabalho continuam. Reativar (active: true) a ativa de novo; a pessoa volta a fazer login, e os tokens revogados continuam revogados.
• Excluir: a conta é desativada do mesmo jeito, perde todos os papéis nos espaços de trabalho que o provedor deu, e o SCIM deixa de gerenciá-la. Ela continua no Ronne, marcada como Deprovisioned by <provider>, desativada. Se o provedor criar a mesma pessoa de novo (o mesmo externalId), a mesma conta volta, ativada. O root pode então apagá-la pela página dela: desatribua a pessoa no provedor primeiro, ou a próxima sincronização cria uma conta nova, vazia.
• O root nunca é tocado: uma requisição sobre uma conta root é recusada, e um root em um grupo é deixado de fora. As contas root são gerenciadas no Ronne.

Em Usuários, essas contas mostram Managed by <provider>; uma adotada mostra também Adopted by <provider> on <date>, para você poder revisar cada adoção, e uma excluída, Deprovisioned by <provider> on <date>. Na página do usuário, Disable e Enable ainda funcionam, mas um aviso diz que a próxima sincronização do provedor desfaz a mudança: mude isso no provedor. Reset password dá uma senha a uma dessas contas, para quando o provedor não consegue fazer o login das pessoas.

Os grupos SCIM do provedor dão papéis nos espaços de trabalho pelos mesmos mapeamentos do login dele (Grupos e papéis nos espaços de trabalho), e pelas mesmas regras: um grupo mapeado dá, no espaço de trabalho do mapeamento, pelo menos o papel mapeado, o mais alto de dois vence, uma participação definida à mão nunca é mudada, nem o root, e ninguém sai do global. Um mapeamento casa com o nome de um grupo ou com o externalId dele, exatamente, então os mapeamentos feitos para a claim de grupos do Entra (object IDs) continuam funcionando.

• Quando o provedor adiciona alguém a um grupo, remove essa pessoa, renomeia o grupo ou o exclui, os papéis das pessoas que a mudança afeta acompanham na hora.
• Enquanto o SCIM estiver ativo, o login deste provedor não aplica mais a claim de grupos dele: o SCIM é a única fonte. Com o SCIM desativado, o login volta a aplicá-la.
• Ativar o SCIM, ou adotar uma conta, não muda nenhum papel. Os papéis que o login deu continuam até a primeira mudança de grupo do provedor que inclua a pessoa, que aplica os mapeamentos a partir dos grupos do SCIM.
• Uma pessoa excluída perde na hora todos os papéis que o provedor deu; uma desativada os mantém enquanto estiver desativada.
• Um grupo que nenhum mapeamento cita é mantido e não dá nada.

Cada mudança fica no log de auditoria como uma mudança de membro, marcada como do provedor.

1. No centro de administração do Entra, em Entra ID › Enterprise apps, abra o aplicativo do Ronne (ou New application › Create your own application, não pela galeria) e depois Provisioning.
2. Crie uma nova configuração com Bearer authentication: a URL base como Tenant URL e o token como Secret Token. Test Connection e depois crie-a.
3. Em Attribute mapping, para os usuários, mapeie objectId para externalId. O padrão do Entra, mailNickname, é um alias que pode ser dado a alguém novo, que então voltaria como a conta antiga. O externalId dos grupos já é o objectId deles.
4. Atribua os usuários e os grupos a provisionar em Users and groups e depois Start provisioning. O Entra sincroniza mais ou menos a cada 40 minutos; Provision on demand provisiona uma pessoa agora.

O Entra define active como false quando alguém perde a atribuição ou é desativado, e exclui a pessoa quando ela é excluída de vez.

1. Abra o aplicativo do Ronne (o OIDC de Okta). Na aba General, edite App Settings e escolha SCIM em Provisioning.
2. Na aba Provisioning, Integration: a URL base como SCIM connector base URL, userName como campo de identificador único dos usuários, as ações Push New Users, Push Profile Updates e Push Groups, e a autenticação HTTP Header com o token.
3. Em To App, ative Create Users, Update User Attributes e Deactivate Users.
4. Atribua as pessoas e depois envie os grupos que o Ronne mapeia, na aba Push Groups.

O Okta desativa as pessoas (active: false) e não as exclui.

1. Applications › Providers › Create › SCIM Provider, com a URL base como URL e o token como token.
2. Edite o aplicativo do Ronne e adicione o provider SCIM em Backchannel Providers. O authentik então envia ao Ronne as pessoas a que o aplicativo está vinculado (todo mundo, quando ele não está vinculado a ninguém) e os grupos, quando eles mudam e uma vez por hora.

O Keycloak não consegue enviar SCIM sozinho. Uma extensão da comunidade que provisione usuários e grupos para um servidor SCIM consegue: instale uma no Keycloak e passe a ela a URL base e o token como token Bearer. O time do Keycloak não dá suporte a essas extensões, então teste uma antes de confiar nela.

O Auth0 não tem um cliente SCIM para provisionar outro aplicativo: o SCIM dele é para receber usuários. Os Event Streams dele podem acionar um código seu que chame o SCIM do Ronne; se não, as pessoas ganham as contas ao fazer login pelo Auth0, e quem sai é desativado em Users.

Passe ao provedor a URL base e o token como token Bearer. Ele precisa enviar o e-mail da pessoa como userName e, como externalId, um id que nunca mude e nunca seja dado a outra pessoa. Os mapeamentos de grupos casam com o nome de um grupo ou com o externalId dele. Os Endpoints SCIM dizem o que o Ronne aceita.

O Ronne serve SCIM 2.0 (RFC 7643 e 7644) em https://ronne.example.com/api/v1/scim/v2, para os clientes dos provedores. Toda requisição, menos a de descoberta, precisa de Authorization: Bearer scim_…; as respostas são application/scim+json, e os erros usam o formato de erro do SCIM.

• Filtros: só eq: em userName, externalId e id para Users, e em displayName, externalId e id para Groups. Os e-mails são comparados em minúsculas.
• Users aceita userName (o e-mail, em ASCII simples), name ou displayName, externalId e active, e um PATCH de emails muda o e-mail; os outros atributos são ignorados. Papéis, senhas e os grupos de um usuário são só leitura: a participação muda pelos Groups. O id é o do vínculo SCIM, não o da conta; depois de um DELETE, ele responde 404 em todo lugar.
• PATCH aceita add, replace e remove, com um path ou como um objeto de valor, como o Entra e o Okta os enviam; "False" é lido como false. Os membros dos grupos são ids de usuário SCIM, removidos um a um com members[value eq "…"].
• Erros: 400 para uma requisição inválida (invalidValue, invalidSyntax, invalidFilter, invalidPath, noTarget, mutability para a remoção de active, de userName ou do displayName de um grupo), 401 para qualquer problema de token ou SCIM desativado, 403 para uma conta root, 404, 405 para um método que um caminho não aceita, 409 uniqueness para um userName, e-mail ou externalId já usado, 413 e 415 para um corpo grande demais ou que não é JSON, e 429 com Retry-After acima de 600 requisições por minuto por token.
• Sem suporte: operações em lote (bulk) e /Me (501), ordenação, ETags e troca de senhas.