Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Comentário: Retomado à versão 29 e inserido aviso no inicio da documentação.

...

Índice
maxLevel4
outlinetrue
stylenone
exclude.*ndice
style

Objetivo

O objetivo deste guia é habilitar e configurar a autenticaç................

 

Visão Geral

A autenticação integrada com o Windows possibilita que os usuários que estejam registrados no Active Directory possam acessar o Fluig sem precisar informar manualmente seus dados de acesso através da tela de login, desde que já  esteja autenticado no Windows.

Basicamente o processo de autenticação integrada com o Windows funciona da seguinte maneira:

  1. O usuário acessa o Fluig através do seu navegador;
  2. Fluig inicia o processo de autenticação integrada, redirecionando para o servidor IIS;
  3. O script de autenticação remota no IIS sabe como autenticar o usuário pelas credenciais de domínio do Windows;
  4. O usuário é consultado e validado no Active Directory pelo IIS;
  5. IIS redireciona novamente ao Fluig com as informações de identidade do usuário retornadas pelo Active Directory;
  6. Fluig valida a integridade das informações recebidas do servidor IIS;
  7. Caso as informações do usuário forem válidas autentica o usuário no Fluig, caso contrário redireciona para a tela de login.
Nota
titleAtenção!

Com essa configuração de autenticação integrada os usuários não são criados automaticamente no Fluig. Eles somente são criados automaticamente quando é utilizado o Identity.

 

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 de autenticação remota 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. O efeito nestes sistemas operacionais é que se tentarem o acesso via autenticação integrada, uma caixa de diálogo proveniente do browser pedirá para que o usuário informe suas credenciais.

 

Configuração da Autenticação Integrada

Para usufruir da autenticação integrada com o Windows, é necessário habilitar este recurso no Fluig e realizar algumas configurações, como a criação do serviço de autenticação remota. As configurações necessárias para o correto funcionamento da autenticação integrada são apresentadas nos tópicos abaixo.

Habilitando e Configurando no Fluig

O primeiro passo para a configuração da autenticação integrada é habilitá-la no Fluig:

 

...

effectDuration0.5
idfluig-config
historyfalse
effectTypefade
Card
defaulttrue
id1
labelPasso 1
titleAcessando as configurações do sistema

 

  • Efetue o login no Fluig utilizando o usuário wcmadmin, e então acesse Painel de Controle  ► WCM ► Configurações do Sistema.

 

Image Removed

 

Card
id2
labelPasso 2
titleHabilitar Autenticação Integrada

 

  • Na tela de configurações do sistema, acesse a aba Autenticação. Para habilitar a autenticação integrada assinale a opção Habilitar autenticação integrada.

 

Image Removed

 

...

id3
labelPasso 3
titleURL Script Autenticação

 

  • Insira a URL do servidor IIS onde será executado o script de autenticação remota no campo URL script de autenticação. A URL deve apontar por padrão para http(s)://<endereço-iis>/remote_auth.asp (A configuração do servidor IIS e da URL para acesso será descrito no tópico Configuração IIS).

Image Removed

 

Card
id4
labelPasso 4
titleInformar usuário e senha para autenticação

 

  • Clique no botão Gerar Novo Token para gerar um token de autenticação. O token é utilizado para validar a integridade e segurança das requisições de autenticação integrada recebidas pelo Fluig.

 

Image Removed

 

Card
id5
labelPasso 5
titleGerar Token

 

  • Informe o endereço do servidor Active Directory no campo Endereço do servidor AD no seguinte formato <servidor>:<porta> e o DN (Distinguished Name) base para a pesquisa de usuários no campo Base DN. O DN base é utilizado para informar abaixo de qual entrada no Active Directory será pesquisado e validado os usuários para a autenticação integrada.

 

Image Removed

 

Card
id6
labelPasso 6
titleSalvar Configurações e Exportar Script

 

  • Informe um login e senha do Active Directory que possua privilégios suficientes para ler informações dos usuários no Active Directory informado no passo anterior. O login deve ser informando no campo Usuário de domínio e a senha no campo Senha.

 

Image Removed

 

Card
id7
labelPasso 7

 

  • Clique no botão Salvar para salvar as configurações de autenticação. Em seguida clique no botão Exportar para gerar e salvar o script de autenticação remota que deverá ser publicado no servidor IIS.

 

Image Removed

 

Nota

É importante lembrar que existem diversas configurações à serem executadas antes que possamos utilizar a autenticação integrada, estas serão detalhadas nos tópicos a seguir. Se estas configurações não forem finalizadas antes que a autenticação integrada seja habilitada, os usuários poderão ter dificuldades para autenticar no Fluig, ou até mesmo poderão ser impedidos de ter acesso.

 

 

 

Configuração IIS

Para disponibilizar o serviço de autenticação remota é necessário ter um servidor Windows com o Internet Information Services (IIS) habilitado. Siga o passo-a-passo abaixo para habilitar o IIS:

Nota

Caso a função Servidor Web (IIS) já tenha sido adicionada ao servidor este passo-a-passo pode ser pulado. Importante apenas garantir que os serviços de função ASP e Autenticação do Windows tenham sidos instalados para o Servidor Web (para mais detalhes confira o passo 4).

 

 

Deck of Cards
effectDuration0.5
idconfig-iis
historyfalse
effectTypefade
Card
id1
labelPasso 1

 

  • Para habilitar o IIS (caso não esta habilitado ainda), devemos utilizar o Gerenciador de Servidores, e adicionar uma nova função. Para adicionar uma nova função, clique na opção Funções e em seguida em Adicionar funções.

 

Image Removed

 

Card
id2
labelPasso 2

 

  • A tela de Assistente para Adicionar Funções é aberta. Assinale a opção Servidor Web (IIS) e clique no botão Próximo.

 

Image Removed

 

Card
id3
labelPasso 3

 

  • Uma tela com uma introdução ao Servidor Web (IIS) é apresentada. Clique no botão Próximo para continuar com a instalação.

 

Image Removed

 

Card
id4
labelPasso 4

 

  • Para que seja possível configurar e disponibilizar o serviço de autenticação remota é necessário a instalação dos seguintes serviços de função ASP, Extensões ISAPI e Autenticação do Windows. Assinale estes serviços de funções e clique em Próximo.

 

Image Removed

 

  • Os serviços de funções ASP e Extenções ISAPI são necessários para a execução do script ASP responsável pela autenticação remota e o serviço de função Autenticação do Windows é necessário para que o navegador possa enviar as credenciais para a aplicação efetuar as validações necessárias no Active Directory.

 

Card
id5
labelPasso 5

 

  • A tela de confirmação de instalação é apresentada. Clique em Instalar para finalizar a instalação do Servidor Web (IIS).

 

Image Removed

 

Card
id6
labelPasso 6

 

  • Após finalizar a instalação é apresentada a tela de Resultados da Instalação com o resumo dos itens instalados. Clique em Fechar.

 

Image Removed

 

 

Configuração e Disponibilização do Serviço

Após possuir o IIS instalado e com as funções de serviços necessárias é possível configurar o serviço de autenticação remota. Lembrando que o apoio da equipe de infraestrutura é fundamental, siga o passo-a-passo abaixo para configurar e disponibilizar o serviço de autenticação remota:

 

...

effectDuration0.5
iddsso-app-iis
historyfalse
effectTypefade
Card
id1
labelPasso 1

 

  • Primeiramente devemos criar um arquivo chamado redirect.html com o seguinte conteúdo (lembre-se que a chave FLUIG-HOST deve ser substituída pelo endereço do servidor Fluig):

 

Bloco de código
languagexml
titleredirect.html
<!DOCTYPE html>
<html> 
  <head>           
    <meta http-equiv="refresh" content="0;URL='http://{FLUIG-HOST}/portal/home?dssoError=invalidUser'" />    
  </head>
</html>

 

  • Seguindo, devemos criar um diretório de conteúdo para o site que iremos criar nos próximos passos. Neste diretório colocamos o script ASP baixado do Fluig (ver item Habilitando e Configurando o Fluig) e o arquivo redirect.html.

 

Image Removed

 

Card
id2
labelPasso 2

 

  • No IIS agora precisamos criar um novo site, que será a aplicação responsável em fornecer o serviço de autenticação remota. Para criar um novo site clique na ação Adicionar Site . A tela Adicionar Site será apresentada, informe o nome do site (por exemplo fluigsso), o tipo, endereço IP e porta, que devem ser definidos pelo administrador do servidor.

 

Image Removed

 

Informações

O endereço informado nas configurações do site é valor que deve ser informado no campo URL script de autenticação na configuração da autenticação integrada no Fluig (ver passo 3 do item Habilitando e Configurando o Fluig).

 

 

...

id3
labelPasso 3

 

  • Outro ponto a ser configurado é autenticação deste site. Realizamos isto através do item Autenticação.

Image Removed

 

Card
id4
labelPasso 4

 

  • Devemos habilitar a forma de autenticação Autenticação do Windows e desabilitar todas as outras opções de autenticação.

 

Image Removed

 

...

id5
labelPasso 5

 

  • Existe um detalhe que deve ser tratado na autenticação, que são os provedores utilizados pela Autenticação do Windows. Clique com o botão direito na opção Autenticação do Windows e em seguida clicar na opção Provedores.

Image Removed

 

...

id6
labelPasso 6

 

  • Devemos deixar apenas a opção NTLM. Todas as outras devem ser excluídas. Se isso não for feito, pode ser exigido do usuário a entrada de credenciais via caixa de diálogo do navegador. Não esquecer que existe outra configuração a ser feita diretamente no navegador (que veremos em tópicos posteriores) para evitar este problema.

Image Removed

 

Card
id7
labelPasso 7

 

  • Em alguns casos, não será possível negociar as credenciais do usuário via NTML e então o IIS redirecionará o usuário para uma página de erro (HTTP 401.2 - Não autorizado). Para evitar este comportamento é possível definir uma página de erro personalizada onde o usuário é redirecionado para a página de login do Fluig ao invés de uma página de erro do IIS. 
  • Realizamos isto através do item Páginas de Erro.

 

Image Removed

 

Card
id8
labelPasso 8

 

  • Para adicionar uma nova página de erro clique na opção Adicionar.

 

Image Removed

 

Card
id9
labelPasso 9

 

  • A tela Adicionar Página de Erro Personalizado é apresentada. Informe o código de status 401.2, selecione a ação de resposta Inserir conteúdo do arquivo estático na resposta de erro e no campo caminho do arquivo informe o caminho relativo da raiz do site para o arquivo redirect.html.

 

Image Removed

 

  • Para finalizar e adicionar a página de erro clique no botão OK.

 

none


Aviso
titleAtenção

Os ERPs TOTVS Vitae, TOTVS Educacional e TOTVS RH (Linha Datasul) estão em processo de descontinuação da integração via EAI com o Fluig LMS, porém, nesse momento a funcionalidade não será retirada do produto. Caso haja novas mudanças, os usuários serão comunicados previamente. 

Objetivo

O objetivo deste guia é habilitar e configurar o console EAI para a utilização nas integrações com TOTVS Vitae, TOTVS Educacional e TOTVS RH (Linha Datasul).


Visão Geral

Existe um conjunto de técnicas e padrões para a integração de ERPs TOTVS, conhecida como “Mensagem Única TOTVS”. Este conjunto de definições estabelece como os produtos TOTVS devem se comunicar e engloba questões como:

  • Como definir uma mensagem de integração;
  • Como as mensagens são identificadas;
  • Como é feita a troca de mensagens;
  • Como as mensagens são rastreadas.

O componente EAI 2.0 (Java), do produto Datasul encapsula estas definições e permite que os produtos possam se integrar no novo modelo com um esforço menor para a sua incorporação. Ele define um conjunto de interfaces que devem ser implementadas pelo produto hospedeiro (host application) que tratam, basicamente, da persistência das informações que circulam pelo EAI em banco de dados. Além disso, o EAI também espera que o aplicativo hospedeiro disponibilize um web service que será a porta de entrada para as mensagens enviadas pelos outros aplicativos.

Em contrapartida, o EAI 2.0 fornece toda a lógica de identificação, processamento e rastreabilidade de mensagens além de uma interface web para o gerenciamento da instância.


Definição de mensagem única TotvsMessage

Durante o processo de consolidação de marcas, iniciado pela TOTVS, várias empresas diferentes foram adquiridas e com elas vários produtos passaram a compor o portfólio de ofertas disponível aos clientes. Esta expansão de ofertas permitiu que clientes de uma marca, antes limitados pelas opções com aquela “etiqueta”, pudesse agora compor o seu ambiente de TI utilizando produtos de origens diferentes (Ex.: TOTVS Educacional + TOTVS Fluig Plataforma, TOTVS RH (Linha Datasul) + TOTVS Fluig Plataforma).

Esta mesma iniciativa já era uma prática comum nos clientes, porém todo o custo envolvido na integração entre estes aplicativos era visto pelo cliente como parte da escolha de utilizar-se de produtos de diferentes fornecedores. Uma vez que estes produtos passam a fazer parte de uma mesma oferta, os clientes TOTVS passam a demandar que estes produtos sejam naturalmente integrados. Isto significa que se antes o cliente arcava com o custo e o risco envolvido em uma integração, ele agora entende que a TOTVS deve prover soluções já integradas, independente da origem dos produtos oferecidos.

Com o objetivo de padronizar a integrações com os produtos TOTVS, foi definida uma nova diretriz para os projetos de integração: A de que todos os produtos TOTVS devam trabalhar com uma mensagem XML únicos evitando, desta forma, o processo de transformação de mensagens. Neste cenário, teríamos o seguinte quadro:


Image Added


Neste cenário, qualquer produto TOTVS trabalhará com o mesmo XML para uma mesma entidade, ou seja, supondo que tenhamos um XML correspondente à mensagem de CLIENTES, ela poderá ser enviada para qualquer um dos produtos que suporte o recebimento desta entidade.

Uma vez que os vários produtos TOTVS terão um “idioma” comum (o XML Único), as integrações entre estes produtos não exigirão mais que as mensagens sejam transformadas de um formato para outro. Com isto, será possível conectar diretamente dois produtos, como no diagrama abaixo:


Image Added


Além de questões referentes ao formato das mensagens, a mensagem única também torna uniforme o tratamento destas mensagens XML pelos aplicativos, principalmente no que diz respeito à capacidade de rastreamento.

Todos os processos devem respeitar o fluxo normal de troca de mensagens no padrão de Mensagem Única TOTVS. O fluxo de mensagens poderá ocorrer nos seguintes sentidos:

  • TOTVS Fluig Plataforma à Educacional: a plataforma TOTVS Fluig irá consumir o webservice da linha RM para recebimento de mensagens únicas. O mesmo também será responsável por encaminhar as mensagens para o EAI RM, que processará a mesma (englobando todas as especificidades requeridas) e encaminhará o retorno de acordo com o tipo de comunicação definida (síncrona ou assíncrona).

  • Educacional à TOTVS Fluig Plataforma: os dados serão trafegados pelo fluxo normal até a fila de Integração TBC, onde o mesmo irá consumir o webservice do EAI da plataforma TOTVS Fluig para envio da(s) mensagem(s). Após a resposta da plataforma, o RM atualizará o registro com o status de processamento e demais dados, no Monitor da Fila de Mensagem Única.

  • TOTVS Fluig Plataforma à TOTVS RH (Linha Datasul): a plataforma TOTVS Fluig irá consumir o webservice do TOTVS RH (Linha Datasul) para recebimento de mensagens únicas. Ele também será responsável por encaminhar as mensagens para o EAI TOTVS RH (Linha Datasul), que as processará (englobando todas as especificidades requeridas) e encaminhará o retorno de acordo com o tipo de comunicação definida (síncrona ou assíncrona).

Assim como definido no protocolo de comunicação de mensagens únicas, a comunicação pode ser efetuada de duas formas:

  • Síncrona: O sistema de origem gera uma mensagem de integração na sua fila e envia ao webservice de destino. O processo na origem aguarda o processamento da mensagem no destino e ao receber o retorno atualiza o status do processamento na fila de integração. (Mensagens síncronas não podem ser processadas/reprocessadas no monitor da fila de integração.)
  • Assíncrona: O sistema de origem gera uma mensagem de integração na sua fila, envia ao webservice de destino e aguarda somente a confirmação de recebimento da mensagem. O processo na origem não fica parado aguardando o processamento da mensagem no destino.

Ao término do processamento da mensagem por parte do sistema de destino o mesmo envia outra mensagem de retorno ao sistema de origem com o status do processamento.

As mensagens assíncronas podem ser processadas (status pendente) ou reprocessadas (status erro) manualmente através do monitor da fila de integração.

Nota: Cada linha irá programar a fila de integração a sua maneira, respeitando o protocolo definido para mensagem padrão e guardando o log de processamento de todas as mensagens recebidas ou enviadas.


EAI vs Arquitetura multi-empresa

Um ponto relevante para a incorporação do EAI 2.0 na plataforma TOTVS Fluig é a sua característica de multi-empresa. Esta arquitetura permite que várias empresas utilizem a mesma instalação do produto de forma independente e transparente, gerando a percepção de que cada um possui uma instância própria do produto.

Isto significa que, do ponto de vista de integração, cada Empresa também deve ser independente e possuir um conjunto próprio de integrações, mensagens, etc. Do ponto de vista lógico, cada empresa teria a sua “instância” do EAI para integração mas, do ponto de vista físico, uma única instância do (componente EAI) deverá gerenciar as integrações de cada uma das empresas individualmente.

Sempre que uma mensagem é recebida na plataforma TOTVS Fluig, ela deve vir com a autenticação de um usuário da empresa e, a partir dessa autenticação, a plataforma realiza o login do usuário e sabe a qual empresa a mensagem foi direcionada.


EAI Console

O EAI Console é a ferramenta, fornecida pelo EAI 2.0, que permite gerenciar todos os aspectos relativos à gestão da integração, desde a configuração da instância do EAI, a ativação de mensagens, o cadastro de aplicativos externos e a consulta de mensagens enviadas/recebidas.

O acesso ao EAI Console é restrito ao administrador da empresa e pode ser feito a partir de Aprendizado → AdministrarConsole EAI.


Recebimento de mensagem

Quando um aplicativo externo envia uma mensagem a um aplicativo hospedeiro do EAI ele deverá informar um usuário e senha que deverá ser validado contra os usuários cadastrados na plataforma TOTVS Fluig. Para que o e-learning permita que este usuário receba esta mensagem ele deverá ter um papel específico configurado no produto (Recurso "LMSEAI - Aprendizado - EAI" permissão "Acessar"). Isto torna flexível o modelo de autenticação uma vez que o cliente poderá utilizar o usuário administrador (que possui todas as roles, inclusive para recebimento de mensagens), criar um usuário específico para integrações (usuário eai, por exemplo) ou, ainda, criar usuários específicos para cada produto integrado.

Vale lembrar que além da permissão específica para o recebimento de mensagens, o usuário utilizado também deverá ter permissões que o habilitam a efetuar a transação que a mensagem pretende fazer. Por exemplo, para que a mensagem de criação de matrícula na turma seja processada com sucesso, o usuário utilizado deverá ter permissão para realizar matrícula na turma, ou seja, permissão de execução na turma.


Configuração do Console EAI


Deck of Cards
effectDuration0.5
historyfalse
idfluig-config
effectTypefade
Card
defaulttrue
id1
labelPasso 1
titleAcessando as configurações do sistema


  • Efetue o login na plataforma TOTVS Fluig utilizando o usuário administrador da empresa, e então acesse Aprendizado → Administrar → Console EAI.


Image Added


Card
id2
labelPasso 2
titleBem Vindo ao Console EAI


  • A primeira tela se refere a tela de boas vindas, clique em Next para continuar.


Image Added


Card
id3
labelPasso 3
titleSeleção do Host Application


  • Na segunda tela informe o host da aplicação.


Image Added


Card
id4
labelPasso 4
titleConfigure o Host Application


  • Na terceira tela deve ser preenchido o nome da aplicação, o usuário e senha do usuário integrador (usuário da plataforma), uma descrição (opcional) e se o xml das mensagens devem ser validadas com os xmls do EAI. Essa validação não é para valores dos campos da mensagem e sim para o formato do XML.


Image Added


Card
id5
labelPasso 5
titleBusca de Mensagens


  • Nessa tela é possível buscar todas as mensagens recebidas e enviadas através do console EAI. É possível buscar através de um UUID específico da mensagem, pela aplicação (externa ou host), pelo status da mensagem, pelo tipo da transação ou informando um intervalo de datas.


Image Added


Card
id6
labelPasso 6
titleConfiguração de Transações do Host


  • Nessa tela o usuário habilita quais as transações que estão disponíveis para as integrações. Deve ser selecionado se a transação esta habilitada para enviar (send), para receber (receive) ou para os dois (both).


Image Added


Card
id7
labelPasso 7
titleDetalhes dos Aplicativos Externos


  • Nessa tela o usuário configura os aplicativos externos que farão a integração com o TOTVS Fluig Plataforma. Para adicionar um novo aplicativo externo clique em Add new external application. Caso já tenha algum aplicativo cadastrado é possível selecionar o registro e atualizá-lo clicando no botão Connection information ou visualizar as transações disponíveis no aplicativo externo clicando em Transactions list.


Image Added


Card
id8
labelPasso 8
titleConfiguração de novo Aplicativo Externo


  • Após clicar em Add new external application o usuário deve adicionar o endereço WSDL do aplicativo externo, a porta e o usuário e senha de um usuário integrador válido no aplicativo externo (Usuário do aplicativo externo. Ex Usuário do RM). Esse usuário deve estar cadastrado no aplicativo externo e não na plataforma TOTVS Fluig.


Image Added


Card
id9
labelPasso 9
titleTransações do novo Aplicativo Externo


  • Após preencher as informações do aplicativo externo e clicar em Next, serão exibidas todas as transações habilitadas do aplicativo externo. Caso esteja tudo correto, clique em Finish para finalizar o cadastro do aplicativo externo.


Image Added


Card
id10
labelPasso 10
titleConfiguração de Rotas


  • Depois de concluída a inclusão de um aplicativo externo, clique em Host application > Send routes, selecione o External application cadastrado e serão listadas todas as mensagem que a plataforma envia. Selecione todas para habilitá-las e clique em Save changes.


Image Added



Carga inicial de treinamentos do TOTVS Fluig Plataforma ao TOTVS RH (Linha Datasul)


Deck of Cards
effectDuration0.5
historyfalse
idfluig-config
Card
id10
labelPasso 10

 

  • Finalizadas as configurações, é possível realizar um teste diretamente no script. Para isto basta executar o script no navegador com o parâmetro de consulta debug=1, que neste exemplo foi http://10.80.128.251:8180/remote_auth.asp?debug=1
  • Quando acrescentado o parâmetro de consulta debug=1, o script é informado para executar em modo debug, no qual ele retorna diversos valores que nos ajudam a depurar o serviço de autenticação remota. No exemplo executado, podemos ver que foi retornado o usuário 'João da Silva' e que a autenticação está funcionando corretamente.

 

Image Removed

 

  • Uma vez concluída estas configurações é possível efetuar a autenticação integrada.
  • Como teste final, autentique no Windows utilizando as credenciais de um usuário válido do Active Directory. Em seguida acesse o Fluig. O acesso ao Fluig não exigirá login e senha e já autenticará o usuário autenticado no Windows.

 

 

 

Configuração do Browser

É necessário configurar o browser do usuário para que ele utilize autenticação Windows (NTLM) com o script de autenticação remota (remote_auth.asp).

Mesmo que o serviço de autenticação remota 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 Active Directory.

 

Internet Explorer e Google Chrome

No caso dos navegadores Internet Explorer e Google Chrome, as configurações de segurança e autenticação devem ser realizadas através das Opções da Internet do Internet Explorer, pois os dois navegadores irão assumir estas configurações realizadas.

 

Deck of Cards
effectDuration0.5
idie-chrome-config
historyfalse
effectTypefade
Para começar, devemos acessar o menu Opções da Internet, no Internet Explorer:

Image Removed

Na sequência, devemos escolher a aba Segurança, selecionar a opção Intranet Local e então clicar no botão Sites, para informar a URL do servidor de autenticação remota. Isto garante que possamos aplicar o envio de credenciais do Windows apenas para a URL do servidor de autenticação remota. Outras aplicações e sites permanecem como estão.

Image Removed

 

  • Para adicionar o endereço do servidor de autenticação remota precisamos clicar no botão Avançadas:

 

Image Removed

 

  • Informamos a URL do servidor de autenticação remota no campo Adicionar este site à zona e então clicamos no botão Adicionar. Podemos fechar a tela clicando no botão Fechar:

 

Image Removed

 

É 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 Local. Para consultar esta tela, basta selecionar Intranet Local e clicar no botão Nível personalizado:

Image Removed

Card
defaulttrue
id1
labelPasso 1
Card
defaulttrue
id2
labelPasso 2
Card
defaulttrue
id3
labelPasso 3
Card
defaulttrue
id4
labelPasso4

 

Mozilla Firefox

O Firefox deve ser configurado de uma maneira um pouco diferente:

 

...

effectDuration0.5
idfirefox-config
historyfalse
effectTypefade

...

defaulttrue
id1
labelPasso 1

 

  • Em primeiro lugar, precisamos digitar about:config na barra de endereços, para poder acessar as configurações do Firefox:

 

Image Removed

  • Uma mensagem de alerta normalmente é exibida. Para continuar, basta clicar no botão de confirmação. No nosso exemplo, o botão Serei cuidadoso, prometo!
titleAcessando as configurações do sistema


  • Efetue o login na plataforma TOTVS Fluig utilizando o usuário administrador da empresa e então acesse Aprendizado → Administrar → Configuração de treinamentos e trilhas.


Image Added


Card
id2
labelPasso 2
titleBem Vindo ao Console EAI


  • Nesta tela é possível exportar os treinamentos já cadastrados na plataforma utilizando o botão Exportar.
  • Também é possível configurar se os usuários poderão finalizar pela plataforma sua matrícula integrada com o TOTVS RH (Linha Datasul) (Sim / Não).


Image Added



Integração na inclusão de dados

Todos os registros da plataforma TOTVS Fluig criados através da integração com sistemas externos ficam ligados aos registros externos.

Exemplo:

  • Quando o RM Vitae envia um usuário para o TOTVS Fluig Plataforma através da integração, esse usuário fica ligado ao registro no RM Vitae. Quando houver uma alteração nesse usuário no RM Vitae, essa alteração será replicada no TOTVS Fluig Plataforma.
    Se o usuário é inativado no RM Vitae ele será inativado no TOTVS Fluig Plataforma também.

  • Quando o RM Educacional envia uma turma para a plataforma TOTVS Fluig através da integração, essa turma fica ligada ao registro no RM Educacional. Quando houver uma alteração nessa turma no RM Educacional, essa alteração será replicada na plataforma TOTVS Fluig.
    Se a turma se chamava "Matemática" e passa a se chamar "Matemática - Noturno" no RM Educacional esta alteração também ocorrerá na plataforma.

  • Quando o RM Educacional envia uma matrícula em uma turma para a plataforma TOTVS Fluig através da integração, essa matrícula fica vinculada ao registro no RM Educacional. A matrícula só poderá ser finalizada no RM Educacional e quando isso acontecer, uma nova mensagem é enviada para a plataforma para que a matrícula seja finalizada nela também.
    Da mesma forma, se a matrícula for cancelada ou bloqueada no RM Educacional a matrícula da plataforma também será cancelada/bloqueada.

  • Quando o RM Vitae envia uma matrícula em uma trilha/treinamento para plataforma TOTVS Fluig através da integração, essa matrícula fica vinculada ao registro no RM Vitae. A matrícula só poderá ser finalizada no RM Vitae e quando isso acontecer, uma nova mensagem é enviada para a plataforma para que a matrícula seja finalizada nela também. Da mesma forma, se a matrícula for cancelada ou bloqueada no RM Vitae a matrícula da plataforma também será cancelada/bloqueada.

  • As requisições de matrículas nos treinamentos podem ser solicitadas pelos usuários na plataforma TOTVS Fluig desde que eles possuam permissão de Matricular em Treinamentos/Trilhas e de Executar no item trilha ou treinamento). Ao solicitar a matrícula de um treinamento na plataforma, a matrícula não é feita automaticamente, e sim enviada para o TOTVS RH (Linha Datasul) e então a plataforma aguarda uma mensagem de matrícula do usuário no TOTVS RH (Linha Datasul). A matrícula só poderá ser finalizada no TOTVS RH (Linha Datasul) e, quando isso acontecer, uma nova mensagem é enviada para a plataforma para que a matrícula seja finalizada nela também. Da mesma forma, se a matrícula for cancelada ou bloqueada no TOTVS RH (Linha Datasul), a matrícula da plataforma também será cancelada/bloqueada.

  • Quando o TOTVS Fluig Plataforma envia um treinamento para o TOTVS RH (Linha Datasul) através da integração, esse treinamento fica ligado ao registro TOTVS RH (Linha Datasul). Quando houver uma alteração nesse treinamento na plataforma, a alteração será replicada no TOTVS RH (Linha Datasul). Os treinamentos não podem ser cadastrados nem editados no TOTVS RH (Linha Datasul). As trilhas não são integradas.

Essa condição acontece com todos os registros integrados.

Exemplo: Usuários, Disciplinas, Turmas, Complementos de Disciplina, Treinamentos, Requisição de Matrículas, Matrículas em Turmas, Matrículas em Treinamentos, etc.


Na mensagem de integração de usuários é permitido o envio de uma lista de papéis e outra lista de grupos. Quando o usuário estiver sendo criado na plataforma TOTVS Fluig, esses papéis e grupos são listados e os papéis/grupos que não existem na plataforma são criados e associados ao usuário. Os papéis e grupos já existentes na plataforma serão apenas associados ao usuário não havendo nenhum tipo de atualização dos mesmo.

Caso seja uma atualização de usuários e na mensagem conste papéis ou grupos não existentes na plataforma TOTVS Fluig, os mesmos serão ignorados, sendo associados ao usuário apenas os existentes na plataforma. O processo de atualização não cria nem grupos e nem papéis.


Nota
titleImportante!

A partir da atualização 1.6.5-190219, o LMS não faz mais parte da plataforma para novas instalações.

Mas, não se preocupe: se você adquiriu a plataforma com o LMS incluso, entre em contato com o Suporte Fluig para que você consiga utiliza-lo normalmente – mesmo após a atualização 1.6.5-190219. Se você não lembra se o LMS está incluso ou não no seu pacote, consulte sua proposta comercial ou entre em contato com o seu ESN.

Card
defaulttrue
id2
labelPasso 2

 

  • As configurações de NTLM podem ser facilmente encontradas se digitarmos no campo Localizar, a palavra “ntlm”. Devemos manter as configurações como exibidas abaixo. A mais importante é network.automatic-ntlm-auth.trusted-urls, onde devemos informar a URL do servidor de autenticação remota:

 

Image Removed

 

  • Feito isso, temos também o Firefox configurado para utilização da autenticação integrada com o Windows do Fluig.

 

 

Group Policies

Configurar o browser de alguns poucos usuários é uma tarefa simples, porém, o cliente terá um problemas 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, pode ser executada uma série de tarefas automáticas, como por exemplo, configurar o navegador do usuário.

Internet Explorer e Google Chrome

O administrador deverá definir a seguinte configuração de GPO:

Configuração do Computador ► Modelos Administrativos ► Componentes do Windows ► Internet Explorer ► Painel de Controle da Internet ► Página Segurança:

 

Image Removed

 

 

Após habilitar a Lista de Atribuições de Sites a Zonas, o cliente deverá definir a URL do servidor de autenticação remota como membro da Zona da Intranet.

 

Image Removed

 

 

Desta forma, toda vez que um usuário membro do 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 a autenticação remota.

 

 

Mozilla Firefox

No caso do navegador Mozilla Firefox, não existe maneira direta de configurar o navegador a partir da GPO, porém, existem scripts que realizam esta configuração, e estes scripts podem ser executados a partir de uma GPO.

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 apresentado abaixo:

Configuração do Usuário ► Configurações do Windows ► Scripts (Logon/Logoff) ► Logon

 

Image Removed

 

 

Opções de arquitetura para Alta Disponibilidade

A autenticação remota 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. O administrador deverá desabilitar a autenticação integrada no Fluig ou corrigir o que for necessário para que o script fique online.

Existe uma opção onde podemos criar dois servidores de autenticação remota, o que fornece uma boa redundância do componente. Se um servidor estiver fora do ar, ou se uma aplicação estiver fora, o outro servidor assume a responsabilidade de manter online o serviço de autenticação remota.

Para isso é necessário disponibilizar um Load Balancer que terá a responsabilidade de fazer o redirecionamento, caso um dos dois servidores de autenticação remota esteja off-line.

 

 

 

...