Tendo em vista que o foco da dissertação é o estabelecimento de um mecanismo se- guro e eficaz de identidade federada, foi realizada uma pesquisa bibliográfica adicional a respeito das principais ferramentas existentes no mercado voltadas a esse propósito. Shibboleth
Segundo [Wangham et al. 2010], o projeto Shibboleth foi iniciado em 2000 pelo con- sórcio Internet2 e resultou na criação de uma arquitetura e implementação, em código aberto, de um Sistema de Gerenciamento de Identidade (SGI) voltado à identificação e autorização federados.
O projeto Shibboleth é um dos principais SGI destinados à criação de federações, sendo voltado especialmente ao âmbito acadêmico, com destaque para sua utilização na Comunidade Acadêmica Federada (CAFe/RNP) e na federação InCommon, norte- americana, mantida pelo consórcio Internet2. Nos últimos anos, passou a ser amplamente adotado também no ambiente corporativo.
Figura 2.5: Diagrama de mensagens do Shibboleth [Seabra 2009].
A característica principal do Shibboleth é a utilização do SAML, implementando no- tadamente o perfil Web Single-Sign-On deste protocolo. De acordo com [Seabra 2009], o funcionamento do Shibboleth segue o diagrama de sequência mostrado na figura 2.5:
2.5. IDENTIFICAÇÃO FEDERADA 25 1. O Utilizador tenta acessar o recurso disponibilizado pelo Provedor de Serviço. 2. Uma vez que o Utilizador não se encontra autenticado, o Provedor de Serviço o re-
direciona para o WAYF Server (Where Are You From Server), que tem como função apresentar uma lista de Provedores de Identidades suportados por aquele Provedor de Serviços.
3. O Utilizador, no WAYF Server, escolhe o seu Provedor de Identidade, a partir da lista disponibilizada por esse servidor.
4. O Utilizador é redirecionado para o seu Provedor de Identidade. 5. No Provedor de Identidade, é pedido ao Utilizador que se autentique.
6. O Utilizador autentica-se, é criado um identificador para ele e é redirecionado para o Provedor de Serviço que aloja o recurso que o Utilizador pretende acessar. O navegador do utilizador recebe um cookie para permitir o Single-Sign-On.
7. O Provedor de Serviço recebe o identificador.
8. O Provedor de Serviço vai usar o identificador para pedir diretamente ao Provedor de Identidade os atributos que necessita para poder tomar uma decisão de autoriza- ção.
9. O Provedor de Serviço recebe os atributos e toma então a decisão de permitir ou negar o acesso a esse o recurso ao Utilizador.
Kantara Initiative
Surgiu com o nome de Projeto Liberty Alliance (consórcio de mais de 160 organiza- ções privadas e governamentais). É composto por três componentes principais: Identity Federation Framework (ID-FF), Identity Web Services Framework (ID-WSF) e Identity Services Interface Specifications (ID-SIS). O funcionamento dos componentes é seme- lhante ao Shibboleth, provendo as mesmas funcionalidades.
Segundo [Wangham et al. 2010], um dos principais pontos positivos do projeto é sua influência em padrões como o SAML, cujas extensões propostas pela Liberty Alliance são hoje parte da versão 2.0 do SAML.
OpenID
De acordo com [Wangham et al. 2010], o OpenID surgiu em maio de 2005 como um projeto pessoal do desenvolvedor Brad Fitzpatrick, voltado à eliminar o problema de spamsem seu blog, o LiveJournal. Implementa sob o mesmo nome um protocolo e um serviço.
O usuário tem a liberdade de efetuar seu cadastro em qualquer servidor OpenID. Ao acessar algum serviço, o usuário é redirecionado ao servidor OpenID. Após efetuar logon com suas credenciais, o usuário é redirecionado de volta à página do serviço. Toda a
26 CAPÍTULO 2. PERÍMETRO X SEGURANÇA comunicação entre o servidor OpenID e o serviço é criptografada com chave assimétrica e realizada de forma indireta, através da URL do navegador do usuário.
O funcionamento do OpenID é explicitado na figura 2.6 (adaptado de [Seabra 2009]): 1. O Utilizador inicia a autenticação no Web Site (relying party) enviando o seu Uni- form Resource Identifier(URI), usando para isso o seu User-Agent (informado pelo navegador);
2. O site normaliza o URI (caso seja necessário) e processa o HTML do OpenID do Utilizador. Em seguida, estabelece um segredo compartilhado com o Provedor; 3. O navegador do Utilizador é redirecionado para o Provedor, onde o Utilizador pode
efetuar a autenticação;
4. O Provedor redireciona o browser do Utilizador para o site, enviando uma resposta; 5. O site verifica a assinatura da resposta e dá acesso ao Utilizador.
Figura 2.6: Diagrama de funcionamento do OpenID [Seabra 2009].
O OpenID já é utilizado em vários sítios da Internet, destacando-se Google, Yahoo, 4Shared, entre outros.
OpenAM
O projeto OpenAM, de código aberto, foi inicialmente desenvolvido pela Sun Mi- crosystems sob o nome de OpenSSO. Após a aquisição desta pela Oracle Corporation, o projeto foi descontinuado e um fork, sob o nome de OpenAM, passou a ser mantido pela empresa ForgeRock [ForgeRock 2012], como uma plataforma de gerenciamento de acesso e federação.
2.5. IDENTIFICAÇÃO FEDERADA 27 Totalmente desenvolvido em Java, possui grande aceitação no mercado corporativo. Possui uma grande quantidade de plugins, permitindo compatibilidade com diversos pro- tocolos de autenticação (como LDAP e Microsoft Active Directory) e federação (SAML e OpenID).
Conclusões sobre os soluções de identidade federada
Todos os mecanismos analisados possuem funcionamento semelhante, empregando as figuras do Provedor de Identidade (IdP) e do Provedor de Serviço (SP). Os mais utilizados atualmente são o Shibboleth (baseado em SAML) e o OpenID.
Pela análise realizada, percebe-se que nenhuma das soluções implementa diretamente um mecanismo de autenticação forte (dois ou três fatores de autenticação), utilizando geralmente o mecanismo tradicional de par de credenciais (usuário e senha), provendo autenticação de um fator (“algo que você saiba”).
Conquanto estes mecanismos implementem de forma eficaz a identificação federada, não atendem aos requisitos de segurança necessários à implementação das fases da depe- rimetrização, conforme analisado nas subseções 2.4.6 e 2.4.12. Para este objetivo se faz necessário o uso da identidade federada através de um mecanismo de autenticação forte, o qual é tratado no próximo capítulo.
Capítulo 3
Modelagem do Autenticador
ICP/SAML
Este capítulo aborda as fases de definição da proposta, levantamento de requisitos e modelagem de software de um mecanismo para autenticação federada através de certifica- dos digitais ICP-Brasil. Para esta etapa do projeto optou-se pela utilização da UML [OMG 2011], que é a linguagem de modelagem de software padrão de facto do mercado.
3.1
Definição da proposta de mecanismo de identificação
federada
Para definição da proposta, é necessário sobretudo definir o mecanismo de autenti- cação e o protocolo de identidade federada utilizado. Numa comparação entre diversos mecanismos de autenticação para sistemas de internet banking [Guimarães 2006], os cer- tificados digitais embarcados em smart-cards tiveram a mais alta avaliação no quesito ’segurança’ (juntamente com chips SIM, usados em celulares GSM).
No contexto nacional, a Infraestrutura de Chaves Públicas Brasileira (ICP-Brasil)[ITI 2012] é a cadeia hierárquica e de confiança que viabiliza a emissão de certificados digitais para identificação virtual do cidadão brasileiro. Por força da Medida Provisória n.o2.200- 2/2001 (que instituiu a ICP-Brasil), documentos assinados digitalmente com certificados ICP-Brasil tem validade jurídica.
Sendo assim, a utilização de um mecanismo de autenticação baseado em certificados digitais A3 (certificados ICP-Brasil com par de chaves gerado e armazenado em mídia criptográfica, i.e., smart-cards ou tokens USB) provê segurança técnica e jurídica. Pelos motivos citados, este é o sistema de validação de credenciais escolhido para o presente trabalho, sendo o principal diferencial em relação às soluções de identificação federadas existentes.
Salienta-se que essa escolha vislumbra também uma tendência dentro do Governo Fe- deral da adoção massiva dos certificados digitais fornecidos pela Autoridade Certificadora Brasileira como mecanismo oficial de fé pública em documentos. Prova disso é a substi- tuição da atual carteira de identidade pelo Registro de Identidade Civil - RIC (figura 3.1), definido por um smartcard contendo um certificado digital emitido pelo ICP-Brasil em nome do titular.
30 CAPÍTULO 3. MODELAGEM DO AUTENTICADOR ICP/SAML
Figura 3.1: O novo Registro de Identidade Civil.
Nos próximos anos, todo cidadão portará um RIC em substituição ao atual RG. A ferramenta proposta neste trabalho permitirá, assim, a identificação federada segura, efi- caz e juridicamente válida do usuário na Internet, através de um objeto portado por este naturalmente (autenticação por “algo que você possua”).
Com relação ao protocolo de identidade federada, a escolha recai sobre o SAML, por ser um protocolo aberto e de grande utilização no meio acadêmico e corporativo. Além disso, é o protocolo de federação oficialmente adotado pelo Governo Federal nos Padrões de Interoperabilidade de Governo Eletrônico - e-PING [Correia et al. 2011].
Define-se, portanto, a proposta deste trabalho: o desenvolvimento de um mecanismo de identificação federada baseado em certificados digitais padrão A3/ICP-Brasil armaze- nados em smart-cards, e no protocolo SAML.