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.