Para acessar “Autenticação”, clique em v.5.50 - Configurações do Logine selecione a opção “Autenticação”. Você irá para a aba “Geral” com as configurações de apresentação da ferramenta.
...
Para alterar as configurações, basta clicar na aba “Geral”, ir até o campo “Logo” e clicar em “Escolher ficheiro”arquivo”. Depois, selecionar a logo que deseja incluir e clicar em “Salvar” para que a logo possa ser modificada.
...
Se optar pelas outras mudanças também, como a “Cor de fundo”, basta clicar no campo “Cor de fundo” e escolher uma cor clicando sobre ela.
...
É importante informar que, ao selecionar essa opção, todos os usuários serão obrigados a trocar a senha na próxima vez que logarem na ferramenta, e seguir os padrões da “senha forte”. Se você não quiser optar por essas configurações basta clicar em “Restaurar Padrão” e todas as configurações anteriores serão retomadas.
...
Troca de senha.
...
Oauth
A Plataforma Lecom permite a autenticação de usuários pelo servidor de autenticação Oauth. Para ter acesso a esse recurso, basta clicar no botão de v.5.50 - Configurações do Logine escolher a opção “Autenticação”. Após selecionar, deverá escolher a aba “Oauth” para realizar as configurações necessárias.
...
Os campos dispostos nessa área do sistema permitem que você configure o sistema para que os usuários possam realizar o login por meio de outra aplicação, como o Google. Atualmente, a ferramenta permite a configuração homologada do Google. Para realizar a configuração, você deverá clicar no box “Habilitado” e preencher todos os outros campos obrigatórios. O campo “Habilitado” indica se o servidor está ou não habilitado e, quando selecionado, ele aparecerá no login do usuário.
O campo “Provedor de autenticação” Autenticação” apresenta os servidores disponíveis para a configuração. Atualmente, a ferramenta apresenta o “Google” como um servidor disponível homologado. Você deverá selecionar a opção “Google”. Ao fazer a seleção, outros campos automaticamente serão preenchidos facilitando a sua configuração.
Os campos “Client ID” e “Client Secret” “ID do cliente” e “Senha do cliente” precisam ser configurados e são informações que devem ser disponibilizadas pelo servidor do Google no momento de preenchimento. O administrador do sistema que estiver realizando a configuração de autenticação deverá fazer um cadastro no servidor do Google e o mesmo disponibilizará algumas informações para preenchimento desses campos que não foram apresentados imediatamente.
Os campos “Access Token”, “User Authorization URI”, “Client Authentication scheme” e “User info URI” “URI de token de acesso”, “URI de autorização de usuário”, “Esquema de autenticação do cliente” e “URI de informação do usuário” já virão preenchidos automaticamente ao selecionar a opção “Google”. O “Access Token” “URI de token de acesso” é um campo destinado ao preenchimento da URI que retorna o Token. Caso o valor seja diferente, é possível trocá-lo. Para isso, vale verificar essa informação no manual do servidor que está sendo utilizado.
O campo “User Authorization URI” “URI de autorização de usuário” é destinado à autorização do usuário, e o “Client Authentication scheme” “Esquema de autenticação do cliente”, para preenchimento da forma de autenticação. O campo “User Info URI” “URI de informação do usuário” é destinado a preenchimento da URI que busca as informações do usuário. Todos esses campos já virão preenchidos e podem ser alterados dependendo do manual do servidor.
No caso do check box “Use current URI” “Usar a URI corrente”, que é indicado para envio da requisição, o campo vem marcado. Mas é preciso ter atenção, ele não poderá ser marcado se o ambiente estiver em cluster ou com algum proxy reverso.
Outro campo que é apresentado no formulário de configuração da OAuth é o “Pre established redirect URI” “URI de redirecionamento pré-estabelecido”. Esse campo é utilizado para preencher a URI preestabelecida para ser enviada para o provedor de autenticação. Esse campo só faz sentido ser preenchido se o campo “Use current URI” “Usar a URI corrente” não estiver marcado. Caso contrário, o preenchimento não terá efeito.
O campo “Scope” “Escopo” não é obrigatório de ser preenchido. Ele é destinado ao preenchimento dos escopos, mas é importante consultar a documentação do provedor que está sendo utilizado para maiores informações.
“Token Name” “Nome do token” é um campo não obrigatório, destinado ao preenchimento do nome do token enviado pelo provedor. O campo “Authentication Scheme” “Esquema de autenticação”, reservado para o preenchimento do schema esquema de autenticação, também não é um campo obrigatório.
O “Path” “Caminho” destinado ao caminho da URI usado para autenticação deverá ser utilizado sempre no padrão “/oauth/<nome_do_provedor>/login”. O campo “Principal extractor class” “Extrator do identificador do usuário” é um campo não obrigatório para o preenchimento do nome da classe responsável por extrair o nome do usuário da resposta de autenticação do provedor. Alguns provedores não necessitam dessa configuração. Então, para o Google, é necessário usar “br.com.lecom.oauth.connect.config.extractor.GooglePrincipalExtractor”.
...
A Plataforma Lecom permite a autenticação de usuários pelo servidor de autenticação SAML. Para ter acesso a esse recurso, basta clicar no botão de v.5.50 - Configurações do Logine escolher a opção “Autenticação”. Após selecionar, você deverá escolher a aba “SAML” para realizar as configurações necessárias.
...
Em “Tipo de configuração”, você poderá escolher uma das duas opções de configurações que podem ser realizadas, por URL ou por upload. Quando selecionado por URL, o campo “Metadata URL” deve ser preenchido com o caminho para acessar o xml de metadados do provedor. Caso a opção seja pelo upload, aparecerá no campo “Metadata” a opção de realizar o upload do xml de metadados do provedor. Para inserir o arquivo, basta clicar em “Escolher ficheiro”arquivo”. Uma janela irá abrir para que você escolha o arquivo. Selecione o arquivo e clique em abrir, o arquivo será carregado.
Os próximos campos são necessários, pois a comunicação do protocolo faz uma assinatura da chamada para que a mesma seja validada no provedor de autenticação com o mesmo xml de metadados que foi enviado no momento do cadastro no nosso serviço. Esse xml possui a nossa assinatura com base no nosso certificado SSL.
O campo “Keystore path” “Caminho Keystore” é destinado ao preenchimento do caminho da keystore e o “Keystore password” “Senha Keystore” é a definição da senha da keystore.
Em “Keystore default key” “Chave predetermina Keystore”, é importante informar que o host do provedor de autenticação deve ser importado dentro da keystore e a key criada para o mesmo deve ser inserida nesse campo.
...
Para acessar a configuração do LDAP, basta acessar o menu v.5.50 - Configurações do Login, escolher a opção “Autenticação” e acessar a aba “LDAP”.
...
As configurações do LDAP são divididas em três sessões: “Configurações Básicas”, “Campos do LDAP usados pelo SSO” e “Campos para Login login automático”.
Em “Configurações Básicas”, temos o campo “Urls”, que é usado para inserir uma ou mais urls do LDAP separadas por vírgula. Ex: “ldap://host1, ldap://host2, ldap:// host3”. Essas outras urls servem como segurança, ou seja, caso o primeiro host caia ou não esteja disponível, o segundo entra em ação e assim sucessivamente. Também é possível usar SSL. Para isso, é necessário informar a porta junto ao endereço. Ex: “ldaps://host:636”. Dessa forma, é necessário importar o certificado como trust dentro da keyStore usada pelo servidor, apenas clicando no botão “Importar Certificado”, que aparecerá logo após do campo “Urls” ser preenchido com um host SSL.
No campo “Base”, preenchemos os objetos DC que representam o topo de uma árvore LDAP que usa o DNS para definir seu namespace. O Active Directory é um exemplo de árvore do LDAP. O designador para um domínio do Active Directory com o nome DNS company com seria dc=Company, dc=com.
O campo “User or “Usuário ou DN” é usado para preenchimento do nome do usuário ou da DN. Um nome que inclua todo o caminho de um objeto para a raiz do namespace LDAP é chamado de nome distinto ou DN. Um exemplo de DN, para um usuário chamado CSantana, cujo objeto está armazenado no contêiner “cn=Users” em um domínio chamado company.com seria cn=CSantana, cn=Usuários, dc=company, dc=com.
O campo “User search base” “Base de pesquisa do usuário” é usado para preenchimento dos objetos da OU que atuam como contêineres que contêm outros objetos. Eles fornecem estrutura para o namespace LDAP. As OUs são o único contêiner de uso geral disponível para administradores no Active Directory. Um nome de OU de exemplo seria ou=Accounting. Esse campo, além de ser usado no momento do login, é usado para importação dos usuários na base.
O campo “Password” “Senha” é usado para o preenchimento da senha do usuário definido no campo “User or DN”.
O campo “Filter” “Filtro” é usado para o preenchimento do filtro no momento do login e para a busca de usuários na importação de usuários do LDAP.
Na sessão “Campos do LDAP usados pelo SSO”, temos os campos para o preenchimento. O “Login key” “Login” é usado para comparação do nome do usuário no momento do login. O campo “Name key” “Nome”, usado no momento da importação para indicar em que campo do LDAP está o nome do usuário. O campo “Mail Lei” “E-mail”, usado no momento da importação para indicar em que campo do LDAP está o e-mail do usuário.
...
As opções “Usar Contexto Kerberos” e “KDC Debug” não são obrigatórias, porém, podem ser usadas em alguns contextos específicos. Como exemplo, caso seja necessário fazer alguma análise de falha, selecionar a opção “KDC Debug” pode ajudar. Caso o cliente exija o uso o Kerberos, inclusive como gerenciamento de contexto do LDAP, selecione a opção “Usar Contexto Kerberos”. Vale ressaltar que esse último caso é muito difícil de acontecer.
O campo “Krb Conf Path” “Caminho da configuração do KRB” é usado para configurar o caminho completo o krb5.conf criado automaticamente.
O campo “Kcc Service “Serviço KDC Principal” é usado para configurar o principal criado anteriormente com o comando setspn para referenciar o usuário gerenciador do AD do BPM a um serviço. No caso o serviço é o próprio BPM.
O “Keytab Path” “Caminho do Keytab” é o campo destinado a configurar a localização do keytab criado anteriormente. Já o “Kdc Field To Filter’ “Campo KDC’ é um campo do AD no qual é referenciado o nome do usuário no formato nome.usuario@ream.usado. Normalmente é usado o valor “userPrincipalName”.
...