SSO da organização

Com o SSO da organização, as pessoas da sua empresa entram no Coda Cloud pelo provedor de identidade corporativo (IdP), como Entra ID, Okta ou Google Workspace, por OpenID Connect ou SAML 2.0. Quem é "da empresa" é definido pelos domínios de e-mail verificados da organização: o login, o provisionamento automático e o SSO obrigatório partem deles.

A configuração fica em Configurações › SSO da organização. A aba Domínios é de Owner e Admin; as demais abas (Conexão, Mapeamentos, Segurança e SCIM) são só do Owner. Nenhuma dessas rotas aceita token de API: a configuração de identidade é feita só pelo portal.

Planos

Recurso	Starter	Pro	Business	Enterprise
SSO da organização (sso.enabled)	não	não	sim	sim
Provisionamento SCIM (sso.scim)	não	não	não	sim

Sem o recurso, as abas aparecem desabilitadas com o aviso de upgrade e a API responde 403 plan.feature_unavailable. Se o plano mudar e o recurso deixar de valer, a conexão continua funcionando por 30 dias de carência, com aviso aos Owners e um banner com o prazo. Ao fim da carência, o login pelo IdP é desativado, o SSO obrigatório é desligado, os tokens SCIM são revogados e quem entrava só pelo SSO recebe um e-mail para definir uma senha. Nada da configuração é apagado: voltando ao plano, basta reativar a conexão. Veja Planos, recursos e limites.

1. Verifique os domínios

1. Em Domínios, cadastre o domínio de e-mail da empresa (por exemplo, empresa.com.br). Domínios de e-mail público (como gmail.com) são recusados, e um domínio já verificado por outra organização também.

2. Publique no DNS o registro TXT mostrado na tela:

   _atlas-verification.empresa.com.br  TXT  "atlas-domain-verification=<token>"

3. Clique em Verificar. Sem o registro, a verificação expira em 72 horas.

Cada subdomínio que tiver e-mails é cadastrado à parte. A plataforma reverifica os domínios todos os dias: se o registro TXT sumir por 7 dias seguidos, o domínio volta a Falhou, deixa de direcionar o login ao IdP e os Owners recebem um e-mail. Mantenha o registro publicado.

2. Conecte o IdP

Em Conexão, escolha o protocolo. O formulário mostra os dados que você cadastra no IdP:

• OIDC: a URL de redirecionamento (https://auth.<domínio da plataforma>/realms/atlas/broker/<alias>/endpoint). Informe a URL de discovery (termina em /.well-known/openid-configuration), o client ID, o client secret, os escopos e o claim de grupos.
• SAML 2.0: o entity ID, a URL ACS e a metadata do provedor de serviço. Informe a URL da metadata do IdP ou cole o XML (até 512 KB), e os atributos de e-mail, nome, sobrenome e grupos. As asserções precisam ser assinadas: metadata sem certificado de assinatura é recusada.

A plataforma busca e valida a discovery ou a metadata e configura o login em alguns segundos. A conexão passa de Configurando para Ativa; se algo estiver errado, ela fica Com erro e o campo com problema é indicado. URLs que apontem para endereços privados, da nuvem ou sem https são recusadas.

O client secret é repassado só ao provedor de identidade da plataforma: o Coda Cloud não o guarda, e ele nunca é exibido de novo, nem na auditoria. A tela mostra apenas quando ele foi configurado. Para trocar, informe um novo; deixar em branco mantém o atual.

3. Teste a conexão

Em Segurança › Testar conexão, entre pelo IdP com uma conta de um domínio verificado. O resultado (sucesso, ou falha com o motivo, como e-mail fora dos domínios verificados ou atributo de e-mail ausente) fica registrado com data e autor, e a página do resultado mostra o e-mail, o nome e os grupos que a plataforma recebeu. Depois do teste, a sessão do navegador passa a ser a da conta usada no IdP; saia e entre de novo com a sua conta de Owner para continuar a configuração.

Como as pessoas entram

A tela de login pede primeiro o e-mail. Se o domínio estiver verificado numa organização com conexão ativa, o navegador segue para o IdP da empresa; nos demais casos, a tela pede a senha, como antes. A descoberta nunca revela se uma conta existe.

Você também pode divulgar os atalhos:

• /sso: a pessoa digita o e-mail corporativo e segue para o IdP certo;
• /sso/<slug-da-organização>: o login já começa no IdP da organização.

Quem já tem conta com senha e entra pelo IdP pela primeira vez com o mesmo e-mail precisa confirmar a senha (ou o link por e-mail) antes de a identidade externa ser vinculada. Nada é vinculado automaticamente.

Provisionamento automático (JIT)

Com o JIT ligado (padrão), a primeira entrada pelo IdP com e-mail de domínio verificado cria a conta e a associação à organização, com origem SSO, mesmo que a plataforma esteja no modo de cadastro só por convite. O papel vem do mapeamento de grupos ou do papel padrão da conexão (Member por padrão, sem acesso a projetos até receber uma concessão; o máximo é Admin). Com o JIT desligado, só entra quem tem convite ou foi criado pelo SCIM.

Mapeamento de grupos

Em Mapeamentos, associe cada grupo do IdP (nome exato, com maiúsculas e minúsculas como no IdP) a um papel na organização (Admin, Developer, Viewer ou Member), a um time ou aos dois. A cada login pelo IdP, quem entrou pelo SSO recebe o maior papel mapeado dos seus grupos (ou o papel padrão) e exatamente os times mapeados; as concessões de projeto dos times passam a valer na hora. Quem sai de um grupo no IdP perde o papel e o time no próximo login (ou na hora, com SCIM).

• O papel Owner nunca é atribuído por grupo; ele só muda pelo fluxo manual.
• Associações criadas manualmente ou por convite não são alteradas pelos grupos.

SSO obrigatório

Com o SSO obrigatório ligado, membros com e-mail de domínio verificado só acessam a organização com sessões abertas pelo IdP dela. Uma sessão por senha recebe 403 sso.required, e o portal mostra o aviso com Entrar com SSO. Tokens de API pessoais desses membros só valem se tiverem sido criados numa sessão do IdP da organização.

Não são afetados: convidados de outros domínios, contas de serviço e as outras organizações da mesma pessoa.

Para ligar, a conexão precisa estar Ativa, com ao menos um domínio verificado e um teste seu bem-sucedido nas últimas 24 horas. Isso evita trancar a organização com um IdP mal configurado.

Owners de emergência

Até 2 Owners podem ser designados como de emergência: eles entram sem o IdP (por exemplo, com o IdP fora do ar), sempre com MFA. Sem MFA, a resposta é 403 sso.break_glass_mfa_required. Cada sessão de emergência fica registrada na auditoria (sso.break_glass.used).

Convidados

Com a política de convidados em Bloquear, convites para e-mails fora dos domínios verificados são recusados (400 sso.domain_not_allowed). Quem já é membro não é removido.

SCIM 2.0

Com o SCIM (Enterprise), o diretório corporativo cria, atualiza e desativa as pessoas da organização. Em SCIM, copie a URL base (https://<api>/scim/v2/orgs/<id da organização>) e crie um token (prefixo atl_scim_, exibido uma única vez, validade de até 1 ano, no máximo 2 ativos). Configure-os no aplicativo SCIM do IdP.

• Users: listar (filtros userName eq e externalId eq), criar, ler, substituir, alterar (PATCH) e remover. Só e-mails de domínios verificados são aceitos.
• Groups: criar, renomear, alterar membros e remover. A pertença a grupos SCIM alimenta o mesmo mapeamento de grupos, aplicado na hora.
• Uma pessoa criada pelo SCIM entra como membro no primeiro login pelo IdP, com o papel dos grupos SCIM, mesmo com o JIT desligado.
• Desativar (active=false) ou remover uma pessoa tira a associação à organização em até 60 segundos e revoga os tokens de API pessoais com acesso a ela. Se a pessoa não pertencer a nenhuma outra organização, a conta é desabilitada e as sessões são encerradas.

Auditoria

Toda mudança de domínio, conexão, mapeamento, SSO obrigatório, Owner de emergência e token SCIM, cada provisionamento JIT, cada sincronização de papel e cada operação SCIM que altere uma associação gera um evento na trilha de auditoria da organização, sem segredos nem tokens. Nas operações SCIM, o ator é o prefixo do token SCIM.