Configuração de SSO com Active Directory, IIS, Edge e Chrome

Objetivo: permitir que um usuário já autenticado no Windows/Active Directory acesse uma aplicação corporativa sem precisar informar novamente usuário e senha no navegador. Esse cenário normalmente utiliza Windows Integrated Authentication.

1. Configuração no IIS

No servidor IIS, abra o site ou aplicação e acesse Authentication.

Método	Configuração
Anonymous Authentication	Disabled
Windows Authentication	Enabled

2. Adicionar o sistema à zona Intranet Local

No computador Windows do usuário, abra Opções da Internet (Internet Options) e siga:

1. Segurança > Intranet local.
2. Clique em Sites.
3. Clique em Avançado.
4. Adicione o endereço da aplicação, por exemplo: https://sistema.seudominio.com

3. Permitir logon automático

Ainda em Opções da Internet:

• Segurança > Intranet local.
• Clique em Nível personalizado.
• Localize Autenticação do usuário > Logon.
• Selecione: Logon automático somente na zona da Intranet.

Importante: essa é uma das configurações mais comuns quando o navegador está exibindo uma janela pedindo usuário e senha mesmo com o usuário já autenticado no domínio.

4. Microsoft Edge e Google Chrome

Edge e Chrome podem utilizar a autenticação integrada do Windows. Em ambientes administrados, é recomendável controlar o comportamento por políticas (GPO).

Microsoft Edge

Para verificar as políticas aplicadas, acesse:

edge://policy

Google Chrome

Para verificar as políticas aplicadas, acesse:

chrome://policy

Políticas relevantes para autenticação integrada:

• AuthServerAllowlist
• AuthNegotiateDelegateAllowlist

Exemplo de allowlist:

AuthServerAllowlist = sistema.seudominio.com

5. Implantação via GPO do Active Directory

Para vários computadores do domínio, o ideal é distribuir as configurações por Group Policy (GPO), em vez de configurar cada estação manualmente. A GPO pode definir a zona de Intranet Local e também as políticas de autenticação do Edge/Chrome.

Exemplo de implementação manual via Registro do Windows, não recomendada para ambientes corporativos, onde o ideal é realizar a configuração de forma centralizada por meio de GPO:

reg add “HKLM\SOFTWARE\Policies\Microsoft\Edge” /v AuthServerAllowlist /t REG_SZ /d “sistema.seudominio.com” /f

6. Checklist de diagnóstico

• O computador está ingressado no domínio do Active Directory.
• O usuário efetuou logon no Windows com uma conta do domínio.
• Anonymous Authentication está desabilitado no IIS.
• Windows Authentication está habilitado no IIS.
• Negotiate aparece antes de NTLM nos Providers do IIS.
• A URL da aplicação está reconhecida como Intranet Local.
• O logon automático está habilitado para a zona Intranet.
• O navegador não está sendo executado com credenciais de outro usuário.
• As políticas AuthServerAllowlist/AuthNegotiateDelegateAllowlist estão corretas, quando utilizadas.
• DNS, SPN e Kerberos devem ser verificados se NTLM funcionar, mas Kerberos não.

Resultado esperado

Após a configuração, o usuário entra no Windows com sua conta do domínio e, ao acessar a aplicação pelo Edge ou Chrome, o navegador envia automaticamente as credenciais integradas. A janela solicitando usuário e senha deixa de aparecer, desde que o servidor, a zona de segurança e as políticas estejam corretamente configurados.

1. Visão Geral

A integração do BNWEB com o WhatsApp permite automatizar o envio de notificações aos usuários da biblioteca, modernizando a comunicação e aumentando a eficiência na recuperação de acervos.

Com esta funcionalidade ativa, o sistema pode disparar mensagens automáticas para eventos como:

• Avisos de livros disponíveis (reservas atendidas).
• Lembretes de devolução iminente.
• Cobrança de materiais em atraso.
• Comprovantes de empréstimo e renovação.
• Outras …

2. Tarefas, Responsabilidade e Custos

É fundamental compreender a divisão de tarefas e responsabilidades nesta integração para o planejamento financeiro e técnico da instituição.

O que o BNWEB oferece (Sem Custos)

A funcionalidade de geração de mensagens faz parte do pacote padrão do BNWEB.

Custo BNWEB: R$ 0,00. Não há cobrança de licenciamento adicional por parte do BNWEB para habilitar o módulo de saída de notificações.

O que o sistema faz: O BNWEB processa as regras de negócio (ex: “quem está atrasado hoje?”) e envia os dados (telefone e texto) para uma “porta de saída” (API/Webhook).

O que a Instituição deve providenciar (Custo Externo)

Para que a mensagem saia do BNWEB e chegue ao celular do usuário, é necessária uma via de transporte. O BNWEB não se conecta diretamente aos servidores da Meta (WhatsApp); ele precisa de um Gateway de Envio.

A instituição deve contratar ou desenvolver esse serviço de mensageria. Existem três modelos principais de integração disponíveis no mercado, variando em custo, estabilidade e complexidade técnica.

Atenção:

Verifique junto à sua instituição, se já utilizam envio de mensagens por whatsapp. Neste caso, bastaria utilizar todo o mecanismo já existente.

3. Alternativas de Mercado para o Gateway de Envio

Abaixo estão listadas as três arquiteturas possíveis para conectar o BNWEB ao WhatsApp, cabendo à instituição escolher a que melhor se adapta ao seu orçamento e política de TI.

Opção A: API Oficial (Meta/BSPs) – Recomendado para Alta Estabilidade

Utiliza a infraestrutura oficial do WhatsApp Business API. Geralmente contratada através de parceiros (BSPs) como Twilio, Gupshup ou Zenvia.

Como funciona: O BNWEB envia os dados para o provedor oficial, que entrega a mensagem com garantia de segurança.

Vantagens: Risco zero de bloqueio do número; alta estabilidade (SLA 99.9%); não depende de celular físico ligado.

Desvantagens: Custo variável por mensagem enviada (modelo de “janelas de conversação” cobrado pelo Facebook); exige aprovação de templates de mensagem.

Custo Estimado: Taxa fixa da ferramenta + Custo por mensagem – verificar valores atualizados..

Opção B: Gateways SaaS (APIs Intermediárias) – Custo-Benefício

Empresas que fornecem um serviço que simula o WhatsApp Web em nuvem. Exemplos: Z-API, PlugMessage, MegaAPI.

Como funciona: A biblioteca contrata o serviço, escaneia um QR Code com um celular da instituição e o serviço fornece uma URL de API para configurar no BNWEB.

Vantagens: Custo fixo mensal (envios ilimitados); implementação rápida; permite envio de qualquer texto sem aprovação prévia.

Desvantagens: Depende da conexão do celular da biblioteca (se o celular ficar sem bateria ou internet, o envio falha); risco moderado de banimento se houver abuso (spam).

Custo Estimado: Mensalidade fixa – verificar valores atualizados.

Opção C: Solução Própria (Open Source) – Para Equipes de TI

A instituição hospeda sua própria API utilizando bibliotecas de código aberto (como Evolution API ou Baileys) em seus próprios servidores.

Como funciona: A TI da instituição sobe um servidor (Docker/Node.js), conecta o WhatsApp da biblioteca e cria o endpoint para o BNWEB consumir.

Vantagens: Sem custo de licença de software; controle total dos dados.

Desvantagens: Exige conhecimento técnico avançado para instalação e manutenção; se o WhatsApp atualizar, a API pode parar de funcionar até que a TI atualize o sistema.

Custo Estimado: Apenas o custo de infraestrutura (Servidor/VPS).

4. Quadro Comparativo Resumido

Característica	API Oficial (Meta/Twilio)	Gateway SaaS (Z-API/Outros)	Solução Própria (Self-Hosted)
Custo BNWEB	Gratuito	Gratuito	Gratuito
Custo do Envio	Variável (por mensagem)	Fixo (mensalidade)	Infraestrutura apenas
Dependência de Celular	Não (Nuvem)	Sim (QR Code)	Sim (QR Code)
Complexidade Técnica	Média	Baixa	Alta
Risco de Bloqueio	Nulo	Baixo (se moderado)	Baixo (se moderado)

5. Requisitos para Implantação

Para ativar a integração, a equipe responsável pelo BNWEB precisará das seguintes informações fornecidas pela solução escolhida:

1. Endpoint (URL) da API: O endereço para onde o BNWEB enviará os dados.
2. Token de Autenticação: A chave de segurança para validar o envio.
3. Documentação dos Parâmetros: (Ex: como a API espera receber o número de telefone e a mensagem).