Muitas vezes é necessário vincular um dispositivo com um serviço de forma tal que o dispositivo tenha permissão de lançar dados dentro do serviço.
O YePAF inclui um exemplo na pasta samples/key-admin que pode ser usado como modelo para criar seus próprios gestores de chaves de forma tal que um dispositivo tenha ou não acesso a um recurso no serviço.
O propósito deste artigo é apenas mostrar como copiar e configurar ele para sua situação cabendo ao programador configurar bancos de dados e elementos de segurança necessários para o correto uso do mesmo. Também, cabe ao programador criar o código necessário para autenticar o dispositivo.
Criando o projeto
Digamos que seu projeto vai se chamar gestaoChaves. E que faremos um projeto webApp/bootstrap3
$ cd www $ yapp gestaoChaves --create --appType webApp --template bs3
Agora copiemos o exemplo para dentro da pasta
$ cp -r www/YeAPF/samples/key-admin/* www/gestaoChaves/
Configurando o YeAPF
Modifique seu yeapf.db.ini para forçar um login controlado pelo arquivo .htpasswd na pasta. Por ser um projeto que visa a segurança e não requer o uso do banco de dados, indique que você utilizará a segurança fornecida pelo serviror web (Geralmente o Apache2) colocando a variável cfgHtPasswdRequired em ‘yes‘
Com isso, o seu aplicativo passará a exigir que as requisições sejamm feitas apenas usando SSL, ou seja, usando https em lugar de http. Escapa ao escopo deste artigo ensinar como configurar seu apache para operar sobre SSL, mas aqui pode encontrar um bom exemplo: http://www.onlamp.com/pub/a/onlamp/2008/03/04/step-by-step-configuring-ssl-under-apache.html
Rode o configure.php na pasta, lembrando que se já tem um db.csv, pode ser melhor destruir esse arquivo e deixar que o configure.php gere um novo a partir do yeapf.db.ini
Crie um arquivo .htaccess dentro da www/gestaoChaves com o seguinte conteúdo:
AuthType Basic AuthName "restricted area" AuthUserFile /var/www/html/gestaoChaves/.htpasswd require valid-user
Agora crie o arquivo /var/www/html/gestaoChaves/.htpasswd (Obvio que a pasta depende da sua distribuição e configuração local do servidor de páginas)
O conteúdo do .htpasswd pode ser gerado online neste atalho: http://www.htaccesstools.com/htpasswd-generator/
Personalizando
Altere os nomes dos arquivos que tem a palavra ‘default’ no nome pois eles serão sobre-escritos na atualização do YeAPF.
Assim, e_index_default.html vira e_index.html e keys.config.default.php vira keys.config.php por citar dois exemplos. Repita com os outros arquivos que tenham _default.
Fazendo assim, as suas versões do exemplo serão mantidas caso atualize a pasta usando rsync, cp ou unzip.
O arquivo labels.default.inc (que deve já ter sido renomado para labels.inc) possui todas as etiquetas que o aplicativo usa para identificar as diferentes partes do aplicativo para o usuário.
Por exemplo, a global lblProjects vem por padrão com o valor ‘Projects’ mas poderia ser chamado de ‘Secções’ pelo programador que seria isso que o usuário iria visualizar na tela.
Esses valores podem ser trocados a qualquer momento, então faça seus testes até ficar do jeito que você quer.
Internamente, porém, o aplicativo entende que são dispositivos dentro de um projeto. É por isso que no keys.config.php a nomenclatura interna é ‘Project’ e ‘Device’. Neste arquivo você controle os tamanhos das chaves geradas, só isso.
Conectando um dispositivo
É responsabilidade do programador criar o serviço que serve as chaves e o cliente que as utilizará. Tanto faz se é um aplicativo desktop, web ou mobile.
A forma mais simples é por restful. Nesse caso seu cliente deve ser configurado para conectar-se com a pasta criada. Digamos que seu ip de serviço é 172.18.32.45 com um certificado ssl bem configurado (ou seja, não pode ser auto-assinado senão o consumidor não sai do lugar) o seu javascript na inicialização do projeto teria alguma coisa como:
ycomm.setDataLocation("https://172.18.32.45/gestaoChaves/rest.php");
Do lado do servidor, o programador pode utilizar algumas funções para verificar os valores passados pelo cliente.
| Função | Parametros | Funcionamento |
|---|---|---|
| _projectExists() | projectKey | Devolve TRUE ou FALSE indicando se o projeto indicado existe |
| _verifyDeviceExistsInProject() | projectKey deviceId |
Devolve TRUE ou FALSE para indicar se o dispositivo existe no projeto |
| _registerDeviceIntoProject() | projectKey deviceId |
Registra um dispositivo no projeto |
| _verifyDeviceBond() | projectKey deviceId deviceKey |
Devolve ‘Y’ se a chave de dispositivo é a gerada para o par (projectKey:deviceId) na tela de gestão |
| _do_login | projectId deviceId |
Gera um identificador de sessão com o qual o dispositivo pode fazer suas requisições. |
| _do_logoff | deviceId | Desconecta um dispositivo do sistema (mas sem perder as credenciais). Repare que não usa o sessionId gerado pelo _do_login |
| _recreateDeviceKey | projectKey deviceId createSequence=false, &a &b |
Gera uma nova chave para o dispositivo. É o equivalente a clicar no botão de gerar chave de dispositivo na tela de gestão. |
|
Os parâmetros createSequence, a e b servem para gerar (ou não) a sequência de controle. Essa sequência serve para controlar requisições de validação do cliente quando se está querendo evitar a clonagem de um nó em um ambiente de servidores distribuidos. Então em um aplicativo de autenticação pode ser obviado. |
||