Provedores de identidade

O Ronne pode deixar as pessoas fazerem login com o provedor de identidade da sua empresa (OpenID Connect): Google Workspace, Microsoft Entra ID, Okta, Keycloak, authentik, Auth0 ou qualquer outro que publique um documento de descoberta. O root o configura em Admin › Settings › Authentication, no navegador: nada a digitar no servidor.

1. Adicione um provedor a partir do preset dele, registre o Ronne no provedor com a URI de redirecionamento que o formulário mostra e traga de volta os valores que ele pede (Adicionar um provedor).
2. Teste-o: Test connection, depois Test sign-in com a sua própria conta no provedor. Nada muda até ele ser ativado.
3. Ative-o. A página de login mostra Continue with <name>.

Quando alguém faz login com ele, o Ronne decide quem a pessoa é, nesta ordem:

• O provedor precisa dizer que o e-mail está verificado; se não, a pessoa é recusada.
• Uma conta desativada é recusada.
• Quem já fez login com este provedor antes é essa mesma conta, mesmo que o e-mail tenha mudado no provedor.
• Se não, uma conta com exatamente esse e-mail é vinculada e faz login, se o provedor vincula por e-mail e o domínio do e-mail é um dos que ele lista (a conta do root também). A senha dela continua funcionando também.
• Se não, se o domínio do e-mail for um dos que o provedor lista, uma conta nova é criada: um user no global, com um espaço de trabalho pessoal e sem senha, nunca root.
• Qualquer outra pessoa é recusada, com uma mensagem para falar com o root.

Depois, os grupos do provedor são aplicados, e a sessão dura no máximo 24 horas e termina quando o navegador fecha, então quem é desativado no provedor normalmente perde o acesso em até um dia. Para cortar o acesso de alguém na hora, desative a conta no Ronne: isso encerra as sessões e os tokens. Com SCIM, o provedor faz isso na próxima sincronização. O login em duas etapas não é pedido: o provedor pede a sua própria segunda etapa. O root decide se os outros ainda podem usar uma senha (Login com senha), e o root sempre pode fazer login com uma (Bloqueio).

Em Admin › Settings › Authentication › Identity providers, escolha Add provider e depois o cartão do seu provedor. O formulário preenche o que o preset sabe e, ao lado dele (embaixo, no celular), ficam os passos a seguir no provedor. Cada preset tem o seu próprio guia abaixo.

• Provider id: de 3 a 32 letras minúsculas, dígitos e hifens, começando e terminando com uma letra ou um dígito. Ele faz parte da URI de redirecionamento, então não pode ser mudado depois.
• A URI de redirecionamento, https://ronne.example.com/api/auth/sso/callback/<id>: registre-a no provedor exatamente como aparece, com Copy. O provedor manda as pessoas de volta para esse endereço depois do login, e só para um endereço registrado nele, por isso ela precisa ser igual: ela é montada a partir do endereço público da instância (PUBLIC_URL) e do id.
• Display name, no botão de login; a URL do issuer (exatamente como o documento de descoberta do provedor a escreve, barra final incluída; o preset a monta a partir das partes que pede), o client ID e o client secret, e os scopes (openid email profile, mais um scope de grupos de que alguns provedores precisam).
• O client secret é guardado criptografado e nunca mais aparece: o formulário diz Secret saved, com Replace.
• Who may sign in: os domínios de e-mail com que esse provedor faz login, e se as contas existentes são vinculadas pelo e-mail verificado. Um endereço novo nesses domínios ganha uma conta no primeiro login; uma conta existente com um deles é vinculada se a vinculação estiver ligada. Uma conta de outro domínio nunca é vinculada, então um provedor não consegue tomar um endereço que não é dele. Vazio: só fazem login as contas já vinculadas.
• Groups: a claim de grupos e os mapeamentos de grupos (Grupos e papéis nos espaços de trabalho).

Depois, na página do provedor:

1. Test connection confere o documento de descoberta do provedor, se ele cita o issuer que você digitou, e as chaves dele, e diz o que encontrou.
2. Test sign-in abre o provedor em uma nova aba: faça login lá com a sua própria conta. De volta à página, o Ronne mostra o que recebeu (o e-mail e se ele está verificado, o nome, os grupos) e o que um login de verdade faria com isso (entrar, vincular, criar ou recusar, e quais papéis nos espaços de trabalho mudam). Ele não muda nada.
3. Turn on exige um Test sign-in aprovado, feito por você, das configurações como estão agora. Mudar depois o issuer, o client, o secret ou os scopes o desativa até ele passar de novo.

O painel mostra o estado de cada provedor: Off, Tested, On ou Failing (o último teste falhou, três logins seguidos falharam, ou o secret dele não pode ser lido depois de uma restauração), e quando alguém fez login com ele pela última vez. Turn off impede logins com ele; os vínculos e as participações em grupos continuam. Delete o remove: as contas vinculadas a ele continuam e ainda podem usar uma senha se tiverem uma, e os papéis nos espaços de trabalho que os grupos dele deram são removidos (no global, voltam a user). Toda mudança fica no log de auditoria.

Erros comuns, com qualquer provedor: uma URI de redirecionamento que difere por uma barra ou por http/https; um issuer sem a barra final que o documento dele tem (ou com uma que ele não tem); um e-mail que o provedor não marca como verificado; e uma claim de grupos que o aplicativo não envia. O Test sign-in mostra cada um.

Um provedor pode dar papéis nos espaços de trabalho a partir dos grupos dele. No formulário do provedor, defina a claim de grupos (normalmente groups; o preset sabe) e depois adicione linhas: grupo → espaço de trabalho → papel (user, moderator ou admin). Um grupo é escrito exatamente como o provedor o envia, com maiúsculas e minúsculas.

A cada login com o provedor:

• Cada grupo mapeado de que a pessoa faz parte dá a ela, no espaço de trabalho do mapeamento, pelo menos o papel mapeado. Dois grupos que dão o mesmo espaço de trabalho dão o papel mais alto.
• Um papel que um grupo deu é retirado quando a pessoa sai do grupo (ou cai para o que outro grupo ainda dá), no próximo login dela. Apagar o último mapeamento faz o mesmo.
• Uma participação que alguém definiu à mão nunca é mudada, nem para subir. Quando alguém muda uma participação que um grupo deu (em Members), ela passa a ser dessa pessoa: os grupos a deixam em paz.
• No global, de que ninguém sai, um grupo pode subir o papel user simples que todos têm; quando o grupo deixa de valer, o papel volta a user.
• O root nunca é mudado por grupos, e os grupos nunca tornam ninguém root.
• Uma claim de grupos ausente não muda nada. O Entra a omite acima de 200 grupos: atribua ao aplicativo só os grupos que o Ronne mapeia.
• Um mapeamento cujo espaço de trabalho foi apagado é ignorado, e o formulário avisa. Espaços de trabalho pessoais não podem ser mapeados.

Cada mudança fica no log de auditoria como uma mudança de membro, marcada como do provedor. O Test sign-in lista as mudanças que os seus próprios grupos fariam.