Configuração Avançada

Classificação: Classificado / Público
Proprietário: Rafael Vital
Usuários: Público em geral
Versão: 0.1 (Criada em 11/04/2017)
Alterado último por: Rafael Vital

1 - Sumário

O ProApps IM/2-FA (Two-factor Authentication System) é uma solução robusta de implementação de autenticação forte fundada no mínimo em 2 fatores de autenticação. A solução é composta dos seguintes componentes:

• SAE: é o motor de autenticação forte (strong authentication engine), que implementa toda a lógica do processo de autenticação baseada em múltiplos fatores. É composta de um sistema de gestão de identidade mínimo para sustentar a base de informação inerente a autenticação do usuário; é o gerador lógico das senhas e hashs OTP.
• GUI: interface gráfica com o usuário que permite administração geral da solução.
• Action Provider: WebService de automação de operações de CRUD (Criação, Leitura, Atualização e Remoção, do acrônimo em inglês) padrão RESTful JSON; adequado para realizar todas as operações de preparação e solicitação de segundo fator de autenticação; é a interface que permite o disparo remoto do processo de autenticação forte; permite interoperabilidade da solução com produtos legados e de terceiros.
• 2-FA Delivery: é a interface que realiza a entrega de fato do segundo fator de autenticação; tipicamente é composto de um agente de envio de mensagens SMS por celular, smartphones iPhone, Android ou tablets iPad e Android; pode em casos especiais ser senhas sequenciais não reutilizáveis impressas em papel ou cartão.

O ProApps 2-FA (Two-factor Authentication System) implementa padrões de fato da indústria, com destaque a: RFC-4226; RFC-6238; RFC-2104; OPIE; FIPS-180/4; padrão formal 2-FA OTP Time Based e Event Based.

Para facilitar o entendimento do documento na imagem abaixo o menu é apresentado conforme na aplicação.

2 - Configuração Avançada

Neste segundo submenu do módulo IM o usuário poderá definir informações como, por exemplo: regras que serão aceitas no cadastro de usuários, o número de tentativas que o usuário terá antes que seu acesso seja bloqueado, dentre outras configurações.   

2.1 - Configuração do IM

O primeiro submenu de “Configuração Avançada” que será analisado é o “Configuração do IM”. Na imagem abaixo é possível visualizar a tela que será aberta e logo após a figura os campos serão explicados separadamente.

Api-Key: Neste campo é apresentada a chave de acesso a API do ProApps IM.

Tempo de antecedência válidos: O objetivo deste campo é definir até quantos tokens serão aceitos após os mesmos serem trocados. Por medidas de segurança é aconselhável que seja aceito somente até o antepenúltimo token gerado, isso não elimina a possibilidade de aumentar a quantidade de token aceitos. Porém, ao escolher a opção de “3 últimos token válidos” à diante a mensagem abaixo aparecerá na tela explicando detalhadamente o uso seguro desta funcionalidade. Caso seja de interesse do usuário o mesmo poderá aceitar o termo de uso.   

No último campo da página há quatro botões que podem ser marcados/desmarcados e que irão influenciar diretamente no cadastro de usuários que será explicado no submenu “Carteiras & Usuários”. Os botões serão explicados abaixo de maneira separada para melhor entendimento dos mesmos.

Login igual a e-mail: caso este item esteja marcado o login(ID) criado para o usuário deverá ser um e-mail.

Documento de usuário único: este item define se será permitido o cadastro de usuários com o mesmo documento, caso esta opção esteja marcada não será permitido usuários com o mesmo documento.

Secret Key dos dispositivos igual do principal: Quando utilizado o cadastro de devices para um usuário, caso este botão esteja marcado, a chave que será encaminhada a biblioteca de geração de tokens será a mesma utilizada nos envios de SMS. Já se a opção estiver desmarcada será enviado uma chave diferente para cada dispositivo, aumentando assim a segurança.

Telefone Mobile IM de usuário único: este item define se será permitido o cadastro de usuários com o mesmo telefone mobile que receberá os tokens do 2FA para a realização de autenticação.    

2.2 - Config Service 2FA SMS

Neste submenu o administrador poderá configurar para que um token 2FA seja enviado para o usuário via SMS. Dois pontos merecem destaque, o primeiro é que diferente do caráter dinâmico do aplicativo Google Authenticator, o usuário irá receber um único token via mensagem para realizar o login. O segundo ponto importante é que ao configurar o envio de uma mensagem a mesma não será enviada diretamente ao cliente, e sim para um servidor local(fachada) e a partir daí fica a responsabilidade da fachada de encaminhar a mensagem para um Broker de SMS. Não é recomendado que seja feito a requisição diretamente para o Broker, sempre é recomendado que uma fachada trate esta informação.

Na imagem abaixo é possível visualizar a tela inicial e após a figura os campos serão explicados com detalhes.

Authentication type: Neste campo o administrador deverá definir por meio de qual protocolo a mensagem será enviada para o usuário. Há duas opções que podem ser escolhidas SOAP (Simple Object Access Protocol - protocolo utilizado para troca de informações estruturadas em uma plataforma descentralizada e distribuída). A outra opção é Rest (Representational State Transfer - é uma abstração da arquitetura Web que consiste de um conjunto coordenado de restrições arquiteturais aplicadas a componentes, conectores e elementos de dados dentro de um sistema de hipermídia distribuído). Por questão de organização do documento será explicado a opção SOAP em primeiro lugar e, posteriormente, a opção Rest.       

URL: Neste campo será passada uma URL com o domínio de um servidor juntamente com o protocolo WSDL para que seja estabelecida a comunicação e o consequente envio da mensagem.

No próximo campo é preciso antecipar que serão duas configurações completamente diferentes. A primeira configuração que será explicada é o “Basic”. Posteriormente, a opção “Advanced” será explicada.    

SOAP type: Com a opção “Basic” escolhida o usuário precisará fornecer o protocolo WSDL para que a comunicação seja estabelecida. Recomendamos a utilização da opção Soap Advanced, pois assim não temos a necessidade de intervenção no servidor para o funcionamento da requisição, já a configuração Basic será necessário intervenção no servidor, o que pode gerar problemas futuros com atualizações.

Mensagem: Neste campo é apresentada a mensagem que será enviada para o cliente. É importante observar que na mensagem há a sigla OTP (one-time password) ou, em português, senha para apenas uma vez, e como o próprio nome indica o token poderá ser utilizado somente uma vez.   

Configuração Avançada: Caso o usuário deseje enviar alguma outra informação via SMS, as variáveis devem ser colocados neste campo.

Conforme mencionado acima, a partir desse ponto voltaremos ao campo SOAP type e a opção “Advanced” será explicada. Como pode ser percebido pela imagem abaixo ao escolher a opção “Advanced” a configuração será completamente diferente da “Basic”. Logo após a figura há uma explicação de cada campo.

Call SOAP: Neste campo deve ser incluído uma chamada SOAP.

Options PHP Request: Neste campo o usuário deverá informar valores no formato JSON com as opções do PHP SoapClient que serão utilizadas. Os valor informados devem estar no formato inteiro. 

Attributes: Neste campo o usuário deverá informar valores no formato JSON com os atributos a serem setados na chamada SOAP.

Request: Neste campo o usuário irá informar valores no formato JSON para que o ProApps encaminhar na chamada feita com o call SOAP.

Response: Neste campo o usuário receberá um retorno quando o SMS for encaminhado com sucesso. O objetivo é que o ProApps possa verificar se as chaves informadas estão presentes na resposta do servidor. Caso o campo acima esteja vazio ou seja informado um JSON inválido, basta uma resposta válida do servidor para que a mensagem seja considerada com sucesso nos relatórios.

Logo abaixo do campo response o usuário poderá definir se ele/ela deseja que o valor seja testado a cada nova chamada SOAP.

A partir deste ponto será explicado o uso do protocolo Rest e na imagem abaixo é possível visualizar a tela inicial, os campos e logo após a figura há uma explicação geral.

URL: Neste campo será passada uma URL com o domínio de um servidor juntamente com o protocolo WSDL para que seja estabelecida a comunicação e o consequente envio da mensagem.

Authorization: Neste campo há três opções diferentes de autorizações: OAuth (ao utilizar esse método o usuário habilita que a aplicação se auto autentique em outra aplicação); Basic (utiliza o protocolo http, portanto consegue trabalhar com browsers, tendo como desvantagem o envio como texto claro o que pode ser corrigido utilizando o protocolo https); Digest (esse método gera um hash de user names, domínios e senhas).    

Key: Neste campo o usuário deverá digitar qual é a chave que será utilizada para descriptografar a mensagem enviada.

Secret: Neste campo o usuário deverá cadastrar a senha que será utilizada para autenticar no servidor.

Token: Neste campo o usuário deverá cadastrar o token que será emitido no momento em que o cliente realizar a autenticação de maneira bem-sucedida. Este token é utilizado para definir quais são as permissões de cada cliente.

Token Secret: Neste campo o usuário irá cadastrar o token secret, este é enviado juntamente com o token de acesso, e é similar ao “Secret”.

HTTP method: Neste campo o usuário irá definir qual método http será utilizado, GET ou POST. Estes métodos são utilizados em aplicações nas quais existe a necessidade de passar valores de uma página para outra, com o intuito de realizar operações como consultas bancárias e autenticação de usuários.

GET - este método é utilizado quando se quer passar poucas ou pequenas informações para realizar uma pesquisa ou simplesmente passar uma informação para outra página através da URL. POST - Este método utiliza a URI (de Uniform Resource Identifier) para envio de informações ao servidor. A URI não é retornável ao cliente, o que torna o método POST mais seguro, pois não expõe os dados enviados no navegador.      

Header: A informação contida no campo Header determina que o conteúdo deve estar no formato JSON, codificado através de UTF-8.

Na imagem abaixo está contida a continuação da página, com os respectivos campos e logo após a figura há uma explicação de cada campo.

Body: Neste campo deve ser incluído o conteúdo da mensagem que será enviada aos clientes.

Chaves retorno: Neste campo os usuário poderá informar um JSON de retorno quando o SMS for encaminhado com sucesso, para que o ProApps possa verificar se as chaves informadas estarão presentes na resposta do servidor, para que então o ProApps informe nos relatórios que o SMS foi encaminhado com sucesso. 

Logo abaixo do campo response o usuário poderá definir se ele/ela deseja que o valor seja testado a cada nova chamada Rest.

Após finalizar as configurações tanto de SOAP quanto de Rest o usuário poderá alternar para nova guia, Broker 2. Nesta página é possível definir qual tipo de configuração de serviço será utilizado: None, Backup ou Balance. É importante ressaltar que independente do tipo de autenticação utilizado, o padrão aqui é igual para ambos. Na imagem abaixo é possível visualizar a tela inicial do Broker 2.

None: A primeira opção “None” estará marcada por padrão ao acessar a página, porém a mesma não apresenta qualquer possibilidade de configuração. A imagem abaixo mostra como fica a página ao escolher alguma outra opção. Independente do que for escolhido a configuração do tipo de autenticação é similar ao descrito nos campos acima.

Backup: O Backup é ativado quando a resposta para chamada do servidor Primário está fora dos padrões configurados, gerando um novo disparo do SMS conforme as configurações do servidor Secundário.

Balance: Com o Balance ativado é feito o disparo de SMS por ambos os servidores. Caso a resposta para chamada esteja fora dos padrões configurados, será gerando um novo disparo do SMS conforme as configurações do outro servidor.

A última guia da página “Mensagens” permite que o usuário personalize a mensagem que será enviada, com as informações que este julgar necessária. Na imagem abaixo é possível visualizar a tela inicial e logo após a figura os campos serão explicados em detalhes.

Mensagem: Neste campo serão apresentadas as mensagens customizadas que foram cadastradas no campo “Adicionar”. 

Adicionar: Neste campo o usuário irá incluir um “ID” de maneira a identificar a mensagem que será cadastrada, definir se a mensagem terá um padrão ou não e por último incluir as tags no campo da mensagem. Ao finalizar o processo descrito acima é necessário clicar sobre o botão com o símbolo “+” para que a mensagem seja incluído no campo acima. Por último basta salvar as informações da página clicando no botão “Salvar” no canto superior direito da tela.

2.3 - Config Service 2FA Voice

O conceito deste submenu é similar aos outros já apresentados aqui neste documento, porém o serviço de fornecimento de 2FA via chamada de voz no momento encontra-se desabilitado.

2.4 - Tipo de Autenticação

Neste submenu de “Configuração Avançada” o gerenciador poderá definir  como será realizada a autenticação do usuário no sistema. Dentre as opções há como forçar que a senha seja mais forte, configurar a senha para AuthSys além do MFA (multi-fator de autenticação). Subdivido em quatro abas diferentes, abaixo há uma explicação de cada uma.

2.4.1 - Configuração 

A primeira aba que será analisada é “Configuração” e aqui o gerenciador deve definir quantas vezes os usuários poderão errar a senha ao tentar realizar login no sistema. Na imagem abaixo pode ser visualizada a página inicial da aplicação que inicialmente está desabilitada.

O primeiro campo visualizado na tela é “Número de Tentativas” e caso o usuário clique neste botão será possível definir qual é a quantidade de vezes que um usuário poderá errar a senha, o limite é 10. Após definir este campo a tela terá a inclusão de mais dois campos como pode ser visualizado na imagem abaixo. Logo após há uma explicação dos novos campos.

Tipo de Bloqueio: Caso o usuário erre a senha a quantidade de vezes determinada o mesmo será bloqueado e o bloqueio será de duas maneiras, definitivo ou temporário. Caso o bloqueio seja definitivo somente um administrador poderá liberar para que o usuário tente logar novamente, já no bloqueio temporário será estipulado a quantidade de tempo, em minutos, que o usuário ficará bloqueado.   

Minutos Bloqueados: Neste campo deve ser definido quantos minutos o usuário ficará bloqueado caso no campo “Tipo de Bloqueio” a opção escolhida seja bloqueio temporário.

2.4.2 - Global

A segunda aba analisada é a “Global” e nela o gerenciador pode, se assim desejar, forçar que a senha do usuário tenha um padrão forte (com números, letras e caracteres especiais) ou um padrão fraco (somente letras ou números), essas e outras funcionalidades que serão explicadas a seguir. Abaixo há uma imagem da tela inicial com algumas configurações já realizadas e logo após os campos serão explicados em detalhes.

Password Hash: Neste campo é definido qual hash será utilizado para salvar a senha do usuário no IM. Por default este campo é sha256.

Password differ: Neste campo é possível definir quantas senhas novas terão que ser criadas pelo usuário antes que uma senha já utilizada possa ser repetida. Por default este recurso é desabilitado.

Password reset every: Neste campo é possível definir de quanto em quanto tempo a senha do usuário deverá ser trocada, caso contrário o mesmo ficará bloqueado por falta de troca de senha. Por default este recurso é desabilitado.

Password Strength: Neste campo é possível definir qual é a força da senha a ser salva, sendo que cada nível escolhido terá uma especificação diferente. Por default este recurso é desabilitado.

Type of password: Após escolher o nível será apresentado um campo que irá apresentar a expressão regular que validará os caracteres obrigatórios que devem ser utilizados para a senha. Você poderá customizar a expressão regular a ser utilizada e assim especificar as regras conforme o seu negócio. Por default este recurso é desabilitado   

Password Test: Neste campo poderá ser realizado um teste com o objetivo de confirmar que a senha foi incluída de acordo com a expressão regular definida no item “Type of password”.

2.4.3 - Auth Sys

A terceira aba analisada é “AuthSys”. Apesar de ter características similares a autenticação “Global” difere em um ponto crucial, o usuário deverá ter uma AuthSys de mesmo nome associado a si para que as regras vinculadas a esta sobreponham as regras Globais, caso contrário as regras cadastradas em AuthSys não serão aplicadas no usuário e passará a valer a regra Global. Na imagem abaixo é possível visualizar a tela da aplicação com algumas configurações já realizadas.

Enabled: Por default é desabilitado, sendo que quando habilitado a regra a ser aplicado será a primeira encontrada na lista que estiver cadastrada na estrutura do usuário, vejam que é “first match wins”, desprezando assim as demais regras configuradas.

AuthSys: Lista das regras configuradas, sendo que cada regra poderá ser editada, excluída e reposicionadas para cima ou para baixo.

Adicionar: as mesmas regras existentes na aba Global, mas será específica para um AuthSys.

AuthSys ID: Neste campo deverá ser digitado o identificador do AuthSys que, posteriormente, deverá existir no cadastro de AuthSys do usuário para que seja aplicado a regra definida no lugar das configuração Global.    

Password Hash: conforme documentado para a aba Global.

Password differ: conforme documentado para a aba Global.

Password reset every: conforme documentado para a aba Global.

Password Strength: conforme documentado para a aba Global.

Type of password:  conforme documentado para a aba Global. 

Password Test:  conforme documentado para a aba Global.

2.4.4 - MFA

A quarta e última aba é a “MFA”, referente ao multi-fator de autenticação para Hash Always Present. Desta forma realiza a autenticação do usuário através da validação um hash(valor) existente em um AuthValue do usuário.  A regra a ser utilizada será conforme parâmetro “mfa” informado na API “user/authenticationHash - Autenticação 1FA Usuário Hash Always Present”. Na imagem abaixo é possível visualizar a tela conforme na aplicação e logo após a imagem há uma explicação de cada campo.

MFA: Lista de todas as regras cadastradas.

Adicionar: Campos para configurar uma regra específica.

MFA ID: Identificador a ser informado na API “user/authenticationHash - Autenticação 1FA Usuário Hash Always Present”. Recomendado que seja um inteiro para que não fique explicito a regra de negócio a ser utilizada na chamada de API.

AuthSys: Neste campo deverá ser cadastrado o identificador do AuthSys que, posteriormente, deverá existir no cadastro de AuthSys do usuário.

AuthClaim: Neste campo deverá ser cadastrado o identificador do AuthClaim que, posteriormente, deverá existir no cadastro de AuthClaim do usuário.

AuthValue: Neste campo poderá ser cadastrado o valor do AuthValue que, posteriormente, deverá existir no cadastro de AuthValue do usuário. Caso não seja informado nenhum valor, o mesmo será dinâmico e deverá ser passado na chamada da API “user/authenticationHash”. Um exemplo de utilização para isso é quando a posição do AuthValue é o identificado de um device.

Position: Quando o conteúdo do AuthValue for do tipo JSON ou CSV, deverá ser informado a posição do mesmo para que o IM possa compara adequadamente. Quando o tipo for JSON deverá ser informado a “chave” do dicionário, sendo que quando for um CSV deverá ser informado a coluna a ser utilizada.

2.5 - ACLs Carteiras & Usuários

Neste submenu o objetivo é criar uma lista de controle de acesso para que cada usuário tenha acesso somente as informações que lhe são pertinentes. ACL, a sigla do título, pode ser desmembrada em Access Control List ou em português, Lista de controle de acesso.

Para explicar este campo vale lembrar a maneira que são criados novos usuários no sistema. Para ter acesso basta seguir o caminho: Gerenciar ProApps>Usuários>Nova. Ao finalizar o cadastro um novo usuário poderá realizar login na aplicação e caso o administrador deseje que o novo usuário não tenha acesso a todas as informações da aplicação é possível realizar este bloqueio.Na imagem abaixo é possível visualizar a tela inicial e logo após a uma explicação de cada campo e como serão realizadas configuradas as permissões para cada usuário.

Como pode ser visualizado na imagem acima o campo “Grupo de Usuários” permite a seleção de grupos diferentes porém ao clicar neste botão o usuário verá que nenhum grupo poderá ser selecionado apesar de conter o grupo “System Administrator”. Para que seja possível incluir usuários com permissões específicas e necessário clicar no botão “clique aqui” logo abaixo deste campo. Ao clicar neste botão um novo grupo de usuários será gerado e o mesmo pode ser visualizado através do caminho: Gerenciar ProApps>Grupo de Usuários. O primeiro grupo que será visualizado neste submenu é o “System administrator” porém, um pouco abaixo, o usuário verá que o grupo “IM ACL Carteiras & Usuários” foi criado, conforme imagem a seguir.

Depois de criar o novo grupo de usuários o próximo passo é associar um usuário cadastrado ao grupo de usuários “IM ACL Carteiras & Usuários”. Para isso é necessário seguir o seguinte caminho: Gerenciar ProApps>Usuários>Editar. Ao percorrer o caminho descrito o usuário chegará na página de edição de usuário conforme visualizado na imagem abaixo.

Analisando a imagem é possível perceber o campo “Grupo” com o grupo “System administrator” selecionado. Porém, após a criação do grupo “IM ACL Carteiras & Usuários”, o mesmo estará disponível e poderá ser selecionado neste campo.

Voltando ao submenu “ACLs Carteiras & Usuários” o grupo de usuários “IM ACL Carteiras & Usuários” estará disponível para editar quais tipos de permissões os usuários deste grupo terão. Na imagem abaixo é possível visualizar como será a tela apresentada assim que o grupo for selecionado.

Como pode ser percebido, inicialmente, todos os campos estão com a permissão negada. Porém isso pode ser alterado pelo usuário ao habilitar que o grupo de usuários possa realizar modificações nos documentos. Para alterações basta clicar no botão de seleção e mudar a opção para “Sim”. Ao habilitar a possibilidade dos usuários editarem as informações tanto de usuário quanto de carteiras as possibilidades de permissões irão se expandir, conforme imagem abaixo.

Como pode ser visto na figura ao habilitar a possibilidade de editar as informações diversos campos serão abertos para edição e caso o administrador deseje que algum campo não seja visualizado basta escolher a opção “Nenhum”. Dentre as outras opções dadas são “Visualizar” que permite somente a visualização das informações enquanto “Editar” permite que o usuário altere a informação.