3.4
Considerações finais sobre a etapa de modelagem
Utilizando algumas estruturas da linguagem UML foi possível modelar o sistema de autenticação SAML / ICP-Brasil proposto com um bom nível de detalhes, simplificando as etapas subsequentes de codificação e testes, além de propiciar documentação adequada para uma boa compreensão da solução e futuras manutenções desta.
Os diagramas de casos de uso representaram a etapa inicial de levantamento de re- quisitos, tomando por base as diretrizes de deperimetrização determinadas no capítulo 2. Estes diagramas permitiram determinar a existência de dois atores - usuário e navega- dor - que, apesar de atuarem em conjunto, executam interações distintas com os sistemas “autenticador” e “aplicação”.
Já os diagramas de sequência possibilitaram determinar o conjunto de interações (mé- todos e mensagens) entre os atores e o sistema, as quais haviam sido parcialmente in- dicadas pelos casos de uso. Além disso, ratificaram a necessidade da modelagem das funcionalidades de autenticação SAML de uma aplicação, uma vez que não seria possível validar o sistema autenticador sem uma aplicação compatível com SAML.
Capítulo 4
Implementação do Autenticador
ICP/SAML
Concluídos o levantamento de requisitos e modelagem descritos no capítulo 3, as eta- pas seguintes de desenvolvimento envolvem a codificação e a realização dos testes. Estas fases são abordadas neste capítulo, concluindo o desenvolvimento da solução proposta de softwarede autenticação federada, através de certificados ICP-Brasil.
4.1
Ferramentas de desenvolvimento utilizadas
A etapa de codificação leva em conta a definição da linguagem de programação, arqui- tetura de software (middleware, frameworks, containers de aplicação, entre outros com- ponentes) e ferramentas de apoio ao desenvolvimento, necessárias à transformação dos requisitos e modelo de software definidos no capítulo 3 em código fonte. Esta etapa en- volve ainda a configuração de ambiente onde o sistema será executado.
Este conjunto de tecnologias deve ser adequado ao desenvolvimento da solução pro- posta, levando em consideração seus requisitos. O software em questão é um mecanismo de autenticação federado cujo cerne é:
1. autenticação e captura de atributos do usuário através de certificados digitais A3/ICP- Brasil em smart-cards;
2. transmissão dos atributos à aplicação de destino, através de assertivas do protocolo SAML.
Logo, a escolha das ferramentas de desenvolvimento leva em consideração a adequa- ção das mesmas para os dois atributos fundamentais definidos: interação com smart-cards e com o protocolo SAML.
4.1.1
Linguagem de programação
Tendo em vista a necessidade de interação com smart-cards e o protocolo HTTP, sob o qual o SAML é executado, optou-se pela utilização da linguagem Java. A escolha
44 CAPÍTULO 4. IMPLEMENTAÇÃO DO AUTENTICADOR ICP/SAML justifica-se pelo fato de que existe um grande apoio da indústria de smart-cards à utili- zação de seus produtos através de Java. Todos os cartões fornecidos no Brasil visando a certificação digital ICP-Brasil são dotados de CSP - Cryptographic Service Provider (provedor de serviços criptográficos - biblioteca que dá acesso às funções criptográficas do dispositivo) compatível com a implementação Java do Public-Key Cryptography Stan- dards- PKCS #11 (especificação voltada à comunicação com dispositivos criptográficos em hardware).
Nesse sentido é importante notar que, independente da linguagem escolhida, existe a necessidade de interação com o CSP do smart-card, o que, em linhas gerais, significa di- zer que a parte do software responsável pela autenticação do usuário e captura dos atribu- tos de seu certificado digital deverá interagir com uma biblioteca - arquivo .dll (Windows) ou .so (Linux/MacOS) - presente no sistema de arquivos do computador do usuário.
4.1.2
Applet x Aplicação Desktop
Considerando a linguagem Java, a interação com uma biblioteca local do computa- dor do usuário requer que ao menos parte do código do sistema proposto seja executado localmente, podendo ser implementado através de uma das seguintes abordagens:
Aplicação Desktop: A aplicação é executada a partir do sistema de arquivos do compu- tador do usuário, necessitando assim de instalação prévia;
Applet: O código objeto Java é encapsulado num arquivo JAR e carregado a partir de um documento HTML no navegador do usuário. Requer que o código seja assinado digitalmente para interagir com o CSP.
Tendo em vista o contexto Web do protocolo SAML, a escolha pela implementação através de Applet é a mais adequada, permitindo que a aplicação seja carregada direta- mente a partir de uma página, sem necessidade de instalação prévia.
4.1.3
Applet x Servlet
Numa primeira análise, seria possível considerar que toda a solução de autenticação federada com smart-cards poderia ser implementada em Applet. Existem, no entanto, alguns problemas no uso dessa abordagem:
1. O sistema é executado inteiramente na estação do usuário, o que requer um conjunto maior de instruções incorporadas ao Applet, tornando-o maior e de carregamento e execução mais demorados;
2. As bibliotecas necessárias à implementação do protocolo SAML devem ser carre- gadas juntamente ao Applet, extendendo ainda mais o tempo de carregamento; 3. Tendo em vista que as mensagens SAML devem ser assinadas, o certificado digital
do IdP, sua chave privada e respectivas senhas precisam ser incorporados ao Applet. Um atacante pode usar engenharia reversa para recuperar esses dados e utilizá-los num ataque, se fazendo passar pelo IdP.
4.1. FERRAMENTAS DE DESENVOLVIMENTO UTILIZADAS 45 Dessa forma, percebe-se que parte do código (especialmente a geração de mensagens SAML) não deve incorporar o Applet e sim ser executada em um Servlet (código Java executado em contexto Web num servidor). Assim, é possível reduzir o Applet ao mínimo necessário para interagir com o usuário e seu smart-card, tornando-o mais leve e o seu carregamento mais rápido, deixando o processamento do protocolo SAML a cargo do Servlet.
Considerando a modelagem realizada no capítulo 3, os casos de uso “Autenticar Usuá- rio” e “Solicitar Certificado Digital e PIN” deverão ser implementados pelo Applet, en- quanto o caso de uso “Gerar Assertiva SAML” será codificado no Servlet.
4.1.4
Containerde aplicação
Tendo em vista a utilização de Servlet para implementação das funcionalidades do protocolo SAML, um container de aplicação J2EE deve ser utilizado. Optou-se pela utili- zação do Apache Tomcat [Apache 2012a], tendo em vista se tratar de uma implementação em código aberto, largamente utilizada pela comunidade acadêmica e corporativa.
Para o presente trabalho, foi utilizada a versão 7.0.33 do referido software.
4.1.5
OpenSAML
O protocolo SAML consiste basicamente de mensagens XML codificadas em schemas XML específicos. A utilização da biblioteca OpenSAML [Shibboleth 2012] permite ao desenvolvedor concentrar-se na lógica do protocolo, abstraindo aspectos de baixo nível como construção de strings XML e o tratamento (através de parser) de mensagens de texto.
A biblioteca é disponibilizada para as linguagens Java e C++, nas versões 1.0 e 2.0 do protocolo SAML . Optou-se pela utilização da versão 2.0, tendo em vista ser a mais recente.
4.1.6
Demais ferramentas utilizadas
Eclipse
O Eclipse [Eclipse 2012] é uma interface de desenvolvimento (IDE) compatível com diversas linguagens de programação, especialmente adequada ao desenvolvimento Java. Sua escolha se deu especialmente pela sua integração com o Apache Tomcat, permitindo execução e depuração de código em tempo de execução do Servlet.
SAMLTracer
O SAMLTracer [Morken 2012] é um plugin disponível para o navegador Mozilla Fi- refox. Permite o acompanhamento das interações HTTP, em especial a visualização das mensagens SAML trocadas entre o IdP e o SP.
46 CAPÍTULO 4. IMPLEMENTAÇÃO DO AUTENTICADOR ICP/SAML