Live Chat Software by Kayako |
Configuração Avançada
Postado por Rafael Vital on 11/Apr 10:50
|
|
Configuração AvançadaClassificação: Classificado / Público 1 - SumárioO 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:
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çadaNeste 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 IMO 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 SMSNeste 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 VoiceO 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.
|