O projeto de codificação foi dividido em 3 etapas: • implementação dos casos de uso voltados ao Applet; • implementação dos casos de uso voltados ao Servlet;
• integração entre o Applet e o Servlet através de JavaScript e HTML Forms. As etapas de codificação são detalhadas a seguir.
4.2.1
Módulo Applet
O módulo Applet é o responsável pela interface com o usuário e acesso ao smart-card. Ele é carregado através da página do IdP, após um redirecionamento realizado pelo SP. Durante o redirecionamento, o SP carrega o navegador do usuário com uma instrução HTTP-GET contendo os seguintes parâmetros na URL:
SAMLRequest: Contém uma string comprimida (deflated) e codificada em Base64 de um elemento <samlp:AuthnRequest>.
RelayState: Representa algum valor de estado do SP (um id de seção, por exemplo). Esta informação só tem significado para o SP - o IdP apenas recebe este parâme- tro e o devolve ao SP sem nenhuma modificação, sendo, portanto, um mecanismo adicional do protocolo SAML para associar requisições a respostas.
No apêndice A.1 é mostrado um exemplo de elemento <samlp:AuthnRequest> resul- tante da decodificação e descompressão do parâmetro SAMLRequestURL de um redire- cionamento do SP para o IdP.
Tendo em vista que o Applet não processa o protocolo SAML, durante o carregamento inicial ele apenas captura os parâmetros SAMLRequest e RelayState para repassá-los ao Servlet, juntamente com os atributos do usuário presentes em seu certificado, após o logon com sucesso.
Concluída a inicialização, o Applet carrega as bibliotecas CSP presentes no sistema de arquivos, solicitando ao usuário a digitação do código PIN do smart-card inserido. Após a validação da credencial, os atributos do tipo Alternative Names são lidos, inter- pretados e decodificados (codificação ASN1). A tabela 4.1 mostra os atributos de usuário recuperados a partir da leitura dos identificadores de objeto (OID) do certificado digital.
Em seguida, o Applet deve repassar ao Servlet os parâmetros SAMLRequest e Re- layState (obtidos da URL de redirecionamento do SP), além dos atributos do usuário. Foram implementadas duas estratégias para a comunicação entre o Applet e o Servlet:
• Através do método “onSendData”, o Applet se comunica diretamente com o Servlet através de conexão HTTP com Content-Type “application/x-java-serialized-object”, encaminhando um objeto ICPSAMLContainer, o qual contém SAMLRequest, Re- layState e atributos do usuário. Recebe do Servlet uma resposta com outro ICP- SAMLContainer contendo os mesmos valores com exceção do SAMLRequest, cujo
4.2. CODIFICAÇÃO 47 Tabela 4.1: Atributos de usuário em um certificado A3 ICP-Brasil.
OID Atributo Descrição
2.16.76.1.3.1
DT_NASCIMENTO Data de nascimento
CPF Número do CPF
NIS Número de Identificação Social
RG Número do RG
RG_EXPEDIDOR Órgão expedidor do RG RG_UF Estado onde foi emitido o RG
2.16.76.1.3.5
TE Título de Eleitor TE_ZE Zona Eleitoral TE_SECAO Seção Eleitoral TE_CIDADE Cidade do eleitor TE_UF Estado do eleitor
2.16.76.1.3.6 CEI Cadastro Específico do INSS 1.3.6.1.4.1.311.20.2.3 MSAD_UPN Login para rede Microsoft
conteúdo é substituído por um elemento <samlp:Response>. A seguir, o Applet aciona o método “postRedirectToSP”, que envia os parâmetros SAMLResponse (contendo o elemento <samlp:Response>) e RelayState através de uma requisição HTTP-POST para a URL consumidora de asserções do SP (obtida a partir do ele- mento <samlp:AuthnRequest>).
• Utilizando o método “postRedirectToIdPServlet”, o Applet preenche um formulário oculto na página de autenticação, contendo os parâmetros SAMLRequest, RelayS- tate e os atributos do usuário. A seguir, efetua um redirecionamento para o Servlet, enviando os parâmetros através da requisição HTTP-POST, deixando a cargo do Servlet o envio da resposta ao SP.
O diagrama de classes do Applet que implementa a funcionalidade descrita é mostrado na figura 4.1.
4.2.2
Módulo Servlet
Ao Servlet são destinadas as funções de tratamento de mensagens (requisições e res- postas) do protocolo SAML, Ele deve ser executado em um container de aplicação J2EE. Sua principais funções são:
• Implementar o perfil Web Single-Sign-On do protocolo SAML; • Gerar o XML de Metadados do IdP.
Web Single-Sign-On
A função de SSO do Servlet inicia com o recebimento dos parâmetros SAMLRequest, RelayState e atributos do usuário. Tendo em vista que o Applet implementa duas meto- dologias para envio dessas informações, o Servlet também codifica as duas modalidades
48 CAPÍTULO 4. IMPLEMENTAÇÃO DO AUTENTICADOR ICP/SAML Figura 4.1: Diagrama de classes do Applet.
4.2. CODIFICAÇÃO 49 de comunicação, checando o Content-Type da requisição para determinar o tratamento correto:
• Caso seja do tipo “application/x-java-serialized-object”, a conexão com o Applet é direta, e a requisição é recebida através de um objeto ICPSAMLContainer.
• Caso seja do tipo “html/text”, os parâmetros foram enviados através de HTTP- POST, por meio de um formulário oculto. O Servet lê os dados do formulário e cria um ICPSAMLContainer a partir dos dados recebidos.
O container é então processado, sendo extraído o elemento <samlp:AuthnRequest>. Em seguida, é criada uma asserção (<samlp:Assertion>) com base nos atributos do usuá- rio <samlp:AttributeStatement>. A asserção é assinada digitalmente utilizando o certifi- cado digital do IdP e encapsulada num elemento <samlp:Response>, o qual referencia a requisição à qual se relaciona (campo “InResponseTo”) e o endereço consumidor de asser- ções do SP (campo “AssertionConsumerServiceURL”). O elemento <samlp:Response> é, finalmente, assinado com o certificado digital do IdP. No apêndice A.2 é mostrado um exemplo de elemento <samlp:Response>, o qual é a resposta para o <samlp:AuthnRequest> mostrado em A.1.
Caso a requisição tenha sido recebida por conexão direta, a resposta ao Applet será através de um objeto ICPSAMLContainer, conforme já informado. Caberá ao Applet efetuar o redirecionamento ao SP. Por outro lado, se a requisição tiver ocorrido por meio de formulário oculto em HTTP-POST, o Servlet montará um novo formulário oculto, ge- rando os parâmetros SAMLResponse (contendo o elemento <samlp:response> codificado em Base64) e RelayState (copiado da requisição). O redirecionamento será realizado, en- tão, para o endereço consumidor de asserções do SP.
Geração de Metadados do IdP
Alguns SP podem carregar as informações do IdP de forma automática a partir de um descritor XML. Este descritor contém, além do identificador do IdP, os certificados digitais utilizados na assinatura mensagens e os endereços de recebimento das requisições. No apêndice A.3 é mostrado um exemplo de elemento XML contendo metadados do IdP.
O diagrama de classes do Servlet é mostrado na figura 4.2.
4.2.3
Integração dos módulos
Para realizar a integração das funcionalidades do Applet e do Servlet, foi criado um pacote de utilitários de uso comum a ambos. Este pacote é constituído de 3 classes:
ICPSAMLConstants: Define as constantes (endereços estáticos, nomenclatura de pa- râmetros, campos de formulário, entre outros) utilizadas em todo o projeto;
ICPSAMLContainer: Classe que armazena uma informação SAML (requisição ou resposta), o RelayState do SP e os atributos do usuário. É utilizada quando a co- municação entre o Applet e o Servlet se dá através do Content-Type “application/x- java-serialized-object”.
50 CAPÍTULO 4. IMPLEMENTAÇÃO DO AUTENTICADOR ICP/SAML Figura 4.2: Diagrama de classes do Servlet.
4.3. TESTES 51