Histórico da Página
Índice
Índice | ||||||||
---|---|---|---|---|---|---|---|---|
|
Introdução sobre o Desktop SSO
|
...
O Desktop SSO é o componente responsável pela realização de Single Sign On, 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.
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), 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.
Painel |
---|
Habilitando o Desktop SSO no Fluig Identity
| ||
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 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 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.
...
effectDuration | 0.5 |
---|---|
id | samples |
history | false |
effectType | fade |
Card | ||||||
---|---|---|---|---|---|---|
| ||||||
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.
|
Card | ||||||
---|---|---|---|---|---|---|
| ||||||
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.
|
Card | ||||||
---|---|---|---|---|---|---|
| ||||||
Agora temos o servidor pronto para executar o Desktop SSO. 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.
No exemplo abaixo, uma pasta chamada c:\inetpub\wwwroot\dsso\dsso foi criada para hospedar o script.
|
...
default | true |
---|---|
id | 4 |
label | Passo4 |
No IIS deverá ser criada uma aplicação que chamamos de dsso, por padrão. O dns e porta para este script é algo a ser definido pelo administrador do servidor.
Uma vez escolhido, deverá ser cadastrado no Identity.
Card | ||||||
---|---|---|---|---|---|---|
| ||||||
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 | 6 |
label | Passo6 |
Deveremos habilitar a opção Windows Authentication, e todas as outras opções devem permanecer desabilitadas.
Card | ||||||
---|---|---|---|---|---|---|
| ||||||
Na configuração da aplicação, devemos informar o caminho físico, que neste exemplo é c:\inetpub\wwwroot\dsso.
|
Card | ||||||
---|---|---|---|---|---|---|
| ||||||
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.
|
Card | ||||||
---|---|---|---|---|---|---|
| ||||||
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.
|
Card | ||||||
---|---|---|---|---|---|---|
| ||||||
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 | 11 |
label | Passo11 |
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 browser 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 |
---|---|
id | samples |
history | false |
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.
|
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 | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||
|
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 | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
...
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 *.fluigidentity.com.
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.
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 |
---|---|
id | samples |
history | false |
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.
Card | ||||||
---|---|---|---|---|---|---|
| ||||||
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!
|
Card | ||||||
---|---|---|---|---|---|---|
| ||||||
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
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
Configuração para Linux, macOS e Mobile
Âncora | ||||
---|---|---|---|---|
|
O Desktop SSO utiliza o protocolo
Existe um script que foi criado para definir estas configurações do Firefox. Ele pode ser obtido com a equipe de serviços do Fluig.
Para executar o script devemos configurar a GPO conforme ilustrado abaixo.
User Configuration > Windows Settings > Scripts > Logon
Configuração para Sistema Operacional Linux e Mac
O DesktopSSO utiliza o protocol 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 muitos clients estações Linux ou Mac, podemos , macOS ou realiza o acesso via dispositivo móvel, é possível instalar um script, executado antes do Desktop SSO, com a finalidade de testar identificar o sistema operacional que está requisitando a página.
Este script é o Chamado de check_remote_auth.asp, que este script não é distribuído pelo Fluig Identity, mas que foi construído especificamente para implantações com ecossistemas mais complexos, envolvendo diferentes sistemas operacionais.
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.
Existem algumas opções para efetuar o load balance, como por exemplo:
- Apache
- BIG-IP
- Barracuda
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>
|
...