Autenticação por webservices

Se você já possui um webservice para autenticação de assinantes, envie um chamado para suporte.maven.com.br com as instruções para chamada e parâmetros de exemplo para podermos testar.


Formatos de webservice suportados: REST ou SOAP Formatos de entrada: Cabeçalhos (headers), Parâmetros, GET/PUT/POST Formato de saída: Sugerimos a saída em Json, contudo, você pode entregar o conteúdo em XML ou text/plain.


Como funciona a autenticação por webservice? O sistema será customizado para invocar o serviço sempre que o usuário tentar autenticar na ferramenta, seja via web ou aplicativos. Quem chama o serviço é a aplicação servidor (server-to-server) e não o cliente, que por sua vez desconhecerá o endereço do seu webservice.


O que o webservice deve retornar? Sugerimos um retorno em jSON no seguinte formato:


Para autenticação com sucesso: {"status":"OK", "userData":{"nome":"João","cidade":"São Paulo" }}


Para autenticação com erro: {"status":"ERROR", "message":"Usuário e /ou senha inválidos"}

  • Caso a sua aplicação seja multi-idiomas você pode entregar códigos de retorno e nos enviar o mapa de códigos e mensagens que devem ser exibidas.
  • Caso você precise executar validações de negócio dependendo dos dados a serem retornados, informe estas regras para a Maven para que possamos viabilizar a integração.


Autenticação por Token


A Autenticação por Token permite o uso de formatos de integração que exigem que não sejam trafegados o par de usuário/senha nos servidores da Maven. Neste caso recomendamos a abordagem de autenticação por token [SSO]. Este token pode ser da Maven ou de terceiros.

Ponto de atenção


Para ter acesso aos recursos, você precisa confirmar a ativação do módulo de webservice para a sua publicação através de um chamado em suporte.maven.com.br.


Autenticação por token da Maven


A Maven possui webservice habilitado para clientes que precisem gerar um token e utiliza-lo nos links internos de suas publicações. O webservice é no formato SOAP mas se você precisar de serviços no formato REST avise-nos que enviaremos o serviço em servidor específico.

  • O limite usual para o tamanho total da linha URL gerada com os parâmetros utilizado pela maioria dos navegadores e servidores fica ao redor de 2000 caracteres. Caso a quantidade de informação utilizada gere linhas perto deste tamanho, o link pode não funcionar, pois o navegador ou o servidor truncará a url. Neste caso, é aconselhado utilizar o método POST, ao invés de GET.


Gerando o token

Endereço do webservice SOAP: http://{servidor}/CustomerWS?wsdl
Serviço: generateMapToken
Parâmetro: mapa de chave / valor no formato:
 <entry key="?" value="?"/>
 <entry key="?" value="?"/>
 ...


Entradas obrigatórias

Sendo entradas obrigatórias: user e pelo menos uma das seguintes: ip e/ou expiry_minutes. Também conter a data e hora em que foi realizada a solicitação do token. Ou seja, a lista de entradas deve ter pelo menos, por exemplo, as seguintes variações abaixo:


Ou seja, numa solicitação somente com ip, ela ficaria assim: 
<entry key="user" value="nome_do_usuario"/>
<entry key="ip" value="200.300.400.500"/>


somente com expiry_minutes: 
<entry key="user" value="nome_do_usuario"/>
<entry key="expiry_minutes" value="7"/>
<entry key="simple_date" value="2018-12-31 23:59"/>


com ambos: 
<entry key="user" value="nome_do_usuario"/>
<entry key="ip" value="200.300.400.500"/>
<entry key="expiry_minutes" value="7"/>
<entry key="simple_date" value="2018-12-31 23:59"/>


Substituindo-se o conteúdo de value com as informações de nome de usuário e IP externo do assinante. Esta configuração permite acesso somente ao IP externo 200.300.400.500. Segue exemplo:


Somente com ip, ela ficaria assim:  
<entry key="user" value="nome_do_usuario"/>
<entry key="ip" value="200.300.400.500"/>


Substituindo-se o conteúdo de value para o expiry_minutes com a quantidade de minutos em número inteiro desejada que o token seja válido para realizar o login do assinante. Esta configuração permite acesso a qualquer IP, mas o token é válido por somente 7 minutos para o assinante poder acessar a publicação. Depois desse tempo, a sessão do assinante permanece ativa independente do token até ele fechar o navegador, fazer logout ou limpar os dados do navegador, por exemplo. Isso evita que o link seja utilizado por outras pessoas indefinidamente.


Além destas entradas obrigatórias, existem outras opcionais.


Entradas opcionais

  1. URL destino para direcionar o assinante no momento que realiza logout do sistema.


<entry key="url_logout" value="http://{url_destino}"/>

Este webservice gera um token/chave assimétrico criptografado que será validado pelo servidor quando você enviá-lo como parâmetro. Exemplo de uma chave de token gerada:


ab_C68B547DAFBE8FF2D03E8DCD05B97D3B069FB72DC6E7477E389CAA05F43D5276BA1785AF5EF947
5FD61261A3ED1D588D22A1F7DB0595D12B086610C34157D0179EA07EBF905DFE46AAF8E4B84D46698
7E6E8A58F2CCD86983FB7601FD37C184819961DE6ADFFC9A38819D91C7F539757067086A1C1709256
CD427C3FE83C470CAE679B6FB763E046DB09DD896A1298BCCF05883BCF5DCDC963F24412D25A4DB6


Utilizando o token

Imagine o token como uma chave de autenticação. No momento que você o gerou com o webservice acima, ele autenticou previamente o usuário para um determinado IP e gerou uma chave válida apenas para aquele momento, que não poderá ser utilizada por outra pessoa. Para utilizar o token, abra o link da sua publicação e o envie no parâmetro "key" sem quebra de linha. Exemplo:


http://{servidor}/pub/revista/?key={token}


Se o token for inválido, expirado, não validado para o IP correto ou o se o módulo de webservice estiver desabilitado para o cliente, não existirá autenticação.


Autenticação por token de terceiros


Pré-requisito

Você já deve possuir sua base de dados de assinantes e mecanismos de login em seu website, loja ou sistemas internos que sejam acessíveis na DMZ.


Como funciona

Você precisa solicitar para a equipe técnica que faz a gestão do sistema de login a criação de um conceito de token na estrutura de dados conforme exemplo abaixo.


Digamos que a sua tabela de assinantes se chame ASSINANTES e que possua as colunas ID, NOME, USUARIO, SENHA. Você precisará criar uma coluna adicional para registrar o token de login do usuário (TOKEN VARCHAR(200)). Você precisa também alterar o mecanismo de autenticação para registrar o token sempre que for realizado um login ou renovada a sessão do usuário se necessário.


Você precisa ainda construir um serviço web que informe para a Maven se o token está ativo ou não está ativo. Por exemplo:

www.seusite.com.br/valida_token.php?token=ABX8883838837729982882


Esse serviço deve imprimir 1 ou 0 na tela(ou true/false ou S/N etc..)


Mas o que significa "token ativo" e como gerar um token?


Token ativo

O token estar ativo significa que para a sua regra de negócio específica o assinante vinculado àquele token está logado/conectado e pode acessar outros recursos sem necessitar se autenticar novamente.


Como gerar o token?

Depende da sua necessidade de negócio. Geralmente ele é criptografado/codificado com MD5, Base64 ou Blowfish com 3DES se precisar de mais segurança. Vamos citar alguns exemplos abaixo.


  • Por tempo: O seu token pode carregar a informação da data e hora de geração do mesmo e fazer uma validação se o assinante está com o token expirado.
  • Por IP: O seu token pode validar se o assinante está em um range de IP's válidos.
  • Por existência: O seu token pode ser válido apenas se existir, sendo que o seu sistema tornaria o TOKEN NULO na tabela de assinantes para invalidar o mesmo.
  • Por regra de negócio: O seu token pode carregar inúmeras informações criptografadas, como nome do usuário, edições que ele tem acesso, regras de negócio e permissões de visibilidade etc... Se precisar de integrações neste nível de granularidade entre em contato conosco para discutirmos a viabilidade do projeto.


Como integrar?

Pronto, concluí o meu sistema de tokens e gerei o link de validação. O que fazer agora? O último passo é você enviar através de um chamado para suporte.maven.com.br o link de validação que iremos habilitar a validação de token na sua conta. Envie também um usuário e senha para que possamos realizar testes.


Cookie Session

Com o formato de autenticação por cookies o sistema tentará importar um cookie do seu portal para manter a navegação do usuário na web. Algumas premissas são necessárias:


a) O visualizador precisa estar hospedado em servidor que atenda com o mesmo domínio do seu portal. b) As restrições de cross-domain do apache do seu portal devem estar corretas. c) Você deve fornecer um serviço de revalidação do cookie.


Como fazer

Primeiro armazene no cookie do seu portal alguma chave de validação da sessão do usuário. É muito comum utilizar um token pois ele é relacionado ao leitor na base de dados e pode ser utilizado também em aplicativos. Informe para a Maven o nome do atributo no cookie onde a informação deverá ser buscada e o domain onde o cookie foi atribuído.


Precisaremos que você nos informe também o link do serviço de revalidação do token caso exista, senão iremos apenas controlar a existência do cookie e sua data de expiração.