SSO e provisionamento

O single sign-on (SSO) permite que os membros façam login no Bird pelo seu provedor de identidade em vez de usar uma senha Bird separada. O Bird suporta conexões SAML 2.0 e OpenID Connect (OIDC).

A configuração é uma tarefa do Owner da organização, e os controles ficam na página Single sign-on da sua organização. Um membro com a permissão de SSO pode gerenciar conexões sem ser Owner.

O login pessoal com Google ou GitHub é separado do SSO da organização. Veja Login, senha e MFA.

Como o SSO funciona

Uma conexão SSO cobre um ou mais domínios de e-mail verificados, como yourcompany.com. Membros nesses domínios se autenticam com o seu provedor de identidade. As permissões deles no Bird ainda vêm dos papéis na organização e no espaço de trabalho.

O que a configuração envolve

Um Owner da organização e um administrador do provedor de identidade completam a configuração:

1. Prove que você é dono do domínio. O Bird fornece um registro DNS para você publicar para cada domínio de e-mail coberto pela conexão. A aplicação obrigatória não pode ser ativada até que o domínio esteja verificado.
2. Configure a conexão. Para SAML, forneça os metadados do provedor de identidade, ou a URL de login e os certificados de assinatura. Para OIDC, forneça o emissor e as credenciais do cliente. Copie os dados de service-provider ou de redirecionamento do Bird para o seu provedor de identidade.
3. Teste a conexão. Faça um login de teste antes de ativar a conexão. Independentemente do protocolo escolhido, um rascunho cujo teste passa é ativado automaticamente, desde que a sua organização tenha um domínio verificado e esteja dentro do limite de conexões ativas.
4. Escolha se o SSO será obrigatório. Quando o SSO é opcional, os membros podem usar SSO ou outro método de login disponível. Quando é obrigatório, os membros precisam completar o SSO para acessar a organização. Exigir SSO requer uma conexão ativa e pelo menos um domínio verificado.

Exigir SSO entra em vigor imediatamente, em cada solicitação, e não apenas no próximo login. Um membro cuja sessão atual não foi estabelecida pelo seu provedor de identidade perde o acesso à organização até fazer login novamente por ele. Planeje a mudança de acordo com o dia da sua equipe em vez de anunciá-la depois. Os Owners da organização são a exceção: um Owner mantém o acesso com a senha Bird, e é isso que impede que uma conexão mal configurada bloqueie todo mundo.

Configure o seu provedor de identidade

O passo 2 é a metade que varia por provedor: o mesmo valor tem um nome diferente em cada um, e cada um tem uma configuração que recusa todos os logins se estiver errada. Os nomes dos campos do Bird são os que aparecem na página da conexão, em Register these with your identity provider.

• Configurar SSO com Okta
• Configurar SSO com Google Workspace
• Configurar SSO com Microsoft Entra ID

Para qualquer outro provedor SAML 2.0 ou OpenID Connect, os quatro passos acima são todo o contrato.

Configurando SAML sem valores provisórios

O Entity ID e a Assertion Consumer Service URL de uma conexão SAML são derivados da própria conexão, então eles não existem até você criá-la. Isso cria um ciclo: o seu provedor de identidade precisa desses valores, e eles precisam da conexão.

Crie a conexão primeiro. Em Add connection, escolha SAML e depois I have not set up my provider yet. A conexão é criada como rascunho sem detalhes do provedor de identidade, e ao abri-la você vê os valores para registrar em Register these with your identity provider. Configure o seu provedor com esses valores, depois volte e use Supply the details na mesma conexão, no formato que você tiver:

• uma metadata URL, que buscamos e lemos
• o documento de metadados em si, para um provedor que entrega um arquivo em vez de hospedá-lo
• o entity ID, URL de login e certificados de assinatura, inseridos diretamente

Um documento enviado é lido para extrair esses três valores e não é armazenado.

Até que os detalhes cheguem, a conexão permanece como rascunho: ela não atende logins e não pode ser ativada.

Como os membros são identificados

Uma conexão SAML identifica cada membro pelo NameID que o seu provedor envia, e esse identificador é permanente para qualquer pessoa que fizer login. A configuração da conexão não pergunta qual formato usar. Se você forneceu uma metadata URL ou documento, lemos o que o seu provedor anuncia ali e vinculamos a conexão a ele. Se você inseriu os detalhes manualmente, não há metadados para ler, então a conexão é vinculada a um ID permanente.

O que você controla é o valor por trás dele. Configure o nome de usuário do aplicativo no seu provedor como algo opaco e nunca reatribuído, e envie o endereço separadamente como um atributo email. Um endereço de e-mail como identificador é permanentemente mais fraco: se o endereço for reatribuído, a próxima pessoa que o receber herda a conta Bird.

Os metadados dizem o que o seu provedor pode enviar; a configuração do aplicativo decide o que ele de fato envia, e os dois podem divergir. Por isso, o login de teste no passo 3 informa o identificador e o formato que a asserção realmente trouxe, e esse relatório é como você verifica se os dois concordam antes de qualquer pessoa depender da conexão. Também recusamos um identificador rotulado como persistente que na verdade é um endereço de e-mail.

Se o teste reportar um formato que você não esperava, há duas formas de corrigir, e qual é a certa depende do que está errado:

• O provedor está enviando a coisa errada. Altere o nome de usuário do aplicativo no seu provedor e teste novamente. Essa normalmente é a correção certa, porque o identificador opaco é o que vale a pena manter.
• A conexão está vinculada à coisa errada. Abra Edit na conexão e altere o formato do NameID para o que o seu provedor envia.

Faça qualquer uma das correções antes de os membros começarem a fazer login. Depois que começarem, as contas deles estarão vinculadas ao identificador em vigor, então o formato fica fixo e a alteração é recusada. Crie uma conexão para o novo formato.

Substituindo um provedor

Os detalhes do provedor de identidade de uma conexão SAML podem ser substituídos enquanto ninguém tiver feito login por ela. Depois que membros a usarem, suas contas estarão vinculadas aos identificadores que o provedor atual envia, então a substituição é recusada. Crie uma conexão para o novo provedor. Em uma conexão OIDC, você pode rotacionar o client secret a qualquer momento, o que não muda o que identifica os membros, mas o provedor em si não pode ser substituído.

O login de teste no passo 3 não conta. Um teste não vincula nenhuma conta e não concede acesso, então uma conexão que você configurou e testou, mas ainda não disponibilizou para a sua equipe, ainda pode ser redirecionada.

O que muda para a sua equipe

Uma conexão pode conceder acesso padrão à organização e ao espaço de trabalho a um membro no primeiro login SSO bem-sucedido. Configure esse acesso padrão explicitamente; caso contrário, convide os membros e atribua papéis antes de eles fazerem login. Veja Usuários, equipes e papéis.

Suspender uma conexão impede novos logins por ela. Revise as associações no Bird e as sessões ativas separadamente quando alguém sair da empresa.

Próximos passos

• Login, senha e MFA: segurança da conta individual, incluindo login pessoal com Google/GitHub
• Usuários, equipes e papéis: como papéis e permissões funcionam depois que os membros estão dentro
• Autenticação e chaves API: a referência de autenticação para desenvolvedores