Pessoas, papéis e SSO do Console

O Console é onde o time da sua empresa governa a memória: fontes e chaves, identidade, comprovantes, privacidade, regras e medição. Toda pessoa entra com um token de 15 minutos, emitido pelo plano de controle, que nomeia um espaço e os papéis dela nele. Esta página cobre quem entra, com que papel e por qual caminho: e-mail e senha com segundo fator, ou o login único (SSO) da empresa, por OIDC ou SAML 2.0.

​

Papéis

Os papéis se combinam, e cada um vale no tenant inteiro ou num espaço só. O tenant mantém sempre ao menos uma pessoa com admin no tenant inteiro: uma mudança de papel ou uma desativação que deixaria o tenant sem ela responde 409.

​

Como uma pessoa chega

Por convite. Em Pessoas e papéis, um admin informa o e-mail e os papéis (POST /v1/users, sem senha). A resposta traz um link de uso único, que vale por sete dias e aparece uma vez só; a Niadra guarda apenas um hash com chave dele. A pessoa abre o link, escolhe a senha (12 caracteres ou mais) e, no primeiro login, configura o aplicativo autenticador pelo QR code e guarda dez códigos de recuperação, mostrados uma vez. Pelo SSO. Quando o domínio do e-mail pertence ao SSO da empresa, não há convite: no primeiro login pelo provedor de identidade, a pessoa é criada na hora, sem senha, com os papéis dos grupos dela. Senha esquecida. O admin gera um link novo; os links anteriores param de valer, e a senha atual continua valendo até o link novo ser usado.

​

Segundo fator

No login com senha, o segundo fator é obrigatório por padrão: o código de seis dígitos de um aplicativo autenticador (TOTP). Quem perde o celular entra com um dos dez códigos de recuperação, cada um uma vez só. Em Sua conta, a própria pessoa gera códigos novos e troca de aplicativo, depois de confirmar a senha de novo; quem perdeu o aplicativo e os códigos pede a um admin que redefina o segundo fator, com o motivo registrado.

​

Desativar e reativar

Uma pessoa desativada não entra mais, e o plano de controle recusa a sessão dela na próxima chamada. As células conferem os tokens sem consultar o controle, então um token já emitido vale na API de dados até vencer, em 15 minutos no máximo. Convites abertos param de valer. Ninguém desativa a si mesmo nem o último admin do tenant. A reativação devolve os mesmos papéis, a mesma senha e o mesmo segundo fator. Cada mudança no acesso de uma pessoa fica no histórico dela, com quem fez e por quê: convites, papéis, desativação, redefinição do segundo fator e o que o SSO fez num login.

​

Login único (SSO)

Cada tenant tem uma conexão, por OpenID Connect ou por SAML 2.0, que responde por uma lista de domínios de e-mail. Quem digita um e-mail desses domínios no login do Console vê Entrar com SSO.

​

O que a Niadra confere

Nos dois casos, o e-mail precisa estar num dos domínios da conexão, e um e-mail que já pertence a outro tenant é recusado.

​

Configurar

1. No Console, com o papel Administração, abra Login único (SSO) e escolha o protocolo.
2. Cole no provedor de identidade o que a tela mostra:
   • OIDC: a URI de redirecionamento, https://control.api.niadra.com/v1/auth/sso/oidc/callback;
   • SAML: o entity ID, urn:niadra:sso:<tenant_id>, a URL do assertion consumer service, https://control.api.niadra.com/v1/auth/sso/saml/<tenant_id>/acs, ou os metadados de uma vez.
3. Traga do provedor, para o Console:
   • OIDC: o emissor, o client ID e o client secret. O segredo fica cifrado com AES-256-GCM no plano de controle e nunca volta numa resposta;
   • SAML: o entity ID do provedor, a URL de login e o certificado de assinatura.
4. Informe os domínios de e-mail, onde vêm os grupos (a declaração ou o atributo groups, por exemplo) e quais grupos dão quais papéis.
5. Salve desligado, use Testar o login e, com o resultado certo, ligue.

Pela API, é PUT /v1/sso.

​

Papéis vindos dos grupos

Cada grupo mapeado dá o papel dele no tenant inteiro, e a comparação ignora maiúsculas. Quem não está em nenhum grupo mapeado recebe o papel padrão; sem papel padrão, o login é recusado. Os papéis são recalculados a cada login pelo SSO: o provedor de identidade é onde o acesso se administra, e uma mudança feita no Console vale até o próximo login pelo SSO. Os grupos nunca tiram o papel admin da última pessoa que o tem. O papel vendor nunca vem de um grupo: ele nomeia fontes, e chega por convite.

​

O login, passo a passo

1. O Console pede o e-mail, e POST /v1/auth/sso/discover responde pelo domínio, sem dizer se a pessoa existe.
2. Em Entrar com SSO, o Console sorteia um valor, manda só o SHA-256 dele para POST /v1/auth/sso/start e guarda o valor nesta aba do navegador. O navegador vai para o provedor.
3. O provedor responde ao plano de controle, que confere a resposta e devolve o navegador para o Console com um código de login no fragmento do endereço, a parte depois de #, que nunca chega a um servidor. O código vale dez minutos e uma vez só.
4. O Console troca o código, junto com o valor guardado, pelo token em POST /v1/auth/sso/exchange, e apaga o valor. Um código sem o valor guardado não abre nada.

Um login recusado volta ao Console com o motivo: provedor negou, tempo esgotado, resposta inválida, domínio fora da conexão, nenhum papel, e-mail de outra empresa, pessoa desativada, provedor fora do ar ou SSO desligado.

​

Como fica o MFA com SSO

Quem entra pelo SSO passa pelo MFA do provedor de identidade da empresa, com as regras que a empresa já definiu lá. A Niadra confere a resposta assinada do provedor, mas não enxerga qual fator a pessoa usou. Se a sua política pede mais, ligue Pedir também o código da Niadra: depois do provedor, o Console pede o código do aplicativo autenticador, com códigos de recuperação, e a pessoa configura o aplicativo no primeiro login (POST /v1/auth/sso/second-factor). Uma pessoa criada pelo SSO não tem senha na Niadra: em Sua conta, o código do aplicativo faz o papel da senha. O login com e-mail e senha continua com o segundo fator obrigatório da Niadra.

​

Só pelo SSO

Com Só pelo SSO ligado, pessoas dos domínios da conexão não entram com senha (401 “single sign-on required”). Quem tem admin no tenant inteiro mantém a senha e o segundo fator, como acesso quando o provedor falhar.

​

Testar

POST /v1/sso/test devolve o endereço de um login de teste, para abrir em outra aba. Quando o provedor responde, GET /v1/sso/tests/{test_id} mostra o e-mail, os grupos e os papéis que o login daria, e se a pessoa já existe. Ninguém é criado e nenhum papel muda, e o teste funciona com a conexão ainda desligada.

​

Limites

Os domínios não passam por verificação de DNS: são únicos entre tenants, e só a Niadra cria tenants, sob contrato. Não há provisionamento por SCIM: as pessoas chegam por convite ou pelo primeiro login no SSO. No Microsoft Entra ID, os grupos chegam pelo id de objeto, e uma conta em grupos demais (mais de 200 no OIDC, mais de 150 no SAML) não os traz no token; atribua à aplicação só os grupos que dão papéis.