Índice

Introdução 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), que chamarei de SSO daqui em diante, onde um usuário poderá acessar o Fluig Identity sem informar manualmente usuário e senha, desde que esteja já autenticado no Windows.

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 email associado a este usuário é recuperado e em seguida é validado no Fluig Identity.

Se a validação estiver OK, o usuário terá acesso ao Fluig Identity e aplicações sem necessidade de entrada de credenciais.

o que permite aos usuários que já estejam autenticados no Windows da estação de trabalho acessar o Identity sem informar 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 o e-mail associado ao usuário e o valida no Identity.

Se as credenciais forem legítimas, o usuário obterá acesso ao Identity sem a necessidade de informá-las manualmente. Caso as credenciais não sejam válidas, será apresentada ao usuário a página de login do Identity, onde ele deverá informar o e-mail Caso as credenciais não sejam validas, a página de login do Fluig Identity é apresentada ao usuário, que poderá entrar com email e senha para ter acesso às aplicações.

O Desktop SSO é um componente não obrigatório na arquitetura do Fluig Identity, que pode ser habilitado pelo administrador do contexto.

Para maior segurança, é possível cadastrar ranges intervalos de IPs, que restringem a permissão para utilização da funcionalidade 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

...

Identity

...

Âncora

...

habilitar habilitar

Siga os passos abaixo como administrador do contexto para habilitar o Desktop SSO.

Deck of Cards
effectDuration 0.5 history 0.5 history false id samples effectType fade
Card default true id 1 label Passo1 label Passo 1 Para habilitar o SSO em um contexto do TOTVS Identity, o administrador deverá acessar o menu Configuração deve acessar Image Added Configurações. Acessar a aba  Active Directory. Image Added Image Removed     Card id 2 label Passo 2 Logo em seguida, o administrador terá acesso às configurações de Active Directory.   Image Removed   Card No final da página, marcar a opção Permitir o acesso via Desktop SSO. Acionar o link Configurações do Desktop SSO. Image Added No final da página, o administrador poderá habilitar o SSO, marcando o CheckBox “Permitir o acesso via Desktop SSO”, porém é importante lembrar que existem diversas configurações à serem executadas antes que possamos utilizar o SSO no contexto. Se as configurações não forem finalizadas antes que o CheckBox seja habilitado, os usuários poderão ter dificuldades para logar no Identity, ou até mesmo poderão ser impedidos de ter acesso.   Image Removed   Para ter acesso às configurações do Identity, o administrador deverá clicar no link Configuração do Desktop SSO. Card id 3 label Passo 3 Card id 4 label Passo 4 Nesta página, o usuário poderá configurar os ranges de IPs que serão liberados para executar o SSO. Para editar os dados da página, basta clicar no botão verde de edição. É importante ter sempre alguém responsável pela infra estrutura do cliente, acompanhando os trabalhos de configuração do Identity, incluindo também a configuração do Desktop SSO. Este profissional poderá facilitar algumas configurações como por exemplo, IPs externos, dados de conexão com o Active Directory e usuários para teste.   Image Removed Nesta página será realizada a definição dos intervalos de endereços IP que serão liberados para executar o SSO. Acionar Image Added (Editar). É importante que o responsável pela infraestrutura do cliente acompanhe o processo de configuração do Identity, inclusive a configuração do Desktop SSO. Este profissional poderá facilitar algumas configurações como por exemplo, IPs externos, dados de conexão com o Active Directory e usuários para teste. Image Added Card label Passo 4 Informar um endereço IP externo permitido. Os endereços IP informados na configuração do Desktop SSO devem ser IPs externos para garantir a comunicação com o TOTVS Identity, que não possui acesso aos IPs internos da rede. Caso não saiba qual o endereço o IP externo, o administrador pode usar sites como http://www.meuip.com.br/ para identifica-los. Além de informar um endereço IP específico, é possível informar um intervalo de IPs. Por exemplo: 192.168.4.[0-10]. Essa expressão indica que todos os endereços IP entre 192.168.4.0 e 192.168.4.10 serão permitidos. Informações Os IPs externos não cadastrados serão redirecionados para a página de login, onde os usuários deverão informar manualmente as credenciais para obter acesso ao contexto. É necessário que a empresa possua um IP externo estático garantindo que usuários deste IP utilizem o Desktop SSO e os IPs diferentes do cadastrado possam utilizar suas credenciais pela tela de autenticação. Informar a URL do script de Autenticação, abordado no próximo tópico. Essa URL é o endereço do servidor IIS para acesso ao script de autenticação, por exemplo: https://acme.com/remote_auth.asp. Nesse momento ainda não é necessário ter o script totalmente configurado no IIS, apenas informar o endereço em que o script será hospedado. Acionar Salvar. Image Added Nota Se o administrador cadastrar Card id 5 label Passo 5 Uma vez clicado no botão de edição, o primeiro item a ser configurado deverá ser os ranges de IPs, através da opção Endereço IP permitido. É possível criar mascaras para estes IPs, como no exemplo abaixo, onde utilizamos a notação [0-255] para informar que qualquer valor entre 0 e 255 é válido. Importante lembrar que o IP que devemos cadastrar é o IP externo. Isso assegura que quem estiver dentro da rede terá acesso ao AD e terá o acesso permitido já que o IP externo estará cadastrado. Usuários provenientes de fora da rede terão um IP diferente do cadastrado e portanto serão obrigados a informar credenciais, na página de login do Identity. Resumidamente, este cadastro é um filtro que informa quem deve utilizar SSO e quem deve informar credenciais manualmente. Se por exemplo, um administrador cadastrar [0-255]. [0-255]. [0-255]. [0-255]. [0-255] como endereço permitido, o Identity entenderá que todos os endereços de acesso são válidos , porém teremos um problema neste caso.Usuários acessando o Identity . Contudo, essa configuração poderá acarretar problemas, pois usuários de fora da rede não terão acesso ao endereço do Desktop SSO , e neste caso um erro será informado (O browser é redirecionado para um endereço que ele não pode acessar). Para cadastrar corretamente o IP é necessário que a empresa possua um IP externo estático garantindo que usuários deste IP utilizem o Desktop SSO e os IPs diferente do cadastrado possam utilizar suas credenciais pela tela de autenticação. Finalmente, existe um campo chamado URL do script de autenticação. Trata-se do Desktop SSO, instalado no tópico anterior deste documento. A URL deve apontar por padrão para http://<endereço>/dsso/remote_auth.asp, mas existem outras alternativas, descritas nos tópicos a seguir.   Image Removed Aviso title Range IP Na faixa de IPs deve ser inserido os IPs externos, ou seja, o IP que chega no Identity. Se o cliente não souber ele pode consultar sites como o http://www.meuip.com.br/ Card id 6 label Passo 6 Um ponto muito importante é que nada destas configurações irá funcionar se não tivermos instalado o script remote_auth.asp, ou Desktop SSO, em um Servidor com IIS. Este script é único por contexto, e o download só é habilitado a partir do momento em que clicamos no botão Salvar. Se não efetuarmos o download neste momento, e desejamos fazer isso posteriormente, é importante lembrar do procedimento: - Clicar em edição - Clicar no botão Salvar Desta forma, a opção Baixar script de autenticação SSO será habilitada, através do botão Baixar, conforme ilustrado abaixo.   Image Removed   Outro ponto que não devemos esquecer. Vamos supor que o script foi instalado com sucesso e que o Desktop SSO foi habilitado no Identity. Mesmo assim, o SSO só será realizado se o usuário chegar até o Identity através do subdomínio cadastrado para o contexto. Por exemplo: https://totvs.fluigidentity.com Se acessarmos o Identity através do endereço https://app.fluigidentity.com, o SSO não será realizado e a página de login do Identity será apresentada para o usuário. Aviso title Configurações script remote_auth Após efetuar o download, é necessário abrir o arquivo do script e preencher com o usuário administrador do Active Directory e a senha criptografada. Dentro do arquivo contém informações de como realizar essa ação.

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 browsers 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.

Igualmente importante é habilitar uma RoleService chamada ASP. Por default, o IIS executa aplicações ASP .NET (deve ser a versão 4.5), mas precisamos habilitar aplicações ASP Classic para serem executadas.

Configurar o Desktop SSO no IIS

Âncora
iis iis

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:

Ativar tráfego NTLM

O Desktop SSO depende do protocolo NTLM para funcionar corretamente. Confira os passos abaixo para ativar o tráfego NTLM.

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.

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.

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

Image Removed

Deck of Cards
history false id testar
Card default true label Executar script Abrir o navegador e acessar a URL do script, por exemplo, 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 não possuía um e-mail cadastrado, o que é primordial para o Identity. Em uma situação como essa, ao tentar acessar o contexto da empresa no Identity, o usuário seria redirecionado para a página de login e uma mensagem de login SSO inválido seria exibida. Image Added Card label Debug O script de autenticação possui instruções para realizar o debug da aplicação. Este modo exibe dados adicionais para auxiliar na identificação de problemas na configuração do SSO.
Deck of Cards
effectDuration 0.5 history false id samples effectType fade
Card default true id 1 label Passo1 Para habilitar, devemos utilizar o Server Manager, adicionar a Role Web Server, se não estiver habilitada. Uma vez habilitada, o IIS estará disponível para utilização, mas não estará pronto para executar scripts ASP classic. Devemos então selecionar a Role Web Server e adicionar a Role Service ASP.   Image Removed   Card default true id 2 label Passo2 Outro ponto importante é que devemos habilitar a autenticação Windows no Desktop SSO. Desta forma, o browser poderá enviar as credenciais para a aplicação efetuar as validações necessárias no Active Directory. Basta adicionar a Role Service Windows Authentication, como ilustrado na figura abaixo.   Image Removed   Card default true id 3 label Passo3 Agora temos o servidor pronto para executar o Desktop SSO. Com isso, basta acessar o IIS e nele adicionar um site que será utilizado pelo DesktopSSO.   Image Removed Card default true id 4 label Passo4 Preencha as informações necessárias para criação do site, conforme exemplo:  Image Removed Card default true id 5 label Passo5 Uma vez que tenhamos baixado o arquivo remote_auth.asp do Identity, devemos criar uma aplicação ASP a ser executada no IIS. Lembrando novamente que o apoio da equipe de infraestrutura é fundamental. Informações title Nota 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.   Image Removed
Card
default true id 6 label Passo6

Deveremos habilitar a opção Windows Authentication, e todas as outras opções devem permanecer desabilitadas.

Image Removed

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.

Image Removed

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.

Configurar navegadores

Âncora
navegadores navegadores

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.

Mozilla Firefox

O navegador Mozilla Firefox exige uma configuração específica.

Para começar, devemos acessar o menu Opções da Internet, no IE.

Image Removed

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.

Image Removed

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 *.fluigidentity.com.

Informamos a url, clicamos no botão Adicionar e podemos fechar a tela clicando no botão Fechar.

Image Removed

Configuração do Firefox

Dentre os principais browsers, temos também o Firefox que deve ser configurado de uma maneira um pouco diferente.

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

Image Removed

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.

Image Removed

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.

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.

Image Removed

Image Removed

É 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.

Image Removed

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.

Configuração para Linux, macOS e Mobile

Âncora
linux linux

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.

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 offline, o usuário não conseguirá autenticar no Fluig Identity.

O administrador deverá desabilitar o Single Sign ON 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 servidor ou uma aplicação estiver foraindisponível, o outro server servidor assume a responsabilidade de manter online 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 off-line.

Image Removed

offline. Existem algumas opções para efetuar o load balanceLoad Balance, como por exemplo:
- Apache
- , Apache, BIG-IP
- e Barracuda.

 Image Added

<!-- 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>

...