Configuração de SSO (Single Sign-On)
Delegue a autenticação do Cord ao provedor de identidade da sua empresa (Okta, Google Workspace, Azure AD).
Segurança empresarial
À medida que as organizações crescem, gerenciar usuários e senhas individualmente se torna um risco impossível de controlar. O Cord oferece integrações SSO via SAML 2.0 com motor próprio (não uma caixa de seleção cosmética): validação de assinatura XML-DSig, controle de replay, provisionamento automático de contas, mapeamento de funções por atributo e um mecanismo de emergência se o seu provedor de identidade falhar.
Ao habilitar o SSO na sua organização do Cord:
- Os seus funcionários entram automaticamente se já estiverem autenticados no portal corporativo de trabalho.
- Qualquer política de MFA que você já exija no seu provedor de identidade (Okta, Azure AD, Google Workspace) é herdada: o Cord delega a autenticação por completo, então nunca vê nem gerencia esse segundo fator.
- Ativar “Exigir SSO” bloqueia senha, Google, Apple e chaves de acesso para todos os membros, exceto o proprietário da conta, que sempre mantém a senha como alternativa — o único caminho de entrada que não depende de o seu IdP estar disponível.
- A exigência é da sua organização, não da conta: alguém que também pertence a outra organização com SSO próprio não pode entrar por esse SSO e depois trocar para a sua. Ao abrir a sua organização, o Cord pede que essa pessoa entre com o seu provedor de identidade.
Pré-requisitos
- A sua organização deve estar no plano Scale do Cord ou superior (Developer) — o SSO não está disponível no Grátis, no Starter nem no Profissional.
- Você precisa da permissão
equipo(equipe) na sua função do Cord (Proprietário e Administrador a têm por padrão; uma função personalizada também pode tê-la). - Você deve ter privilégios de Administrador no seu provedor de identidade (Okta, Azure AD / Microsoft Entra, Google Workspace ou qualquer IdP SAML 2.0).
Onde configurar
Configurações › Equipe e permissões › SSO (não fica em Segurança — o SSO faz parte do mesmo grupo que Equipe e funções, porque gerencia quem entra na organização, e compartilha a permissão equipo).
Etapas de configuração SAML
A troca é bidirecional, mas a ordem real inverte o que muitos esperam: primeiro você passa ao Cord os dados do seu IdP, e o Cord gera os dele a partir daí — não o contrário.
- No seu provedor de identidade, crie um novo aplicativo SAML para o Cord e baixe ou copie o XML de metadados dele (a maioria dos IdPs o expõe em uma URL pública ou em um botão “Download metadata”).
- No Cord, em Configurações › Equipe e permissões › SSO › Conectar provedor, dê um nome à conexão e cole esse XML. O Cord o interpreta automaticamente: extrai o Entity ID do IdP, a URL de login, o(s) certificado(s) X.509 de assinatura e, se existir, a URL de Single Logout — não é preciso digitar esses campos manualmente (embora o detalhe da conexão os deixe editáveis depois, caso o seu IdP rotacione o certificado).
- Com a conexão criada, o Cord mostra três valores próprios da sua organização: a ACS URL (Assertion Consumer Service — para onde o seu IdP deve enviar a resposta SAML), o Entity ID do Cord e a URL de metadados. Volte ao seu provedor de identidade e preencha-os no aplicativo que você criou na etapa 1.
- Teste com um único usuário antes de exigir SSO para toda a equipe — um mapeamento de atributos incorreto pode deixar todo o seu pessoal sem acesso (locked out).
Provisionamento e funções, não só login
O SSO no Cord não é só “entrar de outro jeito” — ele decide automaticamente qual conta é criada e com qual função:
- Provisionamento JIT (Just-in-Time): ativado por padrão. Na primeira vez que alguém entra por esta conexão, o Cord cria a conta e a adiciona à organização no mesmo login — não é preciso convidar a pessoa manualmente em Equipe antes.
- Mapeamento de funções por atributo: defina regras do tipo “se o atributo
groupsque o meu IdP envia contiverfinance-admin, atribua a função Administrador”. Cada regra compara um atributo SAML (equals,containsouregex) com um valor e uma função do Cord; elas são avaliadas em ordem e vale a primeira que corresponder. Se nenhuma se aplicar, a conta recebe a função padrão que você configurar para a conexão (p. ex. Somente leitura). - Login iniciado pelo IdP: você pode permitir que um funcionário entre diretamente pelo portal de aplicativos do IdP (Okta, MyApps da Microsoft), sem passar antes por
cordhq.app. Como esse acesso não começou no navegador dele, o Cord mostra com qual e-mail ele vai entrar e pede que confirme com Continuar antes de abrir a sessão.
Domínios verificados (opcional, recomendado)
Você pode vincular uma conexão SSO a um ou mais domínios de e-mail (suaempresa.com) por meio de um registro TXT no seu DNS — o mesmo padrão de verificação de um domínio de e-mail de saída. Com pelo menos um domínio verificado, só os e-mails desse domínio podem entrar por essa conexão; sem nenhum verificado, a conexão não restringe por domínio.
Se o seu provedor de identidade falhar (break-glass)
Com “Exigir SSO” ativo, um provedor de identidade fora do ar deixa toda a organização sem acesso — exceto o proprietário da conta. Se o restante da equipe precisar entrar temporariamente com senha, o proprietário pode usar o botão de emergência na mesma tela: ele se autentica de novo com a senha e desativa a exigência de SSO por 1 hora. Passada a hora (ou se você a reativar antes manualmente), a exigência volta sozinha.
Importante: Teste a integração com um único usuário antes de ativar “Exigir SSO” para toda a equipe — um erro de mapeamento de atributos pode deixar todo o seu pessoal sem acesso (locked out), exceto o proprietário da conta.