Para habilitar o SSO em um contexto do Identity, o administrador deverá acessar o menu Configuração.

Logo em seguida, o administrador terá acesso às configurações de Active Directory.

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. 

Para ter acesso às configurações do Identity, o administrador deverá clicar no link Configuração do Desktop SSO.

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.

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], 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 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.

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.

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.

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. 

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.

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.

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 foi criada para hospedar o script.

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

Outro ponto é que devemos definir a forma de autenticação desta aplicação, o que é feito através do atalho Authentication, conforme ilustrado abaixo. 

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

Na configuração da aplicação, devemos informar o caminho físico, que neste exemplo é c:\inetpub\wwwroot\dsso. 

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. 

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. 

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.

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.