Histórico da Página
Índice
| Índice | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Sobre o Desktop SSO
...
O Desktop SSO é o componente responsável pela realização de um componente não obrigatório na arquitetura do Identity e que pode ser habilitado pelo administrador do contexto. Ele é responsável pelo Single Sign On (SSO), onde um usuário poderá o que permite aos usuários que já estejam autenticados no Windows da estação de trabalho acessar o fluig Identity sem informar manualmente usuário e senha, desde que esteja já autenticado no Windows. O uso do Desktop SSO deve ser habilitado pelo administrador do contexto.as credenciais (e-mail e senha) manualmente.
A validação das credenciais do Windows no Identity é realizada através de um script ASP, que é gerado pelo próprio Identity e deve ser hospedado em um servidor IIS (Internet Information Service). O script consulta as credenciais no Active Directory, recupera Basicamente, trata-se de um script ASP responsável por validar se as credenciais utilizadas para autenticação no Windows são validas para o fluig Identity. As credenciais são consultadas no Active Directory, o e-mail associado a este ao usuário é recuperado e em seguida é validado no fluig e o valida no Identity.
Se os dados as credenciais forem confirmadoslegítimas, o usuário terá obterá acesso ao fluig Identity e aplicações sem a necessidade de informar as credenciais.informá-las manualmente. Caso as credenciais não sejam válidas, será apresentada ao usuário a página de login do fluig Identity é apresentada ao usuário, que poderá entrar com email , onde ele deverá informar o e-mail e senha para ter acesso às aplicações.
Para maior segurança, é possível cadastrar intervalos de IPs, que restringem a permissão para utilização do recurso de SSO. Isto permite também , por exemplo, que usuários internos da empresa tenham a experiência do SSO habilitada, enquanto usuários externos são à rede corporativa serão obrigados a entrar com credenciais manualmente para ter acesso ao fluig Identity e seus aplicativos.
Habilitando o Desktop SSO no fluig Identity
Siga os passos abaixo como administrador do contexto para habilitar o Desktop SSO.
| Painel | ||
|---|---|---|
| ||
Os passos para configuração dessa página foram repassados ao artigo: https://centraldeatendimento.fluig.com/hc/pt-br/articles/360025124393 |
Habilitando o Desktop SSO no Identity
| Âncora | ||||
|---|---|---|---|---|
|
Siga os passos abaixo como administrador do contexto para habilitar o Desktop SSO.
| Deck of Cards | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
NTLM
O NTLM é um protocolo de autenticação utilizado em uma rede Windows.
Como veremos nos tópicos a seguir, existem uma série de configurações que devemos realizar nos navegadores para que eles utilizem este protocolo, e também no script remote_auth.asp, ou Desktop SSO, para que utilize a chamada Autenticação Windows.
Além disso, é importante lembrar que existem limitações com relação a sistemas operacionais não Windows. Linux e Mac não podem utilizar o protocolo NTLM e portanto não podem realizar o SSO.
O efeito nestes sistemas operacionais é que se tentarem o acesso via SSO, uma caixa de diálogo proveniente do browser pedirá para que o usuário entre com suas credenciais.
Como veremos em breve, existe uma maneira de melhorar a experiência dos usuários que utilizam Linux ou Mac, de forma que ao menos eles sejam redirecionados para a página de login do Identity.
Configurando o Desktop SSO no IIS
Para instalar o Desktop SSO é necessário termos um servidor Windows com a Role WebServer (IIS) habilitada.
...
Configurar o Desktop SSO no IIS
| Âncora | ||||
|---|---|---|---|---|
|
Para realizar a configuração do Desktop SSO, é necessário possuir um servidor Windows com o recurso IIS (Internet Information Services) habilitado para que o script de autenticação SSO seja hospedado. Nos tutoriais abaixo são demonstradas em um servidor Windows Server 2012 R2 a inclusão dos roles exigidos e a configuração do script no IIS.
Habilitar Roles
Para o correto funcionamento do Single Sign On, é fundamental adicionar os seguintes roles ao servidor Windows:
| Deck of Cards | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
|
...
|
...
| |||||||||||||||||||||||||||||||||||
| Deck of Cards | |||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||
Card | | ||||||||||||||||||||||||||||||||||
|
| Informações | ||
|---|---|---|
| ||
Para baixar o arquivo remote_auth.asp, é necessário acessar o Identity com um usuário administrador. Em seguida, acessar Configurações > Active Diretory. Na parte inferior da tela apresentada existem algumas configurações para Desktop SSO. Acessar Configuração do Desktop SSO. Depois de inserir as informações solicitadas é possível gerar o arquivo remote_auth.asp. |
No exemplo abaixo, uma pasta chamada c:\inetpub\wwwroot\dsso foi criada para hospedar o script.
| default | true |
|---|---|
| id | 6 |
| label | Passo6 |
Após finalizado o cadastro do site e inserido o arquivo remote_auth.asp na pasta c:\inetpub\wwwroot\DSSO\dsso , basta acessar o seu contexto do Identity e preencher o campo da URL do Script de autenticação com o valor http://localhost:81/remote_auth.asp
| default | true |
|---|---|
| id | 7 |
| label | Passo7 |
Outro ponto é que devemos definir a forma de autenticação desta aplicação, o que é feito através do atalho Authentication, conforme ilustrado abaixo.
| default | true |
|---|---|
| id | 8 |
| label | Passo8 |
Deveremos habilitar a opção Windows Authentication, e todas as outras opções devem permanecer desabilitadas.
| default | true |
|---|---|
| id | 9 |
| label | Passo9 |
Na configuração da aplicação, devemos informar o caminho físico, que neste exemplo é c:\inetpub\wwwroot\dsso.
| default | true |
|---|---|
| id | 10 |
| label | Passo10 |
Existe um detalhe que deve ser tratado na autenticação da aplicação, que são os providers utilizados pela autenticação Windows. Clicando com o botão direito em Windows Authentication, devemos escolher a opção Providers.
| default | true |
|---|---|
| id | 11 |
| label | Passo11 |
Devemos deixar apenas a opção NTLM. Todas as outras devem ser excluídas. Se isso não for feito, corremos o risco de exigir do usuário a entrada de credenciais via caixa de diálogo do browser. Não esquecer que existe outra configuração a ser feita diretamente no browser, para evitar este problema.
| default | true |
|---|---|
| id | 12 |
| label | Passo12 |
Finalizadas as configurações, podemos iniciar os primeiros testes, diretamente no script.
Basta executar o script no browser, que neste exemplo foi http://localhost/dsso/remote_auth.asp.
No exemplo abaixo, o usuário usuarioteste9 estava logado diretamente no servidor. A mensagem abaixo mostra que o usuário foi localizado no Active Directory, porém, este não possuía um email cadastrado, o que é primordial para o Identity.
Em uma situação como esta, se tentássemos acessar o Identity, seriamos redirecionados para a página de login, acrescido de uma mensagem de login SSO inválido.
| default | true |
|---|---|
| id | 13 |
| label | Passo13 |
Existe uma outra maneira de efetuarmos um trace na aplicação.
O script possui instruções para realizar o debug. Se acessarmos o script, acrescentando via querystring o parâmetro debug=1, teremos acesso a diversos valores que nos ajudam a debugar a aplicação, como no exemplo abaixo, onde chamamos a URL http://localhost/dsso/remote_auth.asp?debug=1
Como podemos ver no exemplo abaixo, o usuário logado não possui um email cadastrado, o que é um pré-requisito no Identity.
Relembrando: uma vez terminada estas configurações poderemos finalmente habilitar o Desktop SSO no Identity.
Para efetuar o teste final, deveremos logar no Windows utilizando as credenciais do AD, e em seguida faremos o acesso ao Identity utilizando o subdomínio do contexto do cliente.
Ex: https://totvs.fluigidentity.com
Se o usuário logado no Windows tiver um email válido no Identity, o acesso ao Identity não exigirá a entrada de senha.
Configuração do Internet Explorer e Chrome
É necessário configurar o navegador do usuário para que ele utilize autenticação Windows (NTLM) com o script remote_auth.asp.
Mesmo que o DesktopSSO tenha sido configurado para utilizar autenticação Windows no IIS, o browser do cliente precisa enviar as credenciais para que o script possa fazer as validações necessárias, no AD e no Fluig Identity.
No caso do Internet Explorer e Chrome, basta configurar as opções de segurança e autenticação no Internet Explorer e o Chrome irá assumir as mesmas configurações.
...
| effectDuration | 0.5 |
|---|---|
| history | false |
| id | samples |
| effectType | fade |
...
| default | true |
|---|---|
| id | 1 |
| label | Passo1 |
Para começar, devemos acessar o menu Opções da Internet, no IE.
...
| default | true |
|---|---|
| id | 2 |
| label | Passo2 |
Na sequência, devemos escolher a tab Segurança e em seguida devemos configurar a opção Intranet Local. Isto garante que possamos aplicar o envio de credenciais do Windows apenas para a url do DesktopSSO. Outras aplicações e sites permanecem como estão.
Em seguida, devemos clicar no botão Sites, para informar a url do Desktop SSO.
...
| default | true |
|---|---|
| id | 3 |
| label | Passo3 |
Para adicionar o endereço do Desktop SSO precisamos clicar no botão Avançadas e em seguida adicionamos a url. No nosso exemplos, utilizamos a url do DesktopSSO.
Informamos a url, clicamos no botão Adicionar e podemos fechar a tela clicando no botão Fechar.
...
| default | true |
|---|---|
| id | 4 |
| label | Passo4 |
É importante garantir que as configurações de Autenticação do Usuário estejam definidas para Login automático com o nome de usuário e senha atuais, para a Intranet Zone (Intranet Local).
Para consultar esta tela, basta marcar Intranet Local e clicar no botão Nivel personalizado.
|
Ativar tráfego NTLM
O Desktop SSO depende do protocolo NTLM para funcionar corretamente. Confira os passos abaixo para ativar o tráfego NTLM.
| Deck of Cards | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||
|
Configurar o Script no IIS
Após a habilitação dos roles obrigatórios, o script de autenticação do Desktop SSO deve ser configurado e hospedado no IIS.
| Deck of Cards | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Verificar a configuração do SSO
Após a configuração do script de autenticação do Desktop SSO no IIS, é possível executá-lo para confirmar se o procedimento foi realizado corretamente.
| Deck of Cards | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
|
Configurar navegadores
| Âncora | ||||
|---|---|---|---|---|
|
A configuração nos navegadores tem por objetivo direcioná-los para a URL do Desktop SSO para a realização do login com as credenciais do Windows. A configuração realizada no Internet Explorer também é válida para o Google Chrome, enquanto o Mozilla Firefox exige uma configuração específica.
Google Chrome e Internet Explorer
É necessário configurar o navegador do usuário para que ele utilize autenticação Windows (NTLM) com o script remote_auth.asp.
Mesmo que o Desktop SSO tenha sido configurado para utilizar autenticação Windows no IIS, o navegador do cliente precisa enviar as credenciais para que o script possa fazer as validações necessárias no Active Directory e no Identity.
| Deck of Cards | ||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||
|
Mozilla Firefox
O navegador Mozilla Firefox exige uma configuração específica.
| Deck of Cards | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||
|
Group Policies para Google Chrome e Internet Explorer
Caso a empresa possua uma grande quantidade de navegadores e estações de trabalho a serem configuradas, é possível fazer a distribuição das configurações utilizando-se de Group Policies (GPO). Durante o procedimento de autenticação no domínio, pode-se executar uma série de tarefas automáticas como, por exemplo, configurar o Internet Explorer do usuário.
| Deck of Cards | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||
|
Configuração para Linux, macOS e Mobile
| Âncora | ||||
|---|---|---|---|---|
|
O Desktop SSO utiliza o protocolo NTLM para realizar o Single Sign On, porém este é um protocolo utilizado apenas pelo sistema operacional Windows. Para tratar situações onde o cliente possui estações Linux, macOS ou realiza o acesso via dispositivo móvel, é possível instalar um script, executado antes do Desktop SSO, com a finalidade de identificar o sistema operacional que está requisitando a página.
Chamado de check_remote_auth.asp, este script não é distribuído pelo Identity, mas foi construído especificamente para implantações com ecossistemas mais complexos, envolvendo diferentes sistemas operacionais.
| Deck of Cards | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||
|
Opções de arquitetura para alta disponibilidade
O Desktop SSO pode utilizar uma arquitetura baseada em um único servidor. O problema é que neste cenário, se o script estiver offline, o usuário não conseguirá autenticar no Identity.
O administrador deverá desabilitar o Single Sign On do contexto do cliente, no Identity, ou corrigir o que for necessário para que o script fique online.
Existe uma opção onde podemos instalar o Desktop SSO em duas máquinas, o que fornece uma boa redundância do componente. Se um servidor ou uma aplicação estiver indisponível, o outro servidor assume a responsabilidade de manter o serviço de Single Sign On acessível.
Para isso precisamos disponibilizar um Load Balancer que terá a responsabilidade de fazer o redirect, caso um dos dois servidores com Desktop SSO esteja offline. Existem algumas opções para efetuar o Load Balance, como por exemplo, Apache, BIG-IP e Barracuda.
| HTML |
|---|
<!-- Hotjar Tracking Code for http://tdn.totvs.com/display/fb -->
<script>
(function(h,o,t,j,a,r){
h.hj=h.hj||function(){(h.hj.q=h.hj.q||[]).push(arguments)};
h._hjSettings={hjid:1280165,hjsv:6};
a=o.getElementsByTagName('head')[0];
r=o.createElement('script');r.async=1;
r.src=t+h._hjSettings.hjid+j+h._hjSettings.hjsv;
a.appendChild(r);
})(window,document,'https://static.hotjar.com/c/hotjar-','.js?sv=');
</script>
<script>
$("b:contains('oculto')").parent().parent().hide();
</script>
|
Configuração do Firefox
Dentre os principais browsers, temos também o Firefox que deve ser configurado de uma maneira um pouco diferente.
...
| effectDuration | 0.5 |
|---|---|
| history | false |
| id | samples |
| effectType | fade |
...
| default | true |
|---|---|
| id | 1 |
| label | Passo1 |
Em primeiro lugar, precisamos digitar about:config na barra de endereços, para poder acessar as configurações do Firefox.
...
| default | true |
|---|---|
| id | 2 |
| label | Passo2 |
Uma mensagem de alerta normalmente é exibida. Para continuar, basta clicar no botão de confirmação. No nosso exemplo, o botão I’ll be careful, I promise!
...
| default | true |
|---|---|
| id | 3 |
| label | Passo3 |
As configurações de NTLM podem ser facilmente encontradas se digitarmos no campo Search, a string “ntlm”.
Devemos manter as configurações como exibidas abaixo. A mais importante é network.automatic-ntlm-auth.trusted-urls, onde devemos informar a url do DesktopSSO.
Feito isso, temos também o Firefox configurado para utilização de Single Sign On com o Fluig Identity.
Group Policies para Internet Explorer e Chrome
Configurar o browser de alguns poucos usuários é tarefa simples, porém, o cliente terá um grande problema quando tem milhares de usuários a serem configurados.
Para estes casos, podemos utilizar a estratégia de distribuição das configurações, baseadas na utilização de Group Policies (GPO).
Durante o procedimento de autenticação no domínio, podemos executar uma série de tarefas automáticas, como por exemplo, configurar o Internet Explorer do usuário.
O administrador deverá definir a seguinte configuração de GPO:
Computer Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page
Após habilitar a definição de lista da Zona da Intranet, o cliente deverá definir a url do Desktop SSO como membro da Zona da Intranet.
No nosso exemplo, estamos definindo o site *.fluigidentity.com, o que deve atender a maior parte dos casos, onde o Fluig Identity é utilizado na modalidade SaaS.
Desta forma, toda vez que um usuário membro deste domínio efetuar o login, as configurações necessárias serão realizadas. Se executada todos os dias, a GPO também deve evitar que um usuário mais avançado desfaça as configurações necessárias para o Desktop SSO.
| Nota | ||
|---|---|---|
| ||
Não existe maneira direta de configurar o navegador Mozilla Firefox a partir da GPO. |
Configuração para Sistema Operacional Linux e Mac
O Desktop SSO utiliza o protocolo NTLM para realizar o Single Sign On, porém, este é um protocolo utilizado apenas pelo Windows.
Para tratar situações onde o cliente possui muitos clients Linux ou Mac, podemos instalar um script, executado antes do Desktop SSO, com a finalidade de testar o sistema operacional que está requisitando a página.
Este script é o check_remote_auth.asp, que não é distribuído pelo Fluig Identity, mas que foi construído especificamente para implantações com ecossistemas mais complexos, envolvendo diferentes sistemas operacionais.
Pode ser efetuado o download do script nesse link, lembrando que é necessário alterar os campos conforme descrição dentro do script.
Este script deve ser hospedado no mesmo IIS do Desktop SSO. Neste exemplos, criamos uma aplicação no IIS, chamada de check_dsso.
É importante que esta aplicação seja configurada para usar Anonymous Authentication, pois a única finalidade dela é redirecionar o usuário para a URL correta.
Se o usuário estiver utilizando Windows, ele será redirecionado para o script Desktop SSO. Caso contrário, será direcionado para uma url do Identity que obriga o usuario a informar suas credenciais.
Opções de arquitetura para Alta disponibilidade
O Desktop SSO pode utilizar uma arquitetura baseada em um único servidor. O problema é que neste cenário, se o script estiver off-line, o usuário não conseguirá autenticar no Fluig Identity.
O administrador deverá desabilitar o Single Sign ON do contexto do cliente, no Identity, ou corrigir o que for necessário para que o script fique online.
Existe uma opção, onde podemos instalar o Desktop SSO em duas máquinas, o que fornece uma boa redundância do componente. Se um server estiver fora do ar, ou se uma aplicação estiver fora, o outro server assume a responsabilidade de manter online o serviço de Single Sign On.
Para isso precisamos disponibilizar um Load Balancer, que terá a responsabilidade de fazer o redirect, caso um dos dois servidores com Desktop SSO esteja off-line.
...
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas