AdministraçãoIntegrações

SSO com SAML 2.0

Federe a WASViking com o seu IdP usando SAML 2.0. Mapeamento de atributos, política de papel padrão e um passo a passo para o Google Workspace.

A WASViking^® implementa SAML 2.0 como Service Provider (provedor de serviço). Autentique a sua equipe pelo seu provedor de identidade (IdP), com mapeamento de atributos e propagação opcional de grupo para papel. O papel padrão no primeiro login via SSO é Read-only por política; a promoção exige um Admin ou Manager já existente.

Provedores de identidade compatíveis

Qualquer provedor de identidade compatível com SAML 2.0 funciona. A integração é testada com:

Google Workspace (passo a passo completo abaixo)
Microsoft Entra (Azure AD)
Okta
OneLogin
JumpCloud
Auth0

Endpoints do Service Provider

Configuração	Valor
ACS URL (Assertion Consumer Service)	`https://portal.wasviking.com/sso/saml/acs/`
Entity ID / Audience	`https://portal.wasviking.com/sso/saml/metadata`
Metadata URL (configuração automática)	`https://portal.wasviking.com/sso/saml/metadata`
Algoritmo de assinatura SAML	RSA-SHA256
Formato do NameID	EmailAddress

O mesmo ACS e o mesmo Entity ID valem para todas as organizações. O roteamento é feito pelo domínio de e-mail principal que você configura no lado da WASViking.

Atributos obrigatórios

O IdP deve enviar estes atributos na asserção SAML:

Atributo do Google Directory	Atributo do app (diferencia maiúsculas de minúsculas)	Obrigatório
Primary Email	`email`	Sim
First Name	`first_name`	Sim
Last Name	`last_name`	Sim
Group memberships	`groupMemberships`	Opcional

Maiúsculas e minúsculas importam. A WASViking espera first_name e last_name em snake_case. CamelCase (firstName / lastName) não é reconhecido.

Configure no lado da WASViking

Portal → Admin → System Settings → SSO & Identity → SAML.

A tela tem:

Campo	Valor
Enable SAML authentication	Ative quando o lado do IdP estiver pronto.
Primary Email Domain	O domínio de e-mail com o qual os usuários vão fazer login (por exemplo, `acme.com`). Usuários com esse domínio são direcionados para o SSO.
IdP Entity ID	Vem do seu IdP.
IdP SSO URL / Metadata URL	Vem do seu IdP. Os usuários são redirecionados para cá para se autenticar.
IdP X.509 Certificate	Cole o certificado completo, incluindo os marcadores `-----BEGIN CERTIFICATE-----` e `-----END CERTIFICATE-----`.

Clique em Save SSO Settings.

Teste a configuração antes de ativar a obrigatoriedade do SSO para todos: clique em Test SSO, ao lado de Save SSO Settings. Ele abre o seu IdP em uma nova aba, confere as configurações salvas exatamente como um login real e mostra um relatório: o endereço que o IdP autenticou, o que a WASViking faria com ele e, se algo estiver errado, qual configuração corrigir. Funciona com Enable SAML authentication ainda desligado e nunca conecta ninguém. Salve antes de testar: o teste usa as configurações salvas.

Abaixo do certificado, a página também mostra quando o certificado salvo vence e avisa quando faltam menos de 30 dias.

Você também pode fazer login na página de entrada da WASViking com seu e-mail corporativo, ou usar o botão de teste do seu IdP (por exemplo, Test SAML login no Google Workspace, Testar login SAML no Admin em português). Os dois terminam com você conectado na WASViking.

Política de papel padrão

Toda conta nova que entra via SSO começa como Read-only por padrão. Isso é política, não uma configuração: contas provisionadas por SSO são somente leitura no primeiro login, independentemente dos grupos do usuário no IdP.

A promoção para qualquer outro papel (Admin, Manager, Analyst) exige um Admin ou Manager que já esteja na plataforma. A promoção é feita em Admin → User → Team Management, com registro na trilha de auditoria.

Por que isso importa: o administrador do lado da WASViking ganha um momento para validar o novo operador antes de conceder direitos elevados, mesmo quando o IdP propagaria automaticamente um papel derivado de grupo.

Fluxo de governança por grupos

Com o SAML ativado, o acesso operacional é conduzido a partir do IdP:

Adicione um usuário ao grupo com acesso à WASViking no seu IdP → o usuário ganha acesso no próximo login.
Remova um usuário do grupo → o usuário perde o acesso imediatamente, na próxima validação de sessão.
Desative um usuário no IdP → o usuário perde o acesso imediatamente.

O padrão é o habitual em IAM: ciclo de vida no IdP, autorização na WASViking. Você não precisa gerenciar contas de operadores no lado da WASViking depois que o SSO está ativo.

Mapeamento de grupo para papel (opcional)

Se o seu IdP envia um atributo groupMemberships, você pode mapear grupos específicos para papéis da WASViking. Os mapeamentos se aplicam na promoção do usuário, não no primeiro login (que é sempre Read-only).

Grupo no IdP	Papel na WASViking
`sec-admins`	Admin
`sec-managers`	Manager
`sec-analysts`	Analyst
`auditors`	Read-only

Um usuário em vários grupos mapeados recebe o maior privilégio entre eles no momento da promoção.

MFA

Quando o SSO está ativado, o MFA fica a cargo do seu IdP. A WASViking não solicita o próprio MFA em logins via SSO. Esse é o padrão usual de SP.

Para acesso de emergência (break-glass) no nível da organização, quando o IdP está fora do ar, os Admins podem ativar o Emergency Local Login em Settings → SSO. A flag tem TTL de 72 horas e dispara um evento de auditoria de alta severidade quando usada.

Single Logout

Se o seu IdP oferece suporte a SLO, configure o endpoint de Single Logout e a WASViking passa a honrar as requisições de logout originadas no IdP. O logout local na WASViking também emite SLO se o usuário entrou via SAML.

Como tornar o SSO obrigatório

Depois de testar o SSO, ative a obrigatoriedade em Admin → System Settings → SSO & Identity. A partir daí:

O login local com senha é desativado para as contas do domínio de e-mail configurado.
As chaves de API continuam funcionando (elas não são gerenciadas pelo SSO).
O Emergency Local Login continua disponível para romper o impasse.

Passo a passo no Google Workspace

Este passo a passo espelha o documento de referência WASViking Google Workspace SSO SAML Integration Guide v1.2.

Passo 1: Crie um grupo para controle de acesso

Google Admin → Groups → Create group.

Campo	Valor sugerido
Name	`WASViking Users`
Email	`wasviking-sso@<your-domain>`
Description	Usuários com permissão para acessar a WASViking via SSO

Segurança do grupo:

Tipo: Custom.
Apenas membros convidados podem entrar.
Não permita membros externos.

Clique em Create group.

Passo 2: Adicione usuários ao grupo

Abra o grupo e clique em Add members. Apenas os membros deste grupo poderão se autenticar na WASViking.

Passo 3: Crie a aplicação SAML no Google Workspace

Google Admin → Apps → Web & Mobile Apps → Add App → Add custom SAML app.

Nome sugerido para o app: WASViking. Clique em Continue.

Passo 4: Guarde a identidade do IdP do Google

Na tela de detalhes do IdP do Google, copie e guarde:

SSO URL
IdP Entity ID
X.509 Certificate

Você vai colar esses valores na WASViking no Passo 7.

Clique em Continue.

Passo 5: Configure a WASViking como Service Provider

Preencha exatamente:

Campo	Valor
ACS URL	`https://portal.wasviking.com/sso/saml/acs/`
Entity ID	`https://portal.wasviking.com/sso/saml/metadata`
Name ID	Email
ID of Name	Basic Information > Primary email
Start URL	Deixe vazio

Clique em Continue.

Passo 6: Mapeie os atributos

Adicione exatamente estes mapeamentos:

Atributo do Google Directory	Atributo do app
Primary Email	`email`
First Name	`first_name`
Last Name	`last_name`

Clique em Finish.

Passo 7: Restrinja ao grupo (governança)

Google Admin → Apps → Web & Mobile Apps → WASViking → Service status.

Selecione Groups e procure por WASViking Users.
Defina o status como ON.
Salve.

Agora apenas os membros de WASViking Users conseguem fazer login por este app SAML.

Passo 8: Opcional: importe via Metadata URL

Se o seu IdP permite importar o SP automaticamente, use:

https://portal.wasviking.com/sso/saml/metadata

Passo 9: Configure no lado da WASViking

No portal da WASViking:

Admin → System Settings → SSO & Identity → SAML.

Preencha:

IdP Entity ID (do Passo 4)
IdP SSO URL / Metadata URL (do Passo 4)
IdP X.509 Certificate (cole entre -----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----)
Primary Email Domain (o domínio com o qual os usuários fazem login)

Ative Enable SAML authentication e clique em Save SSO Settings.

Para testar, clique em Test SSO na mesma página (dá para fazer antes de ligar o SSO), abra o app WASViking no Google Admin e clique em Test SAML login, ou faça login em https://portal.wasviking.com com seu e-mail corporativo. Quem tem acesso também pode abrir a WASViking pelo menu de apps do Google.

Passo 10: Operação no dia a dia

Adicione um usuário a WASViking Users no Google Workspace → ele ganha acesso no próximo login (começa como Read-only).
Remova do grupo → acesso revogado.
Mudanças no grupo podem levar até 24 horas para chegar ao app.
Promova a Admin / Manager / Analyst → feito por um Admin ou Manager já existente na WASViking.

Problemas comuns

Problema	Causa provável
O usuário não consegue fazer login	Não é membro do grupo da WASViking no IdP.
O Google mostra `403 app_not_enabled_for_user`	O usuário não está em `WASViking Users`, ou foi adicionado há pouco. Mudanças no grupo podem levar até 24 horas para chegar ao app.
O botão de teste do IdP ou o ícone do app termina em Unable to complete sign-in.	Há uma Start URL (RelayState padrão) configurada no app do IdP. Deixe vazia.
Uma página da WASViking diz Unable to complete sign-in. e mostra uma referência	A WASViking recusou o login por um motivo que só o suporte consegue ver. Envie a referência ao suporte da WASViking.
403 no callback do ACS	Entity ID ou ACS URL não conferem. Revise o Passo 5.
O usuário faz login, mas o nome está ausente	Mapeamento de atributos ausente ou com maiúsculas e minúsculas erradas (deve ser `first_name` / `last_name`).
Nenhuma resposta SAML do IdP	O app não está ativo para o grupo.
Erro de certificado inválido	O certificado de assinatura do IdP expirou. Faça a rotação no IdP e atualize na WASViking.
Papel errado após o primeiro login via SSO	Esperado. O padrão é Read-only; promova em Admin → User → Team Management.

Notas de segurança

Apenas membros do grupo no IdP conseguem se autenticar.
A WASViking segue o menor privilégio: o primeiro login é Read-only.
A administração de papéis permanece no lado da WASViking.
Toda autenticação e toda mudança de papel ficam registradas na trilha de auditoria.

O que isto não é

A WASViking não implementa OIDC. O SAML 2.0 é o padrão para SSO corporativo em ferramentas de segurança e é o que todos os provedores de identidade acima suportam nativamente. O suporte a OIDC está no roadmap.

A WASViking não é um provedor de identidade. Você não pode usar a WASViking para fazer login em outras ferramentas SaaS.