Acessos que acompanham as mudanças da sua organização

O SSO funciona com qualquer provedor de identidade compatível com SAML 2.0 ou OIDC, incluindo Okta, Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud, Rippling, Ping Identity e Auth0. O provisionamento SCIM segue o padrão SCIM 2.0 e aceita os formatos de requisição do Okta e do Entra ID, as combinações mais comuns. Outros clientes SCIM 2.0 também funcionam se filtrarem com uma única condição de igualdade, já que o Basedash não suporta operações em lote, ordenação nem ETags.

O SCIM sincroniza usuários, grupos e associações a grupos. De cada usuário, ele leva o e-mail (o userName do SCIM, que não pode mudar depois do provisionamento), o primeiro nome, o nome de exibição, o cargo, o status ativo e o ID externo do seu diretório. Os grupos são criados, renomeados e excluídos a partir do provedor de identidade, e adicionar ou remover alguém lá atualiza a associação no Basedash. Papéis e permissões não são sincronizados: quem é provisionado entra como membro, e os admins decidem no Basedash o que cada grupo acessa.

Os grupos sincronizados viram grupos do Basedash, e um admin concede acesso a cada um. As permissões de cada fonte de dados definem quem pode consultá-la no chat, nos dashboards, nas exportações, no editor SQL e nas variáveis, e os dashboards podem ser compartilhados com grupos específicos. No Postgres, o Basedash também passa os grupos de quem pergunta para o banco na variável de sessão basedash.groups, para que as políticas de segurança em nível de linha filtrem o que cada resposta de IA pode ler. Embeds para os seus clientes são limitados por tokens assinados, como explicado em embedding.

Quando o seu provedor de identidade desativa ou remove a atribuição de alguém, ele envia uma requisição SCIM e o Basedash desativa a associação dessa pessoa à organização assim que ela chega. A pessoa perde o acesso aos dados da organização e os chats abertos são restringidos na hora, então o tempo depende só da rapidez do seu provedor. Dashboards, gráficos e histórico de auditoria continuam lá para o time. Um delete via SCIM também desativa em vez de apagar, provisionar o mesmo e-mail de novo restaura a mesma associação, e o último admin ativo não pode ser desativado.

Sim. Depois que o SSO é configurado para um domínio verificado, qualquer pessoa com e-mail nesse domínio precisa entrar ou se cadastrar pelo seu provedor de identidade. Você adiciona o domínio nas configurações, verifica com um registro DNS TXT e pode deixar que pessoas desse domínio entrem na organização automaticamente. Organizações que não usam SAML podem exigir que todos os membros entrem com o Google.

SSO e SCIM fazem parte do plano Enterprise, junto com os logs de auditoria, e só admins da organização podem configurá-los. Eles também estão incluídos nos deploys self-hosted, em que o SCIM usa os mesmos endpoints na sua própria URL base, sem variáveis de ambiente extras. Se as requisições SCIM retornarem 403 Forbidden, o token é válido, mas a organização não tem um plano com provisionamento. Veja o Enterprise para o restante do plano, ou o self-hosting para rodar o Basedash na sua infraestrutura.

Um admin da organização abre Configurações, depois Segurança, e cria um token SCIM com nome. Ele começa com bd_scim_ e só aparece uma vez, porque o Basedash guarda apenas um hash. No Okta ou no Entra ID, crie um app SCIM 2.0, defina a URL base https://charts.basedash.com/scim/v2 e use o token como bearer token. Teste a conexão e atribua as pessoas e os grupos que precisam de acesso. Para rotacionar, crie um novo token, troque no provedor, teste e revogue o antigo.