Estudo de Caso de uma Estrutura de Autenticação Única utilizando o protocolo OAuth
Upcoming SlideShare
Loading in...5
×
 

Estudo de Caso de uma Estrutura de Autenticação Única utilizando o protocolo OAuth

on

  • 13,692 views

This monograph, developed in my post-graduation course in Universidade Tecnológica Federal do Paraná (UTFPR), proposes an OAuth provider used as a single-sign-on server, showing two clients that ...

This monograph, developed in my post-graduation course in Universidade Tecnológica Federal do Paraná (UTFPR), proposes an OAuth provider used as a single-sign-on server, showing two clients that consumes the provider developed. The full code can be found in: https://github.com/fernandomantoan

Statistics

Views

Total Views
13,692
Views on SlideShare
3,135
Embed Views
10,557

Actions

Likes
3
Downloads
158
Comments
0

4 Embeds 10,557

http://fernandomantoan.com 10512
http://feeds.feedburner.com 41
http://translate.googleusercontent.com 3
http://www.simplefinance.com.br 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Estudo de Caso de uma Estrutura de Autenticação Única utilizando o protocolo OAuth Estudo de Caso de uma Estrutura de Autenticação Única utilizando o protocolo OAuth Document Transcript

  • UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ PROGRAMA DE PÓS-GRADUAÇÃO EM TECNOLOGIA ESPECIALIZAÇÃO EM DESENVOLVIMENTO DE SISTEMAS BASEADOS EM OBJETOS PARA AMBIENTE INTERNET FERNANDO GERALDO MANTOANESTUDO DE CASO DE UMA ESTRUTURA DE AUTENTICAÇÃO ÚNICA UTILIZANDO O PROTOCOLO OAUTH MONOGRAFIA DE ESPECIALIZAÇÃO MEDIANEIRA 2011
  • FERNANDO GERALDO MANTOANESTUDO DE CASO DE UMA ESTRUTURA DE AUTENTICAÇÃO ÚNICA UTILIZANDO O PROTOCOLO OAUTH Trabalho de Conclusão de Curso apresentado à Universidade Tecnológica Federal do Paraná – Câmpus Medianeira como requisito parcial à obtenção do grau de Especialista em Projeto e Desenvolvimento de Sistemas Baseados em Objetos para Ambiente Internet. Orientador: Prof. Esp. Diego de Carvalho MEDIANEIRA 2011
  • Ministério da Educação Universidade Tecnológica Federal do Paraná Diretoria de Pesquisa e Pós-Graduação Especialização em Projeto e Desenvolvimento de Sistemas baseados em Objetos para Ambiente Internet TERMO DE APROVAÇÃOEstudo de Caso de uma Estrutura de Autenticação Única utilizando o protocolo OAuth Por Fernando Geraldo Mantoan Esta monografia foi apresentada às 11:00h do dia 08 de dezembro de 2011como requisito parcial para a obtenção do título de ESPECIALISTA, no curso deEspecialização em Projeto e Desenvolvimento de Sistemas baseados em Objetospara Ambiente Internet, da Universidade Tecnológica Federal do Paraná, CâmpusMedianeira. O acadêmico foi arguido pela Banca Examinadora composta pelosprofessores abaixo assinados. Após deliberação, a Banca Examinadora considerouo trabalho aprovado. Prof. Esp. Diego de Carvalho Prof. Me. Alan Gavioli Orientador Convidado UTFPR – Câmpus Pato Branco UTFPR – Câmpus Medianeira Prof. Dr. Hermes Irineu Del Monego Prof. Me. Fernando Schütz Convidado Coordenador do Curso de Especialização UTFPR – Câmpus Medianeira UTFPR – Câmpus Medianeira UTFPR – DIRPPG Av. Brasil, 4232 – Pq Independência 85884000 – Medianeira – PR www.utfpr.edu.br/medianeira +55(45) 3240-8074A FOLHA DE APROVAÇÃO ASSINADA ENCONTRA-SE NA DIRETORIA DE PÓS-GRADUAÇÃO DA UTFPRCÂMPUS MEDIANEIRA
  • AGRADECIMENTOS Primeiramente a Deus, por sempre me iluminar e ser o meu apoio nas horas maisdifíceis. À minha namorada Aline Regina Marzurkiewicz e aos meus pais, pelo incentivo,pelo apoio, pelo amor e carinho, pela compreensão, por sempre me cobrarem e pela forçaque sempre me deram. Ao meu orientador, professor Diego de Carvalho, por toda assistência, pelo apoio,pelas idéias, pela paciência, e por sempre me ajudar, mesmo não estando presentefisicamente. Agradeço aos meus amigos e colegas, pelos momentos de discussão, estudo ediversão.
  • “A coisa mais bonita que podemos experimentar é omistério. Ele é a fonte de toda a verdadeira arte eciência.”Albert Einstein
  • RESUMOMANTOAN, Fernando Geraldo. Estudo de caso de uma estrutura de autenticação únicautilizando o protocolo OAuth. 56 f. Monografia (Especialização em Projeto eDesenvolvimento de Sistemas Baseados em Objetos para Ambiente Internet) – Programade Pós-graduação em Tecnologia, Universidade Tecnológica Federal do Paraná.Medianeira, 2011.O presente trabalho tem como principal objetivo apresentar um estudo de caso de umaestrutura de autenticação única utilizando o protocolo OAuth. Com este protocolo omodelo tradicional de autenticação cliente-servidor ganha um terceiro papel que é o deproprietário do recurso, um usuário com credenciais válidas no provedor OAuthresponsável por permitir ou negar acesso de consumidores aos seus dados pessoais.Também é feito um estudo sobre conceitos de segurança, apresentação das tecnologiasutilizadas no estudo de caso, e toda a parte de implementação, composta por umprovedor OAuth e duas aplicações consumidoras, utilizada para verificar asfuncionalidades do OAuth.Palavras-chave: Segurança, Spring Framework, Java, Play Framework, PHP, ZendFramework.
  • ABSTRACTMANTOAN, Fernando Geraldo. Case study of a structure of single sign on with the OAuthprotocol. 56 f. Monografia (Especialização em Projeto e Desenvolvimento de SistemasBaseados em Objetos para Ambiente Internet) – Programa de Pós-graduação emTecnologia, Universidade Tecnológica Federal do Paraná. Medianeira, 2011.This assignment has the main goal of presenting a case study of an structure of singlesign on with the OAuth protocol. With OAuth the traditional client-server authenticationmodel gains a third role, which is the role of the resource owner, an user with validcredentials in the OAuth provider responsible of allowing or revoking consumers access toits personal data. It also makes a study about the main security concepts, an overview ofthe technologies used in the case study, and all the information about the implementation,which is composed by a provider application and two consumer applications, used tocheck the OAuth functionalitys.Keywords: Security, Spring Framework, Java, Play Framework, PHP, Zend Framework.
  • LISTA DE FIGURASFIGURA 1: TELA DE AUTORIZAÇÃO DO TWITTER.........................................................34FIGURA 2: TELA DE AUTORIZAÇÃO DO YAHOO!............................................................35FIGURA 3: ARQUITETURA DEFINIDA...............................................................................44FIGURA 4: TELA DE AUTENTICAÇÃO...............................................................................49FIGURA 5: TELA DE AUTORIZAÇÃO.................................................................................52FIGURA 6: TELA DE ACESSO REVOGADO......................................................................52FIGURA 7: TELA INICIAL DA APLICAÇÃO DE CONTATOS..............................................55FIGURA 8: TELA PARA ADICIONAR UM CONTATO..........................................................55FIGURA 9: TELA INICIAL DA APLICAÇÃO DE FINANÇAS................................................59FIGURA 10: TELA PARA ADICIONAR UM LANÇAMENTO................................................59
  • LISTA DE SIGLASAPI Application Programming InterfaceAOP Aspect Oriented ProgrammingCAS Central Authentication ServiceCSS Cascading Style SheetsHTML HyperText Markup LanguageHTTP HyperText Transfer ProtocolHTTPS HyperText Transfer Protocol SecureIoC Inversion of ControlJ2EE Java 2 Platform Enterprise EditionJ2ME Java 2 Platform Micro EditionJ2SE Java 2 Platform Standard EditionJPA Java Persistence APIJVM Java Virtual MachineMVC Model View ControllerOAUTH Open AuthenticationORM Object Relational MapperPHP Hypertext PreprocessorREST Representational State TransferRMI Remote Method InvocationSQL Structured Query LanguageSSL Secure Sockets LayerURI Unified Resource IdentifierURL Uniform Resource LocatorW3C World Wide Web ConsortiumWWW World Wide WebXML Extensible Markup Language
  • SUMÁRIO1 INTRODUÇÃO..................................................................................................................121.1 JUSTIFICATIVA..............................................................................................................121.2 OBJETIVOS...................................................................................................................131.2.1 Objetivo Geral.............................................................................................................131.2.2 Objetivos Específicos..................................................................................................132 FUNDAMENTAÇÃO TEÓRICA........................................................................................142.1 SEGURANÇA................................................................................................................142.2 AUTENTICAÇÃO...........................................................................................................152.3 AUTORIZAÇÃO.............................................................................................................152.4 CLOUD COMPUTING...................................................................................................162.5 HTTP..............................................................................................................................162.5.1 URIs............................................................................................................................172.5.2 URLs...........................................................................................................................172.5.3 Transações..................................................................................................................182.5.4 Métodos......................................................................................................................182.5.5 Códigos de Estado......................................................................................................192.5.6 Mensagens..................................................................................................................192.6 OPENID.........................................................................................................................202.6.1 Fluxo de Autenticação.................................................................................................212.7 CAS................................................................................................................................212.7.1 Fluxo de Autenticação.................................................................................................222.8 OAUTH...........................................................................................................................232.8.1 Terminologia................................................................................................................232.8.2 Benefícios...................................................................................................................242.8.3 Funcionamento...........................................................................................................252.8.4 Credenciais Temporárias............................................................................................262.8.5 Autorização do proprietário do recurso.......................................................................272.8.6 Credenciais de Token.................................................................................................292.8.7 Requisições Autenticadas...........................................................................................302.8.8 Experiência do Usuário...............................................................................................333 PROCEDIMENTOS METODOLÓGICOS.........................................................................363.1 PROCEDIMENTOS DE PESQUISA..............................................................................363.1.1 Tipo de Pesquisa........................................................................................................363.2 ESTRUTURA FÍSICA.....................................................................................................363.3 TECNOLOGIAS.............................................................................................................373.3.1 Java.............................................................................................................................373.3.2 Spring MVC e Spring Security....................................................................................383.3.3 Hibernate.....................................................................................................................383.3.4 PHP.............................................................................................................................393.3.5 Zend Framework.........................................................................................................393.3.6 Play Framework..........................................................................................................403.3.7 HTML 5 e CSS3..........................................................................................................403.3.8 MySQL........................................................................................................................413.4 JUSTIFICATIVAS TECNOLÓGICAS.............................................................................414 IMPLEMENTAÇÃO...........................................................................................................434.1 SERVIDOR DE AUTENTICAÇÃO.................................................................................434.1.1 Configuração do Spring Security e OAuth..................................................................444.1.2 Autenticação de Usuários...........................................................................................474.1.3 Confirmação do Proprietário do Recurso...................................................................49
  • 4.2 APLICAÇÃO 1: AGENDA DE CONTATOS....................................................................524.3 APLICAÇÃO 2: CONTROLE DE FINANÇAS................................................................565 CONSIDERAÇÕES FINAIS.............................................................................................605.1 TRABALHOS FUTUROS...............................................................................................60REFERÊNCIAS...................................................................................................................62
  • 121 INTRODUÇÃO Aplicações no geral possuem a necessidade comum de restringir o acessoaos seus recursos utilizando meios de segurança como, por exemplo, autenticaçãode usuários. Comumente, cada aplicação fornece uma fonte de dados paraarmazenar informações de usuários do software e, utilizando estas fontes de dados,fornece restrição baseada em credenciais de acesso (usuário e senha por exemplo). No modelo tradicional de autenticação cliente-servidor, o cliente usa suascredenciais para acessar os recursos hospedados pelo servidor. Com o advento douso de web services distribuídos e de cloud computing, aplicações de terceirosprecisam acessar estes recursos hospedados pelo servidor. (OAUTH, 2010) O protocolo OAuth introduz um terceiro papel no modelo tradicional deautenticação cliente-servidor: o resource owner (proprietário do recurso). No modeloOAuth, o cliente (que não é o proprietário do recurso, mas está atuando como um)requisita acesso a recursos controlados pelo proprietário, mas hospedados noservidor. Além disso, o OAuth permite que o servidor verifique não apenas aautorização do proprietário do recurso, mas também a identidade do cliente que estáfazendo a requisição. (OAUTH, 2010) A proposta deste trabalho é fazer um estudo sobre o protocolo OAuth,destacando os princípios pelos quais ele foi elaborado, seu funcionamento,utilização no mercado e aspectos principais. Será implementada uma estruturabásica de autenticação única, com a definição de uma arquitetura para a parte deautenticação utilizando o protocolo OAuth, e duas mini-aplicações, que utilizam aestrutura de autenticação desenvolvida, permitindo ou negando acesso aos recursosdisponibilizados, de acordo com cada uma das aplicações.1.1 JUSTIFICATIVA Com o advento do uso de web services distribuídos e de cloud computing,aplicações de terceiro precisam acessar estes recursos hospedados pelo servidor,fugindo do modelo tradicional de autenticação entre cliente e servidor. (OAUTH,2010)
  • 13 O protocolo OAuth fornece um método para que clientes acessem recursosdo servidor em nome de um proprietário do recurso. Com ele também é possívelfornecer um processo para usuários finais autorizarem acesso de terceiros aosrecursos de seus servidores sem compartilhar suas credenciais (como o conjuntousuário/senha), usando redirecionamento de seus agentes de usuários. (OAUTH,2010)1.2 OBJETIVOS1.2.1 Objetivo Geral Propor uma estrutura para fornecer autenticação única com o protocoloOAuth na plataforma Java, e implementar duas mini-aplicações que utilizem estaestrutura de autenticação, sendo elas de plataformas de programação diferentes.1.2.2 Objetivos Específicos • Explicar os conceitos de segurança; • Explanar o protocolo OAuth, seguindo sua especificação e apresentar sua utilização no mercado; • Apresentar as tecnologias utilizadas no desenvolvimento das aplicações; • Implementar uma aplicação que forneça autenticação única utilizando o protocolo OAuth; • Realizar um estudo de caso, elaborando duas aplicações que se autenticam utilizando a estrutura OAuth implementada.
  • 142 FUNDAMENTAÇÃO TEÓRICA Neste capítulo é apresentada toda a fundamentação teórica levantadadurante a análise bibliográfica dos principais conceitos necessários para o estudodeste trabalho. Serão abordados os principais aspectos sobre segurança,autorização, autenticação, cloud computing, o protocolo HTTP, alguns protocolos deautenticação similares ao OAuth (OpenID e CAS) e os principais conceitosfornecidos pela especificação do protocolo OAuth.2.1 SEGURANÇA Segurança é sem dúvida um dos componentes arquiteturais mais críticos dequalquer aplicação baseada na web escrita no século vinte e um. Em uma era ondemalwares, crimonosos, e funcionários mal intencionados estão sempre presentes eativamente testando falhas de software, o uso inteligente e abrangente de segurançaé um elemento chave para novos projetos a serem desenvolvidos. (MULARIEN,2010) O objetivo da segurança consiste em garantir um conjunto de três atributos:confidencialidade, integridade e disponibilidade. A confidencialidade é a ausênciade divulgação não autorizada de conteúdo. A integridade é a ausência dealterações não autorizadas ao sistema ou à informação. A disponibilidade é aprontidão do serviço fornecido ou da informação. Além das três, é comumenteadicionada a autenticidade, que é a medida em que a informação ou o serviçofornecido são genuínos. (CORREIA; SOUSA, 2010) Um dos principais conceitos na segurança de software é o devulnerabilidades, que é um defeito relevante no sistema que pode ser explorado porum atacante com o objetivo de subverter sua política de segurança. Existem trêstipos de vulnerabilidades, podendo ser uma vulnerabilidade de projeto, que éintroduzida durante o projeto do sistema; vulnerabilidade de codificação que éintroduzida durante a codificação e resulta em bugs de segurança; e avulnerabilidade operacional, causada pelo ambiente onde o sistema é executadoou por sua configuração. (CORREIA; SOUSA, 2010)
  • 152.2 AUTENTICAÇÃO Autenticação é um dos dois conceitos chave que deve ser implementado aose desenvolver aplicações seguras. A autenticação lida com a identificaçãoespecífica de um usuário do sistema, e com o mapeamento deste usuário para umaentidade identificável (e, portanto, protegida). Tipicamente, um software está divididoem dois domínios de alto nível como anônimo e autenticado. (MULARIEN, 2010) As funcionalidades da aplicação para o domínio anônimo são independentesde uma identificação de usuário, como por exemplo, uma listagem de produtos emum site de comércio eletrônico. As seções que permitem acesso anônimo nãorequerem a autenticação do usuário para sua utilização, não exibem informaçõesconfidenciais como nomes e cartões de créditos, e não fornecem meios paramanipulação geral do sistema ou de seus dados. (MULARIEN, 2010)2.3 AUTORIZAÇÃO Autorização é o segundo dos dois principais conceitos de segurança cruciaisna implementação e compreensão de segurança de aplicações. Autorização lidacom a disponibilidade adequada de funcionalidades e dados para usuários queestão autorizados para acessá-los. Construído em torno do modelo de autorizaçãopara a aplicação está a atividade de particionar as funcionalidades e os dados daaplicação de tal forma que a disponibilidade destes itens possam ser controlados poruma combinação de privilégios, funcionalidades e dados, e usuários. (MULARIEN,2010) O processo de autorização tipicamente envolve dois aspectos separadosque se combinam para descrever a acessibilidade do sistema seguro. O primeiro é omapeamento de um usuário autenticado para um ou mais papéis, por exemplo opapel de administrador do sistema ou o papel de visitante. O segundo aspecto é aatribuição das checagens de autoridade para os recursos protegidos do sistema, oque tipicamente é feito durante o desenvolvimento do sistema, através dedeclaração explícita no código ou por meios de configuração. Um recurso protegidopode ser uma funcionalidade do sistema, como, por exemplo, gerenciamento deprodutos. (MULARIEN, 2010)
  • 162.4 CLOUD COMPUTING Cloud Computing (computação na nuvem) é um fenômeno recente queimpacta na forma com que infra-estruturas são arquitetadas, compradas eimplantadas. No modelo de computação na nuvem, computação e infra-estruturasde armazenamento estão disponíveis para uso como um utilitário e não apenasdentro de uma infra-estrutura própria. O modelo de utilitário estende-se a partir deapenas um hardware de computador de plataforma de serviços para aplicativoscompletos como um serviço externo. (SANKAR; BOUCHARD, 2009) Computação na nuvem é uma otimização tática assim como um artefatoarquitetural estratégico. É uma otimização tática, porque ao se ter aplicações ad-hocque precisam funcionar em um curto período de tempo (como uma enquete oualguma pesquisa) é possível executá-la em uma infra-estrutura de nuvem, como, porexemplo, o Amazon Elastic Compute Cloud. Mas também é estratégica porqueagora os acionistas de empresa (e envolvidos em TI) podem trabalhar além daslimitações de largura de banda finita de computação e otimizar os sistemas ativos auma era de poder de processamento infinito, que é flexível. (SANKAR; BOUCHARD,2009) Uma nuvem é um conjunto de soluções escaláveis, com infra-estruturaabstrata que hospeda aplicações de uso final, cobrado pelo consumo. Em suma,uma nuvem é um conjunto grande de infra-estrutura de servidores, rede earmazenamento, hospedado em algum lugar para ser alugado ou usado conforme anecessidade. Ele pode ser interno a uma empresa (chamado de nuvem “privada”) ouhospedado na internet como uma nuvem “pública”. A decisão de se utilizar a nuvemprivada ou pública para um aplicativo é determinada por políticas, conformidade eregulamentos relevantes para uma organização, bem como as condições devisibilidade e controle de uma empresa comparado com os recursos fornecidos porum provedor de nuvem público. (SANKAR; BOUCHARD, 2009)2.5 HTTP Todos os navegadores de internet, servidores, e aplicações webrelacionadas se comunicam entre si através do Hypertext Transfer Protocol (HTTP),
  • 17que é uma linguagem comum da Internet mundial moderna. (GOURLEY; TOTTY,2002) O conteúdo da web reside em servidores web, que falam o protocolo HTTP,dessa forma sendo comumente chamados de servidores HTTP. Estes servidoresfornecem os dados quando são requisitados pelos clientes HTTP, que enviampedidos HTTP para servidores e recebem os dados pedidos em respostas HTTP. Oconjunto de clientes e servidores HTTP fazem os componentes básicos da WorldWide Web (WWW). (GOURLEY; TOTTY, 2002) O protocolo HTTP possui diversos blocos necessários para seu corretofuncionamento, cada um com uma finalidade distinta para compor este protocoloque, segundo Gourley e Totty (2002) é o mais utilizado pela internet atual. Dentreestes blocos encontram-se nomes de recursos (URIs), identificadores de recursos(URLs), transações, métodos, códigos de estado e mensagens.2.5.1 URIs Cada recurso de um servidor web tem um nome, assim clientes podemapontar quais recursos eles estão interessados em acessar. O nome do recurso deservidor é chamado de Unified Resource Identifier (URI), em português IdentificadorÚnico de Recurso. URIs são como os endereços postais da Internet, identificandoexclusivamente e localizando informação de recursos em todo o mundo. Umexemplo de URI de uma imagem em um servidor web é apresentado no Quadro 1.(GOURLEY; TOTTY, 2002)http://www.site.com/imagens/imagem.gifQuadro 1: Exemplo de URI2.5.2 URLs O Uniform Resource Locator (URL) é a forma mais comum de umidentificador de recurso. URLs descrevem a localização específica de um recursoem um servidor particular. Elas descrevem exatamente como obter um recurso deuma localização precisa e fixa. (GOURLEY; TOTTY, 2002) De acordo com Gourley e Totty (2002) muitas URLs seguem um formato
  • 18padronizado de três partes principais: • A primeira parte da URL é chamada de esquema, e ela descreve o protocolo utilizado para acessar o recurso, comumente o protocolo é o HTTP (http://); • A segunda parte fornece o endereço do servidor de Internet (por exemplo, www.site.com); • O resto da URL nomeia um recurso de um servidor web (por exemplo, /imagens/imagem.gif). Atualmente, quase toda URI é uma URL. (GOURLEY; TOTTY, 2002)2.5.3 Transações Uma transação HTTP consiste em um comando de pedido (enviado docliente ao servidor), e um resultado de resposta (enviado de volta ao cliente). Estacomunicação acontece com blocos formatados de dados chamados de mensagensHTTP. (GOURLEY; TOTTY, 2002)2.5.4 Métodos O protocolo HTTP suporta diferentes comandos de pedido, chamados demétodos HTTP. Cada mensagem de pedido HTTP possui um método, que diz aoservidor qual ação deve ser executada (obter uma página, executar um programa,excluir um arquivo, etc). O Quadro 2 lista os cinco métodos HTTP comuns.(GOURLEY; TOTTY, 2002) Método DescriçãoGET Envia um recurso nomeado do servidor ao cliente.PUT Armazena dados de um cliente em um recurso nomeado do servidor.DELETE Exclui o recurso nomeado de um servidor.POST Envia dados do cliente a uma aplicação servidora de gateway.HEAD Envia apenas os cabeçalhos HTTP da resposta para o recurso nomeado.Quadro 2: Métodos HTTPFonte: Gourley e Totty (2002)
  • 192.5.5 Códigos de Estado Cada mensagem de resposta HTTP retorna com um código de estado. Ocódigo de estado é um número de três dígitos que diz ao cliente se o pedido foiexecutado com sucesso, ou se outras ações são necessárias. O HTTP tambémenvia uma explicação textual com cada código numérico, que é inclusa apenas parafins descritivos; e o código numérico é utilizado para todo o processamento. Algunscódigos de estado comuns são apresentados no Quadro 3. (GOURLEY; TOTTY,2002) Código de Estado Descrição200 OK. Documento retornado com sucesso.302 Redirect. Redireciona o usuário para outro lugar para obter o recurso.404 Not Found. Não foi possível encontrar este recurso.Quadro 3: Códigos de EstadoFonte: Gourley e Totty (2002)2.5.6 Mensagens Mensagens HTTP são simples sequências de caracteres orientadas porlinha. Devido ao fato de serem texto simples, não binários, eles são fáceis paraseres humanos lerem e escreverem. Mensagens HTTP enviadas de clientes webaos servidores são denominados mensagens de pedido. Mensagens de servidores aclientes são chamados de mensagens de resposta. Não existem outros tipos demensagens HTTP e o formato de ambas as mensagens é similar. (GOURLEY;TOTTY, 2002) Segundo Gourley e Totty (2002) as mensagens HTTP consistem de trêspartes: Linha de início: A primeira linha da mensagem é a linha de início, indicandoo que fazer para um pedido e o que aconteceu para um recurso; Campos de cabeçalho: Nenhum ou muitos campos de cabeçalho seguem alinha de início. Cada campo de cabeçalho consiste de um nome e um valor,separados pelo caractere dois pontos (:) para facilitar a leitura. Os cabeçalhosterminam com uma linha em branco; Corpo: Após a linha branca existe um corpo de mensagem opcional
  • 20contendo qualquer tipo de dado. Corpos de pedido carregam dados para o servidorweb; corpos de resposta carregam dados para o cliente. Diferentemente da linha deinício e dos cabeçalhos, que são textuais e estruturados, o corpo pode conter dadosbinários arbitrários (por exemplo, imagens, vídeos etc.), assim como podem contertexto simples.2.6 OPENID OpenID fornece sites e serviços com um protocolo descentralizado deautenticação de usuários através de uma ampla variedade de provedores. Issosignifica que um site integrando OpenID pode permitir que seus usuários seautentiquem utilizando, por exemplo, suas contas do Yahoo!, Google ou AOL. O siteem questão pode não apenas evitar a criação de seu próprio sistema deautenticação, mas também pode tirar vantagem das contas que seus usuários jápossuem, aumentando assim o registro de usuários e as taxas de autenticação.(LEBLANC, 2011) Além da autenticação simples, o OpenID também oferece diversasextensões através do qual um provedor de OpenID pode permitir que as aplicaçõesobtenham informações do perfil de um usuário ou integrar camadas adicionais desegurança para o procedimento de autenticação. (LEBLANC, 2011) O fator mais interessante do OpenID é o de que ele oferece um padrão queé totalmente descentralizado dos provedores e dos consumidores. Este aspecto é oque dá a um site consumidor simples a possibilidade de autenticação a partir decontas do Yahoo! e Google, enquanto outro site pode querer que seus usuários seautentiquem através do Blogger ou Wordpress. Cabe ao consumidor OpenID (umsite ou serviço) escolher quais métodos de autenticação ele gostaria de oferecer aosseus usuários. (LEBLANC, 2011) Cada provedor de OpenID possui um endereço de OpenID associado comseu sistema de autenticação para habilitar o método de descoberta requirido para oprocesso de autenticação. Existem diversos provedores de OpenID, entre osprincipais estão o Google, Yahoo!, Flickr, Wordpress, AOL, Blogger, MySpace,MyOpenID entre outros. (LEBLANC, 2011)
  • 212.6.1 Fluxo de Autenticação Segundo Leblanc (2011) o OpenID define um fluxo padronizado pelo qualum usuário pode se autenticar em um site de terceiro de retransmissão de umprovedor de OpenID como Yahoo! ou Google. Existem três participantes no fluxo deautenticação do OpenID: • O usuário: Usuário final que está tentando se autenticar em um site ou serviço utilizando um dos provedores de OpenID; • Partido confiável: Site consumidor de OpenID, que implementa um processo de autenticação de um provedor de OpenID, para permitir aos usuários a autenticação com suas contas; • O provedor de OpenID: Site ou serviço que possui o banco de dados de membros que o partido confiável se autenticará e através do qual o usuário irá fornecer seus dados de acesso. O processo de autenticação do OpenID necessita de quatro passosdiferentes, iniciando quando o usuário escolhe um provedor para se autenticar eterminando com o resultado de sucesso/falha do provedor quando o usuário tenta seautenticar. No primeiro passo é solicitada a autenticação do usuário, passando umaURI identificadora de OpenID. No segundo passo é feita a descoberta do endpointdo OpenID. No terceiro passo é solicitado ao usuário que o mesmo se autentiquecom sua conta. E finalmente, no quarto passo, é fornecido um estado desucesso/falha baseado na autenticação. (LEBLANC, 2011)2.7 CAS Central Authentication Service (CAS) é um portal de autenticação única decódigo aberto, que fornece controle de acesso centralizado, e autenticação pararecursos baseados na web dentro de uma organização. Mularien (2010) destaca queos principais benefícios do CAS são: • O acesso individual ou em grupo a recursos (aplicações) pode ser configurado em um único local; • Suporte a uma ampla variedade de locais de autenticação (para centralizar a gestão de usuários), fornecendo um ponto único de autenticação e
  • 22 controle para um amplo ambiente multi-máquina; • O suporte amplo de autenticação é fornecido por aplicações Java baseadas ou não baseadas na web através de bibliotecas de clientes CAS; • Um único ponto de referência para credenciais de usuário (através de CAS), para que aplicações clientes CAS não necessitam saber nada sobre as credenciais do usuário, ou como verificar elas.2.7.1 Fluxo de Autenticação Segundo Mularien (2010), o fluxo básico de autenticação do CAS éexecutado através das seguintes ações: • Primeiramente o usuário tenta acessar um recurso protegido de uma aplicação; • O usuário é redirecionado para o portal CAS através do mecanismo de segurança da aplicação, para fornecer suas credenciais; • O portal CAS é responsável pela autenticação do usuário. Se o usuário for autenticado com sucesso no CAS, ele é redirecionado para o recurso protegido com um ticket CAS único definido na requisição; • O mecanismo de segurança da aplicação chama novamente o servidor CAS para validar se o ticket é aceitável (é válido, não está expirado, etc). O servidor CAS responde com uma afirmação indicando que a confiança foi estabelecida. Caso o ticket seja aceitável, a confiança foi estabelecida e o usuário pode proceder através de checagem de autorização comum. Com este fluxo é possível visualizar que existe uma grande interação entre oservidor CAS e a aplicação segurada, com a necessidade de bastante troca dedados antes que a confiança do usuário possa ser estabelecida. O resultado destacomplexidade é um protocolo de autenticação única que é difícil para falsificaratravés de técnicas comuns (assumindo que outras precauções de segurança foramtomadas, como o uso de Secure Sockets Layer e monitoração de rede).(MULARIEN, 2010)
  • 232.8 OAUTH Open Authentication (OAuth), é um padrão aberto para autorização deaplicações para acessar dados em nome de um usuário. Através do OAuth, épossível proteger informações pessoais de um usuário. O protocolo OAuth éutilizado por diversas grandes empresas famosas da Internet, como, por exemplo,Yahoo!, Google, FourSquare e Twitter. (LEBLANC, 2011) O protocolo OAuth foi criado originalmente por uma comunidade pequena dedesenvolvedores web de diversos websites, que queriam resolver o problemacomum de permitir a delegação de acesso a recursos protegidos. O protocolo OAuthresultante foi estabilizado na versão 1.0 em Outubro de 2007, e revisado em Junhode 2009 (Revisão A), conforme publicado online. (OAUTH, 2010) O protocolo OAuth fornece um método para que clientes acessem recursosdo servidor em nome de um resource owner (dono de recursos). Também é possívelfornecer um processo para usuários finais autorizarem acesso de terceiros aosrecursos de seus servidores sem compartilhar suas credenciais (como, por exemplo,usuário/senha), usando redirecionamento de seus agentes de usuários. (OAUTH,2010) Para que o cliente acesse recursos do servidor, ele primeiramente precisaobter permissão do dono de recursos. Essa permissão é expressada na forma deum token e de uma chave secreta correspondente. O objetivo do token é fazer comque não haja necessidade do dono de recursos compartilhar suas credenciais com osistema. Diferentemente das credenciais do dono de recursos, tokens podem seremitidas com um escopo restrito e um tempo de vida limitado, e podem serrevogados independentemente. (OAUTH, 2010)2.8.1 Terminologia O protocolo OAuth apresenta diversos conceitos com um significadoparticular para seu contexto, conforme apresentado abaixo: Cliente: Um cliente HTTP capaz de fazer requisições OAuth autenticadas.(OAUTH, 2010) Servidor: Um servidor HTTP capaz de aceitar requisições OAuth
  • 24autenticadas. (OAUTH, 2010) Recurso protegido: Um recurso de acesso restrito que pode ser obtido deum servidor utilizando uma requisição OAuth autenticada. (OAUTH, 2010) Proprietário do recurso: Uma entidade capaz de acessar e controlarrecursos protegidos utilizando credenciais para se autenticar no servidor. (OAUTH,2010) Credenciais: Credenciais são um par composto de um identificador único eum segredo correspondente compartilhado. O OAuth define três classes decredenciais: cliente, temporário e token, usados, respectivamente, para identificar eautenticar o cliente que está fazendo a requisição, a requisição de autorização, e aconcessão do acesso. (OAUTH, 2010) Token: Um identificador único emitido pelo servidor e usado pelo clientepara associar requisições autenticadas com o proprietário do recurso cujaautorização é solicitada ou tenha sido obtida pelo cliente. Tokens possuem umachave secreta compartilhada correspondente que é utilizada pelo cliente paraestabelecer a sua posse do token, e sua autoridade para representar o proprietáriodo recurso. (OAUTH, 2010)2.8.2 Benefícios Segundo Leblanc (2011, p. 319) o protocolo OAuth oferece algumasmelhorias sobre os modelos tradicionais de autenticação, incluindo: • Ao invés de ter que enviar o nome de usuário e senha ao servidor com cada requisição de autenticação, é possível trabalhar com tokens de acesso abstratos que não compartilham nenhuma das senhas do usuário; • Como tokens são emitidos a partir de um servidor, eles podem ser revogados a qualquer momento, colocando mais controle nas mãos do usuário. Diversos provedores também implementam um mecanismo de expiração de tokens, que requerem que uma aplicação periodicamente renove o token de acesso para continuar executando requisições de dados dos usuários; • Usuários podem ver os tokens que eles possuem ativos (isto é, quais
  • 25 aplicações podem acessar seus dados) no site do provedor, significando que eles podem manualmente revogar o acesso de uma aplicação. Já que a aplicação não possui as credenciais de autenticação do usuário, ela não pode fazer mais requisições de dados uma vez que o usuário revogue a autorização da aplicação.2.8.3 Funcionamento O OAuth utiliza tokens para representar a autorização garantida ao clientepelo proprietário de recurso. Tipicamente, credenciais de token são emitidos peloservidor na requisição do proprietário de recurso, após a autenticação da identidadedo proprietário de recurso (comumente utilizando um nome de usuário e senha).(OAUTH, 2010) Segundo OAuth (2010, p. 8) existem diversas maneiras de um servidorprover as credenciais de token. Uma delas é utilizando a redirecionamentos HTTPno agente de usuário do proprietário de recurso. Este redirecionamento inclui trêsetapas: 1. O cliente obtém um conjunto de credenciais temporárias do servidor (na forma de um identificador e uma chave secreta compartilhada). As credenciais temporárias são utilizadas para identificar o pedido de acesso em todo o processo de autorização; 2. O proprietário de recurso autoriza o pedido de acesso do cliente no servidor (identificado pelas credenciais temporárias); 3. O cliente utiliza as credenciais temporárias para requisitar um conjunto de credenciais de token do servidor, que lhe permitirá acessar recursos protegidos do proprietário de recurso. O servidor deve revogar as credenciais temporárias após elas seremutilizadas para obter as credenciais de token. É recomendado que as credenciaistemporárias tenham um tempo de vida limitado. Servidores devem permitir que osproprietários de recursos possam revogar as credenciais de token após elas serememitidas aos clientes. (OAUTH, 2010) De acordo com OAuth (2010, p. 8), para permitir que o cliente execute astrês etapas, o servidor deve anunciar os endereços dos seguintes endpoints:
  • 26 Pedido de Credencial Temporária: O endpoint utilizado pelo cliente paraobter um conjunto de credenciais temporárias. Autorização do Proprietário do Recurso: Endpoint onde o proprietário dorecurso é redirecionado para garantir a autorização. Pedido de Token: O endpoint utilizado pelo cliente para requisitar umconjunto de credenciais de token utilizando as credenciais temporárias.2.8.4 Credenciais Temporárias O cliente obtém um conjunto de credenciais temporárias do servidor fazendopedido HTTP “POST” autenticado para o endpoint de Pedido de CredencialTemporário. O cliente constrói uma URI de pedido adicionando o parâmetroobrigatório “oauth_callback”, que define um endereço para o qual o servidorredirecionará o proprietário de recurso após o processo de autorização doproprietário do recurso estar completo. (OAUTH, 2010) Ao fazer o pedido, o cliente se autentica utilizando apenas suas credenciais.O cliente pode omitir o parâmetro vazio de protocolo “oauth_token” da requisição edeve utilizar a string vazia como o valor secreto do token. (OAUTH, 2010) Uma vez que o pedido resulta na transmissão de texto simples, o servidordeve exigir o uso de um mecanismo de camada de transporte como o SecureSockets Layer (SSL) (ou um canal seguro com proteções equivalentes). (OAUTH,2010) O servidor deve verificar o pedido e se for válido, responder ao cliente comum conjunto de credenciais temporárias (na forma de um identificador e um segredocompartilhado). As credenciais temporárias são incluídas no corpo da respostaHTTP utilizando o tipo de conteúdo “application/x-www-form-urlencoded” com umcódigo de estado 200, que significa sucesso na requisição. (OAUTH, 2010) Segundo OAuth (2010) a resposta contém os seguintes parâmetrosobrigatórios: • oauth_token: O identificador de credenciais temporárias; • oauth_token_secret: O segredo compartilhado de credenciais temporárias;
  • 27 • oauth_callback_confirmed: Deve estar presente e definido como “true”. Este parâmetro é utilizado para diferenciar de versões antigas do protocolo. Note que mesmo que o parâmetro inclua o termo “token”, essas credenciaisnão são as credenciais de token, mas são utilizadas nas próximas duas etapas deuma maneira similar às credenciais de token. O Quadro 4 contém um exemplo deresposta HTTP de credenciais temporárias. (OAUTH, 2010)HTTP/1.1 200 OKContent-Type: application/x-www-form-urlencodedoauth_token=hdk48Djdsa&oauth_token_secret=xyz4992k83j47x0b&oauth_callback_confirmed=trueQuadro 4: Exemplo de Resposta HTTP de Credenciais TemporáriasFonte: OAuth (2010)2.8.5 Autorização do proprietário do recurso Antes do cliente solicitar o conjunto de credenciais de token doservidor, ele deve enviar o usuário ao servidor para autorizar a requisição. O clienteconstrói uma URI de pedido para o endpoint de Autorização do proprietário dorecurso, adicionando o parâmetro obrigatório “oauth_token”, que contém oidentificador de credenciais temporárias, obtido na etapa anterior no parâmetro“oauth_token” da resposta. (OAUTH, 2010) O cliente direciona o proprietário de recursos para a URI construídautilizando uma resposta HTTP de redirecionamento, ou outros meios disponíveisutilizando o agente de usuário do proprietário de recursos. A requisição deve utilizaro método HTTP “GET”. (OAUTH, 2010) Por exemplo, o cliente redireciona o agente de usuário do proprietário dorecurso para efetuar o seguinte pedido HyperText Transfer Protocol Secure (HTTPS)apresentado no Quadro 5.GET /authorize_access?oauth_token=hdk48Djdsa HTTP/1.1Host: server.example.comQuadro 5: Exemplo de pedido de autorizaçãoFonte: OAuth (2010) Independente da maneira na qual o servidor processa o pedido de
  • 28autorização, incluindo ou não um canal seguro, o servidor sempre deverá verificarprimeiramente a identidade do proprietário do recurso. Ao pedir para o proprietário de recurso para autorizar o pedido de acesso, oservidor deve apresentar ao proprietário de recurso informações sobre o cliente queestá solicitando o acesso baseado na associação das credenciais de acessotemporárias com a identidade do cliente. Ao exibir qualquer uma dessasinformações, o servidor deve indicar se as informações foram verificadas. Após receber uma decisão de autorização do proprietário do recurso, oservidor redireciona o usuário para o endereço de retorno, caso algum tenha sidoinformado no parâmetro “oauth_callback” ou por outros meios. Para garantir que o proprietário de recurso que está concedendo o acesso éo mesmo proprietário de recurso que está retornando de volta ao cliente paracompletar o processo, o servidor deve gerar um código de verificação: um valor nãoadivinhável é passado para o cliente através do proprietário de recurso e obrigatóriopara concluir o processo. O servidor constrói uma URI de solicitação adicionando osseguintes parâmetros obrigatórios para o endereço de retorno: oauth_token: O identificador de credenciais temporárias recebido do cliente; oauth_verifier: O código de verificação. O endereço de retorno já possui um componente de consulta, o servidordeve acrescentar os parâmetros do OAuth no final da consulta existente. Porexemplo, o servidor redireciona o agente de usuário do proprietário do recurso paraefetuar a seguinte requisição HTTP:GET /cb?x=1&oauth_token=hdk48Djdsa&oauth_verifier=473f82d3 HTTP/1.1Host: client.example.netQuadro 6: Redirecionamento para o endereço de retorno com parâmetros do OauthFonte: OAuth (2010) Se o cliente não forneceu um endereço de retorno, o servidor deve exibir ovalor do código de configuração, e instruir o proprietário de recurso para informarmanualmente o cliente que a autorização está completa. Se o servidor conhece umcliente que está rodando em um dispositivo limitado, ele deve garantir que o valor deverificação é acessível para o registro manual.
  • 292.8.6 Credenciais de Token O cliente obtém um conjunto de credenciais de token do servidor fazendoum pedido HTTP “POST” autenticado para o endpoint de Pedido de token. O clienteconstrói uma URI de pedido adicionando o seguinte parâmetro obrigatório: oauth_verifier: Código de verificação recebido do servidor no passoanterior. Ao efetuar o pedido, o cliente faz a autenticação utilizando suas credenciais(identificadores do cliente) assim como as credenciais temporárias. As credenciaistemporárias são utilizadas como um substituto para as credenciais de token nopedido autenticado e transmitidas utilizando o parâmetro “oauth_token”. Uma vez que o pedido resulta na transmissão das credenciais em texto purona resposta HTTP, o servidor deve requerer o uso de um mecanismo de camada detransporte como o SSL (ou um canal seguro com proteções equivalentes). Umexemplo de um pedido de credenciais de token utilizando um pedido HTTPS éapresentado no Quadro 7.POST /request_token HTTP/1.1Host: server.example.comAuthorization: OAuth realm="Example",oauth_consumer_key="jd83jd92dhsh93js",oauth_token="hdk48Djdsa",oauth_signature_method="PLAINTEXT",oauth_verifier="473f82d3",oauth_signature="ja893SD9%26xyz4992k83j47x0b"Quadro 7: Pedido de Credenciais de TokenFonte: OAuth (2010) O servidor deve verificar a validade do pedido, garantir que o proprietário dorecurso autorizou o fornecimento de credenciais de token ao cliente, e garantir queas credenciais temporárias não foram expiradas ou usadas anteriormente. Oservidor deve verificar também o código de verificação recebido do cliente. Se opedido é válido e autorizado, as credenciais de token são incluídas no corpo daresposta HTTP utilizando o tipo de conteúdo "application/x-www-form-urlencoded"com um código de estado 200 (OK). A resposta contém os seguintes parâmetros obrigatórios, e um exemplo deresposta contendo credenciais de token é apresentado no Quadro 8:
  • 30 oauth_token: O identificador do token. oauth_token_secret: O segredo compartilhado do token.HTTP/1.1 200 OKContent-Type: application/x-www-form-urlencodedoauth_token=j49ddk933skd9dks&oauth_token_secret=ll399dj47dskfjdkQuadro 8: Resposta do servidor com as credenciais de tokenFonte: OAuth (2010) O servidor deve reter o escopo, duração e outros atributos aprovados peloproprietário de recurso, e reforçar essas restrições ao receber uma requisição de umcliente com as credenciais de token emitidas. Uma vez que o cliente receba e armazene as credenciais de token, ele podeproceder para acessar recursos protegidos em nome do proprietário de recursofazendo requisições autenticadas utilizando as credenciais de cliente em conjuntocom as credenciais de token recebidas.2.8.7 Requisições Autenticadas Alguns métodos especiais do protocolo HTTP permitem que clientes façamrequisições autenticadas, permitindo que eles ganhem acesso a recursos protegidosutilizando suas credenciais (tipicamente o par usuário/senha), que permitem que oservidor verifique a autenticidade dos mesmos. Utilizar estes métodos paradelegação exige que o cliente assuma o papel do proprietário do recurso. (OAUTH,2010) O OAuth fornece um método projetado para incluir dois conjuntos decredenciais com cada requisição, um para identificar o cliente e outro para identificaro proprietário do recurso. Antes do cliente ter permissão para fazer uma requisiçãoautenticada em nome do proprietário do recurso, ele deve obter um token autorizadopelo proprietário do recurso, seguindo o método explicado nas seções anteriores.(OAUTH, 2010) As credenciais do cliente tomam a forma de um identificador único e umsegredo compartilhado único ou um par de chaves RSA. Antes de fazer requisiçõesautenticadas, o cliente estabelece esse conjunto de credenciais com o servidor. Oprocesso e os requisitos para prover essas credenciais variam de acordo com o
  • 31implementador do protocolo. (OAUTH, 2010) De acordo com a especificação de OAuth (2010), uma requisiçãoautenticada inclui diversos parâmetros do protocolo. Cada nome de parâmetro iniciacom o prefixo “oauth_”, e os nomes e valores dos parâmetros são sensíveis à caixa.Clientes fazem requisições autenticadas calculando os valores de um conjunto deparâmetros de protocolo e adicionando-os à requisição HTTP da seguinte forma: 1. O cliente define o valor de cada um dos seguintes parâmetros de protocolo: • oauth_consumer_key: A porção de identificação das credenciais do cliente (equivalente ao nome de usuário). O nome do parâmetro reflete um termo depreciado (Chave do Consumidor) utilizado nas revisões da especificação, e mantido para manter compatibilidade. • oauth_token: O valor de token utilizado para associar o pedido com o proprietário do recurso. Se o pedido não está associado a um proprietário do recurso (nenhum token disponível), os clientes devem omitir o parâmetro. • oauth_signature_method: O nome do método de assinatura utilizado pelo cliente para assinar o pedido. • oauth_timestamp: Valor de estampa de tempo. • oauth_nonce: Valor nonce. • oauth_version: Valor opcional, caso esteja presente deverá ser definido como “1.0”. Fornece a versão do processo de autenticação a ser utilizado. 2. Os parâmetros de protocolo são adicionados ao pedido utilizando algum método de transmissão. Cada parâmetro não deve aparecer mais de uma vez no pedido . 3. O cliente calcula e define o valor do parâmetro “oauth_signature” e adiciona o parâmetro ao pedido utilizando o mesmo método do passo anterior . 4. O cliente envia o pedido HTTP autenticado para o servidor. Para efetuar o pedido HTTP autenticado do Quadro 9, conforme OAuth(2010), o cliente deverá definir os parâmetros do protocolo do Quadro 10, utilizando
  • 32suas credenciais de cliente, credenciais de token, a estampa de tempo atual, umvalor nonce gerado automaticamento e indica que o método de assinatura será o“HMAC-SHA1”.POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1Host: example.comContent-Type: application/x-www-form-urlencodedc2&a3=2+qQuadro 9: Pedido HTTPFonte: OAuth (2010)oauth_consumer_key: 9djdj82h48djs9d2oauth_token: kkk9d7dh3k39sjv7oauth_signature_method: HMAC-SHA1oauth_timestamp: 137131201oauth_nonce: 7d8f3e4aQuadro 10: Parâmetros de ProtocoloFonte: OAuth (2010) O cliente adiciona parâmetros do protocolo para o pedido utilizando o campode cabeçalho HTTP do OAuth “Authorization”, conforme ilustrado no Quadro 11.(OAUTH, 2010)Authorization: OAuth realm="Example",oauth_consumer_key="9djdj82h48djs9d2",oauth_token="kkk9d7dh3k39sjv7",oauth_signature_method="HMAC-SHA1",oauth_timestamp="137131201",oauth_nonce="7d8f3e4a"Quadro 11: Pedido HTTP com o Parâmetro de AutorizaçãoFigura: OAuth (2010) Por último o cliente calcula o valor do parâmetro “oauth_signature”,adiciona-o ao pedido e envia o pedido HTTP ilustrado no Quadro 12 ao servidor.(OAUTH, 2010)
  • 33POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1Host: example.comContent-Type: application/x-www-form-urlencodedAuthorization: OAuth realm="Example",oauth_consumer_key="9djdj82h48djs9d2",oauth_token="kkk9d7dh3k39sjv7",oauth_signature_method="HMAC-SHA1",oauth_timestamp="137131201",oauth_nonce="7d8f3e4a",oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"c2&a3=2+qQuadro 12: Pedido HTTP autorizado completoFonte: OAuth (2010)2.8.8 Experiência do Usuário Quando o OAuth é utilizado em uma aplicação, a experiência para o usuáriofinal que interage com a aplicação é muito menos intrusiva e complicada do que oprocesso necessário para o desenvolvimento da mesma. (LEBLANC, 2011) Implementações da tela de permissão, onde usuários permitem que umaaplicação façam ações em seu nome, podem variar muito dependendo daplataforma onde ela é implementada, mas o princípio básico é o mesmo. Aplataforma exibe uma página contendo uma informação básica sobre a aplicação efornece meios para que o usuário possa permitir ou negar que a aplicação utilizeseus dados pessoais. (LEBLANC, 2011) Leblanc (2011, p. 327) destaca as telas de autorização de algumasplataformas que utilizam o OAuth, na Figura 1 é apresentada a tela de autorizaçãodo Twitter e na Figura 2 é apresentada a tela do Yahoo!.
  • 34 Figura 1: Tela de Autorização do Twitter Fonte: Leblanc (2011) No caso da implementação do Yahoo!, o usuário primeiramente deveinformar seu usuário e senha e, posteriormente, ele será redirecionado para a telade permissão. Nesta tela também são exibidas as aplicações necessárias para ofornecimento de dados da aplicação que está requisitando autorização. (LEBLANC,2011)
  • 35Figura 2: Tela de Autorização do Yahoo!Fonte: Leblanc (2011)
  • 363 PROCEDIMENTOS METODOLÓGICOS Para a realização do estudo de caso proposto neste trabalho foram adotadosmétodos que envolvem desde a parte de pesquisa até os estudos tecnológicos e autilização de uma estrutura física para o correto funcionamento das implementações.O objetivo deste capítulo é descrever detalhadamente cada um dos procedimentosadotados, assim como as principais justificativas das escolhas tecnológicas desteestudo.3.1 PROCEDIMENTOS DE PESQUISA Tratando-se dos procedimentos de pesquisa será utilizado, inicialmente, apesquisa bibliográfica, por ser “[...] desenvolvida com base em material já elaboradoconstituído principalmente de livros e artigos científicos.” (GIL, 2002). Posterior àetapa da pesquisa bibliográfica, será adotada a pesquisa experimental porque,segundo Gil (2002), consiste em determinar um objeto de estudo, selecionar asvariáveis que seriam capazes de influenciá-lo, definir as formas de controle e deobservação dos efeitos que a variável produz no objeto.3.1.1 Tipo de Pesquisa Quanto a natureza da pesquisa ela pode ser classificada como aplicada pois“[...] é feita a partir de objetivos que visam sua utilização prática. Valem-se essaspesquisas das contribuições das teorias e leis já existentes.” (PARRA FILHO et al,2001). Quanto aos objetivos, esta pesquisa classifica-se como exploratória pois “[...]têm como objetivo proporcionar maior familiaridade com o problema, com vistas atorná-lo mais explícito ou a constituir hipóteses.” (GIL, 2002).3.2 ESTRUTURA FÍSICA A estrutura física utilizada para o desenvolvimento e testes das aplicações écomposta de um notebook doméstico com sistema operacional GNU/Linux Ubuntu
  • 3711.10, os navegadores de internet Opera 11 e Chromium, e a rede utilizada é a FastEthernet 100. A configuração de hardware do notebook utilizado para o desenvolvimento etestes é a seguinte: • CPU Pentium Dual Core T2130 1.86GHz; • 2 GB de memória DDR2 667MHz; • HD de 160 GB SATA.3.3 TECNOLOGIAS Para a implementação das aplicações que são objetos de estudo destetrabalho foram utilizadas diversas tecnologias que, juntas, fornecem o corretofuncionamento do protocolo OAuth e das funcionalidades desenvolvidas em cadaaplicação.3.3.1 Java De acordo com a Sun Microsystems (atualmente Oracle) o Java é umambiente de programação simples, robusto, orientado a objetos, independente deplataforma, dinâmico e de propósito geral. Esta definição permitiu ao Java crescer ese expandir para diversos nichos. Atualmente ele é utilizado em plataformasempresariais e em pequenos dispositivos. Para que o Java suporte esta gama deambientes diversas interfaces de programação de aplicações (APIs) e versões foramdesenvolvidas. (SPELL, 2005) Segundo Spell (2005) a arquitetura Java completa é composta por quatrocomponentes: • A linguagem de programação Java; • O formato de arquivo de classe Java; • As APIs Java compostas por Java 2 Platform – Standard Edition (J2SE), Java 2 Platform – Enterprise Edition (J2EE) e Java 2 Platform – Micro Edition (J2ME); • E a máquina virtual do Java (JVM).
  • 383.3.2 Spring MVC e Spring Security O Spring Framework é uma solução leve utilizada para desenvolveraplicações corporativas. Ele é modular, permitindo a utilização apenas das partesnecessárias, sem a necessidade de utilizar o pacote completo. O Spring Frameworksuporta gerenciamento transacional declarativo, acesso remoto à lógica com RMI eweb services, e diversas opções de persistência de dados. Além disso ele ofereceum framework MVC completo, e habilita a utilização de linguagem orientada aaspectos (AOP) transparentemente no software. O componente de Inversion ofControl (IoC) provê um meio de injetar dependências de uma classe utilizando meiosformais de compor componentes diferentes em uma aplicação totalmente funcionalpronta para utilização. (SPRING, 2010) Spring MVC é um componente do framework projetado para auxiliar efacilitar o desenvolvimento de aplicações web, oferecendo uma ferramenta paradesenvolver aplicações flexíveis e com baixo acoplamento, assim como o próprioSpring Framework é. Ele fornece funcionalidades de gerenciar o estado, fluxo detrabalho, validação. (WALLS, 2011) Spring Security é outro componente do framework que oferece diversosrecursos que permitem que práticas de segurança comuns possam ser declaradasou configuradas de uma forma direta e declarativa. Com o Spring Security é possívelmapear usuários a classes da aplicação, definir níveis de autorização a papéis deusuário, definir papéis de usuários às classes, aplicar regras de autenticação portodos os recursos da aplicação, assim como regras de autorização e prevenir tiposcomuns de ataque com o intuito de manipular ou roubar a sessão dos usuários.(MULARIEN, 2010) O componente Spring Security OAuth fornece uma implementação doprotocolo OAuth ao Spring Security. Ele suporta a especificação 1.0 e a 2.0, queainda está em fase de desenvolvimento. Ele suporta componentes para consumir efornecer serviços de autenticação que suportam OAuth. (SRINGOAUTH, 2010)3.3.3 Hibernate O Hibernate é uma solução de Mapeamento Objeto-Relacional (ORM) para
  • 39ambientes Java. O termo Mapeamento Objeto-Relacional refere-se à técnica demapear dados de um modelo de representação em objetos para um modelo derepresentação relacional (e vice e versa). Além do Hibernate lidar com estemapeamento ele também provê recursos para consulta e obtenção de dados. OHibernate ajuda no encapsulamento de código SQL específico dos bancos de dados,abstraindo os mesmos do desenvolvedor, e fornece integração com diversossistemas gerenciadores de banco de dados. (HIBERNATE, 2010)3.3.4 PHP PHP é uma linguagem de script amplamente utilizada, especialmenteadequada para o desenvolvimento web e pode ser incorporada ao HTML. O quediferencia o PHP de linguagens como o Javascript é que ele é executado noservidor, gerando o código HTML final que será enviado ao cliente. O clientereceberá o resultado da execução do script, mas não saberá o código que geroueste resultado. O PHP pode ser utilizado para, entre outras coisas, coletar dados deformulários, gerar conteúdo de páginas dinamicamente, enviar e receber cookies emanipular banco de dados. (PHP, 2011)3.3.5 Zend Framework Zend Framework é um framework de código aberto utilizado nodesenvolvimento de aplicações e serviços web utilizando a linguagem PHP naversão 5. O framework é desenvolvido utilizando um código totalmente orientado aobjetos. A estrutura de componentes fornecida pelo Zend Framework foi projetadade forma a diminuir a dependência entre eles, permitindo a utilização decomponentes individuais. O framework também fornece uma implementação robustae de alta performance do padrão MVC, além da abstração com o banco de dados,componentes para formulários com validação e filtros, componentes de autenticaçãoe autorização, incluindo suporte ao protocolo OAuth. (ZEND, 2010)
  • 403.3.6 Play Framework O Play Framework é uma alternativa limpa para o conjunto inchado do JavaEnterprise. Seu principal foco é a produtividade do desenvolvedor e sua meta éarquiteturas REST. O Play é um ótimo auxiliar para o desenvolvimento ágil desoftware. Seu principal objetivo é facilitar o desenvolvimento de aplicações web e, aomesmo tempo, se manter alinhado ao Java. Ele foi escrito puramente em Java, emantém bibliotecas e ferramentas comuns deste ecossistema. O framework compilaos fontes Java diretamente e recarrega-os na JVM sem a necessidade de reiniciar oservidor. Ele provê um mecanismo eficiente de templates com a linguagem Groovy,que possui uma sintaxe muito consistente ao Java, além de fornecer JPA como a APIde mapeamento objeto-relacional, utilizada na persistência de dados. (PLAY, 2010)3.3.7 HTML 5 e CSS3 HyperText Markup Language 5 (HTML5) e Cascading Style Sheets 3 (CSS3)são dois padrões novos propostos pela World Wide Web Consortium (W3C). Essastecnologias são a evolução das tecnologias utilizadas no dia a dia de envolvidos coma internet, e existem para ajudar na construção de aplicações web modernas einovadoras. Diversas novas funcionalidades ajudam na melhora da sintaxe dalinguagem, assim como adicionam um suporte maior a animações interoperáveis(independentes de plugins de terceiros), trazem novas funcionalidades parautilização de sockets, armazenamento offline, melhorias de formulários e muito mais.(HOGAN, 2010) O CSS3 adiciona novos seletores para melhorar a estilização decomponentes, como, por exemplo, até a identificação de colunas pares e ímpares deuma tabela. A nova versão do CSS também traz efeitos visuais sofisticados, comosombras, gradientes, cantos arredondados e etc. Ambas as novas tecnologias aindasão trabalhos em andamento, porém cada vez mais as ferramentas de acesso àinternet (como navegadores) estão adotando e suportando essas tecnologias.(HOGAN, 2010)
  • 413.3.8 MySQL O software MySQL provê um servidor de banco de dados Structured QueryLanguage (SQL) robusto, multi-usuário, rápido e eficaz. Ele é indicado para sistemasem produção de alta carga assim como para incorporação em massa de sistemas jáimplantados. O servidor MySQL possui uma licença comercial, fornecida pela Oraclee uma versão de código-aberto. (MYSQL)3.4 JUSTIFICATIVAS TECNOLÓGICAS O protocolo OAuth foi escolhido principalmente por sua facilidade deimplementação, tanto na parte servidor quanto para os consumidores. Quandocomparado ao OpenID e CAS, a implementação de um servidor de recursos semostra menos complexa. Outro motivo é que grandes empresas utilizam o OAuthem casos de sucesso, como o Facebook ou Twitter. E, finalmente, o protocolo OAuthutiliza padrões abertos como HTTP junto com todos os seus recursos e permitegrande flexibilidade com relação a mecanismos de criptografia, e exigências deobrigatoriedade de parâmetros, ficando a cargo do desenvolvedor decidir o que émais adequado para o seu caso. A tecnologia Java foi escolhida para ser utilizada na aplicação servidor deOAuth principalmente por ser uma das mais utilizadas no ambiente corporativo, queé o ambiente ideal para a implantação do OAuth, principalmente por, na maioria doscasos, um ambiente corporativo ser dividido em diversas aplicações independentesentre si, mas que utilizam uma base de autenticação de usuários. Junto com o Java,foram utilizados os frameworks Spring, Spring Security com Spring Security OAuth eJPA com Hibernate. O Spring e Spring Security com o módulo OAuth foram utilizados para provermeios de autenticação, segurança das funcionalidades, recursos web para cadastrode usuários, injeção de dependências, mapeamento de URL e gerencia de beans. OHibernate foi o escolhido por suportar a especificação Java Persistence API (JPA),suportar diversos bancos de dados e fornecer recursos para consultas emapeamento objeto-relacional. O PHP foi utilizado, em conjunto com o Zend Framework, para desenvolver
  • 42a aplicação de controle de finanças, e ambos foram escolhidos pela baixa curva deaprendizado, por sua robustez e produtividade. O Zend Framework é desenvolvidopela Zend, principal mantenedora da linguagem PHP, e é muito bem projetado, comuma estrutura de componentes similar ao Spring. O Play! Framework foi escolhido devido à sua simplicidade, altaprodutividade, sintaxe limpa de templates (graças ao Groovy), integração nativa comJPA, mapeamento de requisições, e por sua fácil integração com o OAuth. HTML5 e CSS3 foram as linguagens escolhidas para a parte de visualizaçãodas aplicações. Foram utilizados seletores avançados do CSS3, validação nativa doHTML5, novas tags, cantos arredondados, sombras e gradientes. O banco de dados MySQL foi escolhido por sua fácil integração com cadauma das tecnologias utilizadas nas aplicações.
  • 434 IMPLEMENTAÇÃO Este capítulo descreve as três aplicações desenvolvidas para demonstrar ofuncionamento do protocolo OAuth. Cada aplicação foi construída em um escoposeparado visando demonstrar a capacidade de integração das tecnologias com oprotocolo OAuth e os recursos básicos necessários para um provedor deautenticação. Foram elaboradas as seguintes aplicações, explanadas maisdetalhadamente a seguir: • Servidor de Autenticação OAuth: Fornece as capacidades de autenticação utilizando o protocolo OAuth; • Agenda de contatos: Uma aplicação de agenda de contatos simples que se autentica com o servidor de autenticação OAuth; • Controle de Finanças: Uma aplicação para controle de finanças, utiliza o servidor de autenticação OAuth para permitir sua utilização.4.1 SERVIDOR DE AUTENTICAÇÃO O servidor de autenticação foi desenvolvido com o propósito de fornecer oendpoint de autenticação para consumidores OAuth. Sua estrutura foi definidautilizando o framework Spring MVC, com o padrão arquitetural Model-View-Controller (MVC), além de definir serviços, entidades e repositórios conformeapresentado na Figura 3.
  • 44 Figura 3: Arquitetura Definida Fonte: Autoria Própria4.1.1 Configuração do Spring Security e OAuth Para fornecer os recursos de segurança e proteção de acessos foi utilizadoo framework Spring Security, em conjunto com o componente Spring Security OAuth.Para configurá-los é necessário definir um arquivo XML com todos os parâmetros deconfiguração necessários para a aplicação. O Quadro 13 apresenta o arquivo deconfiguração utilizado na aplicação.
  • 45<security:http pattern="/resources/**" security="none" /><security:http pattern="/user/login*" security="none" /><security:http auto-config="true" access-denied-page="/user/login" use-expressions="true"> <security:intercept-url pattern="/oauth/**"access="isAuthenticated()" /> <security:intercept-url pattern="/request_token_authorized.jsp"access="isAuthenticated()" /> <security:intercept-url pattern="/dashboard"access="isAuthenticated()" /> <security:intercept-url pattern="/index.jsp"access="isAuthenticated()" /> <security:intercept-url pattern="/user/profile"access="isAuthenticated()" /> <security:intercept-url pattern="/user/info/**"access="isAuthenticated()" /> <security:intercept-url pattern="/**" access="hasRole(ROLE_ADMIN)" /> <security:form-login default-target-url="/" authentication-failure-url="/user/login?login_error=1" login-page="/user/login" login-processing-url="/login.do" /> <security:logout logout-success-url="/user/login" logout-url="/logout.do" /></security:http><security:authentication-manager> <security:authentication-provider user-service-ref="userService"> <security:password-encoder ref="passwordEncoder" hash="md5" /> </security:authentication-provider></security:authentication-manager><oauth:provider consumer-details-service-ref="consumerDetails" token-services-ref="tokenServices" request-token-url="/oauth/request_token"authenticate-token-url="/oauth/authorize" authentication-failed-url="/oauth/confirm_access" access-granted-url="/request_token_authorized.jsp" access-token-url="/oauth/access_token"require10a="false" /><oauth:consumer-details-service id="consumerDetails"> <oauth:consumer name="Contas.tcc" secret="oauth-tcc-secret-01"key="contas-consumer-key" resourceName="Seu Perfil"resourceDescription="Dados do seu perfil de usuário" /> <oauth:consumer name="Agenda.tcc" secret="oauth-tcc-secret-02"key="agenda-consumer-key" resourceName="Dados Pessoais"resourceDescription="Seus dados pessoais" /></oauth:consumer-details-service><oauth:token-services id="tokenServices" /><bean id="passwordEncoder"class="org.springframework.security.authentication.encoding.Md5PasswordEncoder" />Quadro 13: Arquivo de Configuração do Spring SecurityFonte: Autoria Própria Os principais pontos a se destacar neste arquivo de configuração são osparâmetros com o prefixo “security:”. Primeiramente são definidos dois endpointsque não terão segurança: a pasta de imagens, arquivos de folhas de estilos ejavascript nomeada “resources”, e o endereço utilizado para acessar o formulário deautenticação “/user/login”.
  • 46 A próxima etapa é adicionar restrições para que os endereços internos dosistema só possam ser acessados por usuários autenticados. Os endereços quecontém as palavras “oauth”, “request_token_authorized.jsp”, “dashboard”,“index.jsp”, “user/profile”, “user/info” serão protegidos pelo framework desegurança, exigindo que um usuário esteja autenticado para acessar algum destesendereços. Também é definido o endereço para o formulário de autenticação. Após definir a configuração de recursos protegidos, é necessário configuraro serviço que fornece os meios de autenticação do usuário. Neste caso foi definidoum serviço customizado, contendo o código apresentado no Quadro 14, assim comoum bean para criptografia de senha. As próximas linhas definem a configuração do provedor de OAuth daaplicação. É necessário definir o serviço que fornece dados dos consumidoressuportados pela aplicação. Somente os consumidores definidos na tag “consumer-details-service” poderão consumir o serviço de autenticação, requisitando aautorização de acesso pelo proprietário do recurso autenticado. Para este trabalhoforam definidos dois consumidores: uma aplicação de finanças e outra de agenda decontatos. O parâmetro “token-services-ref”, define o serviço que fornecerá asfuncionalidades para: • Gerar credenciais temporárias; • Gerar tokens de acesso; • Verificar a validade dos tokens; • Vincular consumidores, proprietários de recursos e tokens. Para a aplicação desenvolvida, foi utilizada a classe“InMemoryProviderTokenServices”, que é um serviço de tokens nativo dabiblioteca Spring Security OAuth, que armazena em memória os tokens gerados eutiliza mecanismos de tempo para validar um token utilizado para uma tentativa deautorização ou para uma requisição autenticada. Os demais parâmetros definidos na tag “provider” definem os endpointspara, respectivamente, a requisição de tokens temporários, a autenticaçãoautorizada por um proprietário do recurso, a página de autorização de umconsumidor pelo proprietário do recurso, a página de confirmação de que o acesso
  • 47foi concebido (caso não seja definido o parâmetro “oauth_callback”) e o endereçopara obter as credenciais de token.4.1.2 Autenticação de Usuários O arquivo de configuração do Spring Security, define um serviço deautenticação de usuários, que nada mais é do que um bean que implementa ainterface UserDetailsService e o método loadByUsername. O Quadro 14 mostraum trecho do serviço implementado, que busca na base de dados por um nome deusuário passado como parâmetro do método.@Service("userService")public class UserServiceImpl implements UserService{ @Autowired private UserRepository userRepository; @Override public UserDetails loadUserByUsername(String username) { return userRepository.findByUsername(username); }}Quadro 14: Serviço de UsuárioFonte: Autoria Própria O banco de dados da aplicação é composto apenas por uma tabela deusuários e para manipular esta tabela foi implementado um repositório, que utiliza oEntityManager fornecido pelo Hibernate para efetuar uma consulta baseando-se nonome de usuário passado como parâmetro. O código deste repositório éapresentado no Quadro 15.
  • 48@Repositorypublic class UserRepository extends AbstractRepository<User> { public User findByUsername(String username) { try { TypedQuery<User> query = this.entityManager.createQuery("select ufrom User u where u.username = :username", User.class); query.setParameter("username", username); return query.getSingleResult(); } catch (NoResultException e) { return null; } }}Quadro 15: Repositório de usuáriosFonte: Autoria Própria No Quadro 16 é apresentado o código do formulário de autenticação,utilizando HTML5. Foram utilizados os novos atributos da tecnologia que permitemque o próprio navegador de internet faça a validação dos campos, sem anecessidade de programar Javascript para essa funcionalidade. Também foramutilizadas as tags novas que dão mais semântica ao código implementado.<div class="login-wrapper"> <header> <h1>MyPortal - Login</h1> <c:if test="${not empty param.login_error}"><div class="error">Ocorreu um erro. Verifique seu usuário/senha.</div></c:if> </header> <section id="content"> <form method="post" action="<c:url value="/login.do"/>" class="form-login"> <p> <label for="username">Nome de Usuário:</label> <input type="text" id="username" name="j_username"required="required" /> </p> <p> <label for="password">Senha:</label> <input type="password" id="password" name="j_password"required="required" /> </p> <p><input class="button blue" type="submit" value="Autenticar"/></p> </form> </section></div>Quadro 16: Tela com o Formulário de LoginFonte: Autoria Própria O resultado deste código é apresentado na Figura 4. Esta tela deautenticação é apresentada ao usuário ao se acessar alguma das aplicações
  • 49desenvolvidas e permite que o usuário forneça suas credenciais de acesso,prosseguindo com o fluxo de autorização. Figura 4: Tela de autenticação Fonte: Autoria Própria4.1.3 Confirmação do Proprietário do Recurso Para que o consumidor possa utilizar os dados do proprietário do recurso oOAuth exige que, após efetuar a autenticação, o provedor apresente uma telasolicitando ao proprietário do recurso se ele autoriza ou não o acesso do consumidoraos seus dados. Para esta funcionalidade foi desenvolvido um controlador, queresponde à URL configurada no arquivo de configuração do Spring Security,responsável por direcionar o usuário para a tela de confirmação de acesso daaplicação, validar as credenciais e tokens temporários, e, também, revogar umacesso a um token temporário. O Quadro 17, apresenta o código implementado paraeste controlador.
  • 50@Controllerpublic class AccessConfirmationController{ @Autowired private OAuthProviderTokenServices tokenServices; @Autowired private ConsumerDetailsService consumerDetailsService; @RequestMapping("/oauth/confirm_access") public ModelAndView accessConfirmation(HttpServletRequest request,HttpServletResponse response) throws Exception { String token = request.getParameter("oauth_token"); if (token == null) { throw new IllegalArgumentException("Deve ser informado um token derequisição"); } OAuthProviderToken providerToken = tokenServices.getToken(token); ConsumerDetails consumer =consumerDetailsService.loadConsumerByConsumerKey(providerToken.getConsumerKey()); String callback = request.getParameter("oauth_callback"); TreeMap<String, Object> model = new TreeMap<String, Object>(); model.put("oauth_token", token); if (callback != null) { model.put("oauth_callback", callback); } model.put("consumer", consumer); return new ModelAndView("access_confirmation/confirm", model); } @RequestMapping("/oauth/revoke/{tokenValue}") public ModelAndView accessRevoked(@PathVariable String tokenValue) {((OAuthProviderTokenImpl)this.tokenServices.getToken(tokenValue)).setTimestamp(0); return new ModelAndView("access_confirmation/revoked"); }}Quadro 17: Controlador de Confirmação de AcessoFonte: Autoria Própria A primeira etapa é verificar se os parâmetros de token foram informados narequisição, após isso o token é obtido do serviço definido no arquivo deconfiguração, e logo após, os dados do consumidor são obtidos. Caso em algumadessas etapas algum dado não seja informado, será lançada uma exceção e ocódigo HTTP de erro será o “401” UNAUTHORIZED. Caso o parâmetro“oauth_callback” esteja definido, ele será definido também na tela de autorização,para que o Spring OAuth redirecione o usuário caso o mesmo permita o acesso doconsumidor. O método de revogação de acesso, faz com que o token temporário expire
  • 51e, redireciona o usuário para informar que o consumidor foi revogado com sucesso. O Quadro 18 apresenta o código da tela de autorização do proprietário dorecurso. Ele aponta o endereço para o endpoint definido de confirmação daautorização do acesso. Caso exista o parâmetro “oauth_callback” o mesmo éadicionado a um campo escondido do formulário, e internamente, o Spring SecurityOAuth define este endereço como o ponto de redirecionamento após concluir oprocesso de autorização.<layout:page title="MyPortal - Autorizar Aplica&ccedil;&atilde;o"> <jsp:body> <h2>Confirmar Acesso</h2> <p>Voc&ecirc; confirma a autoriza&ccedil;&atilde;o daaplica&ccedil;&atilde;o &quot;<c:out value="${consumer.consumerName}"/>&quot; para acessar os seguintes recursos:</p> <ul> <li><c:out value="${consumer.resourceName}" /> &mdash; <c:outvalue="${consumer.resourceDescription}" /></li> </ul> <form action="<c:url value="/oauth/authorize"/>" method="post"> <input name="requestToken" value="<c:out value="${oauth_token}"/>"type="hidden" /> <c:if test="${!empty oauth_callback}"> <input name="callbackURL" value="<c:out value="${oauth_callback}"/>" type="hidden"/> </c:if> <p> <input class="button blue" name="authorize" value="Autorizar"type="submit" />&nbsp; <a href="<c:url value="/oauth/revoke/${oauth_token}"/>"class="button red">Revogar</a> </p> </form> </jsp:body></layout:page>Quadro 18: Formulário de Autorização de um ConsumidorFonte: Autoria Própria A tela de autorização do proprietário do recurso é apresentada na Figura 5,ela exibe as informações sobre a aplicação que está requirindo autorização doproprietário do recurso autenticado, e as opções de autorizar ou revogar o acesso daaplicação em questão.
  • 52 Figura 5: Tela de autorização Fonte: Autoria Própria Caso o proprietário do recurso revogue o acesso do consumidor ele serámantido na aplicação servidor de OAuth, e será exibida a tela apresentada na Figura6, que indica que o consumidor foi revogado com sucesso. Se o proprietário dorecurso autorizar o acesso do consumidor ele será redirecionado para as telasprincipais do consumidor em questão. Essas telas são apresentadas na e .Figura 6: Tela de acesso revogadoFonte: Autoria Própria4.2 APLICAÇÃO 1: AGENDA DE CONTATOS A primeira aplicação desenvolvida tem como foco principal fornecer umaagenda simples de contatos. Ela foi desenvolvida utilizando o Play! Framework, juntocom seu módulo OAuth, e permite que o usuário, após a autenticação e autorizaçãodo consumidor, mantenha uma lista de contatos com nome, endereço, telefone, e-mail e data de nascimento de cada contato. Os controladores possuem um método para verificar se existe um usuário
  • 53definido em sessão e, caso não exista, redireciona o usuário para que o mesmo façaautenticação como proprietário do recurso e autorize o consumidor a obter os dadosdo perfil do usuário. O código do Quadro 19 apresenta o método do controlador quefaz essa verificação, simplesmente validando um parâmetro da sessão.@Beforestatic void checkAuthentication() throws Exception { if (session.get("user") == null) AuthenticationController.auth();}Quadro 19: Método de verificação de usuário logadoFonte: Autoria Própria Caso seja necessário efetuar a autenticação do proprietário do recurso como OAuth, o controlador de autenticação será executado, ficando responsável porredirecionar o agente de usuário para o servidor Oauth, onde serão apresentadas aousuário as telas apresentadas nas Figuras 5 e 6, e obter o retorno do servidor. O Quadro 20 apresenta o código utilizado para criar o cliente OAuthutilizando o módulo disponível para o Play Framework onde os seguintes parâmetrosde configuração são definidos: • Endereço para obter o token temporário; • Endereço para obter o token de acesso; • Endereço para obter a autorização do proprietário do recurso; • Chave identificadora do consumidor; • Segredo compartilhado do consumidor. Após a criação do cliente OAuth, é criado um objeto que armazenará osdados de credenciais de token. E, após isso, o método authenticate, redireciona ousuário para o servidor OAuth, e define o endereço de retorno, a partir do parâmetro“oauth_callback” da requisição, que apontará para o método callback, apresentadono Quadro 21.
  • 54public static void auth() throws Exception { if (session.get("user") != null) ContatoController.index(); client = new OAuthClient("http://localhost:9090/tcc-oauth-server/oauth/request_token", "http://localhost:9090/tcc-oauth-server/oauth/access_token", "http://localhost:9090/tcc-oauth-server/oauth/confirm_access", "agenda-consumer-key", "oauth-tcc-secret-02"); credentials = new MyCredentials(); client.authenticate(credentials, "http://localhost:9000/auth/callback");}Quadro 20: Método de autenticação com o servidor OAuthFonte: Autoria Própria O método de retorno, irá obter o parâmetro “oauth_verifier”, que contém ocódigo de verificação indicando que o token para o consumidor em questão foidefinido e autorizado. Após obter o código verificador, o cliente OAuth obtém ascredenciais de token para, a partir deste ponto em diante, fazer requisiçõesautenticadas em nome do proprietário do recurso. A requisição efetuada obtém asinformações do perfil do proprietário do recurso, para definir em sessão o códigoidentificador do mesmo, o nome real e o nome de usuário utilizado por ele. Emseguida são utilizados os componentes do Play! Framework para mapear a respostaJSON retornada pelo servidor a um objeto do tipo User, são armazenados os dadosdo usuário em sessão e o controlador principal é invocado.public static void callback() throws Exception { String verifier = params.get("oauth_verifier"); credentials = MyCredentials.find("byToken",params.get("oauth_token")).first(); client.retrieveAccessToken(credentials, verifier); HttpResponse response = client.sign(credentials,WS.url("http://localhost:9090/tcc-oauth-server/user/info"),"POST").post(); JsonElement json = new JsonParser().parse(response.getString()); User user = new Gson().fromJson(json.getAsJsonObject().get("user"),User.class); session.put("user_id", user.id); session.put("user", user.username); session.put("user_realname", user.realname); ContatoController.index();}Quadro 21: Método de retorno do processo de autorização OAuthFonte: Autoria Própria Após concluir o fluxo de autorização e armazenar uma instância de User emsessão é apresentada a tela principal do sistema ao usuário, ilustrada na Figura 7.
  • 55 Figura 7: Tela inicial da aplicação de contatos Fonte: Autoria Própria Nesta tela o usuário poderá ver com que credenciais se autenticou, e sãolistados todos os contatos cadastrados pelo usuário autenticado. Ao acessar o botão“Adicionar Novo” é apresentado o formulário de cadastro de um contato, conformeapresentado na Figura 8. Figura 8: Tela para Adicionar um Contato Fonte: Autoria Própria
  • 564.3 APLICAÇÃO 2: CONTROLE DE FINANÇAS A aplicação de controle de finanças tem como objetivo fornecer ao usuário ocadastro de lançamentos de crédito e de débito e, baseando-se na soma doscréditos e débitos, apresentar o saldo do mesmo, destacando se é positivo ounegativo. Este aplicativo foi desenvolvido utilizando PHP 5.3 junto com o ZendFramework e seus componentes Zend_Auth, Zend_Oauth_Consumer, Zend_Db eZend_Mvc. Assim como a aplicação de agenda de contatos, o controle de finançasexige a autenticação e autorização do proprietário do recurso e, após isso, guardaem sessão os dados de seu perfil. O banco de dados utilizado define apenas atabela de contas. Seguindo o mesmo modelo da aplicação de contatos, o controle de finançasfaz a verificação se existe um usuário autenticado e, caso não exista, redireciona ousuário para um controlador de autenticação que implementa um consumidor OAuth.O Quadro 22 apresenta o plugin, configurado na pilha de plugins de controladoresdo Zend Framework, que faz a verificação se o componente Zend_Auth possui umaidentidade definida e, caso não possua, muda a requisição para o controlador deautenticação.class FernandoMantoan_Auth_OAuth_Plugin extendsZend_Controller_Plugin_Abstract{ public function preDispatch(Zend_Controller_Request_Abstract $request) { $auth = Zend_Auth::getInstance(); if (!$auth->hasIdentity()) { if ($request->getControllerName() != auth) { $request->setControllerName(auth); $request->setActionName(login); $request->setModuleName(default); } } else if ($request->getControllerName() == auth && $request->getActionName() == login) { $redirector =Zend_Controller_Action_HelperBroker::getStaticHelper(redirector); $redirector->gotoSimple(index, bills); } }}Quadro 22: Plugin de verificação de usuário autenticadoFonte: Autoria Própria Os parâmetros para a configuração do componente
  • 57Zend_Oauth_Consumer são definidos no arquivo de configuração application.inida aplicação. Estes parâmetros são apresentados no Quadro 23.oauth.siteUrl = "http://localhost:9090/tcc-oauth-server/oauth"oauth.authorizeUrl = "http://localhost:9090/tcc-oauth-server/oauth/confirm_access"oauth.callback = "http://localhost/tcc-oauth-contas/auth/callback"oauth.consumerKey = "contas-consumer-key"oauth.consumerSecret = "oauth-tcc-secret-01"userService.endpoint = "http://localhost:9090/tcc-oauth-server/user/info"userService.logout = "http://localhost:9090/tcc-oauth-server/logout.do"Quadro 23: Parâmetros de configuração dos serviços OAuthFonte: Autoria Própria O controlador de autenticação, apresentado no Quadro 24, é responsávelpor criar uma instância do componente Zend_Oauth_Consumer, utilizando osparâmetros de configuração definidos no arquivo de configuração, estes sendoobtidos na primeira linha do método init. As linhas subsequentes têm a função,respectivamente, de inicializar a sessão do Zend Framework, configurar osparâmetros do OAuth, que definem o endereço de retorno, o endereço do servidorOAuth, a chave de consumidor e o segredo de consumidor compartilhado. Apósinstanciar o componente, é definido o endereço de autorização de consumidores doservidor OAuth.public function init(){ $oauthParams = $this->getInvokeArg(bootstrap)->getOption(oauth); $this->_session = new Zend_Session_Namespace(oauth); $this->_oauthConfig = array(callbackUrl => $oauthParams[callback], siteUrl => $oauthParams[siteUrl], consumerKey => $oauthParams[consumerKey], consumerSecret => $oauthParams[consumerSecret]); $this->_oauthConsumer = new Zend_Oauth_Consumer($this->_oauthConfig); $this->_oauthConsumer->setAuthorizeUrl($oauthParams[authorizeUrl]);}public function loginAction(){ $token = $this->_oauthConsumer->getRequestToken(); $this->_session->token = serialize($token); $this->_oauthConsumer->redirect();}Quadro 24: Métodos de inicialização e de redirecionamento do controlador de autenticaçãoFonte: Autoria Própria O método loginAction ficará responsável por utilizar o componenteZend_Oauth_Consumer para obter o token temporário, armazená-lo em sessão e
  • 58redirecionar o proprietário do recurso para que o mesmo inicie o processo deautorização. Após autorizar a aplicação, o método callbackAction, apresentado noQuadro 25 é executado. Este método obtém o token temporário da sessão, obtémos parâmetros passados por GET no cabeçalho HTTP, e, caso os parâmetros sejamválidos, obtém as credenciais de token baseando-se nestes parâmetros. Após isso as credenciais de token são armazenadas em sessão, e osparâmetros de configuração do serviço que obtém os dados do perfil do proprietáriodo recurso autenticado são obtidos, para efetuar uma requisição POST que obtémos dados do perfil em JSON. Após obter os dados, os mesmos são convertidos a umobjeto do tipo stdClass do PHP, e são armazenados na sessão do componenteZend_Auth. Após todo o processo estar concluído, o usuário é redirecionado para atela principal da aplicação de finanças.public function callbackAction(){ $sessionToken = $this->_session->token; $get = $this->getRequest()->getQuery(); if (sizeof($get) > 0 && ! empty($sessionToken)) { $token = $this->_oauthConsumer->getAccessToken($get,unserialize($sessionToken)); $this->_session->accessToken = serialize($token); unset($this->_session->token); $userServiceConfig = $this->getInvokeArg(bootstrap)->getOption(userService); $httpClient = $token->getHttpClient($this->_oauthConfig); $httpClient->setUri($userServiceConfig[endpoint]); $httpClient->setMethod(Zend_Http_Client::POST); $response = $httpClient->request(); Zend_Auth::getInstance()->getStorage()->write(Zend_Json::decode($response->getBody(), Zend_Json::TYPE_OBJECT)->user); return $this->_helper->redirector(index, bills); } else { exit(Erro ao efetuar a autorização); }}Quadro 25: Método de Retorno do processo de autorizaçãoFonte: Autoria Própria Similarmente à aplicação de Agenda de Contatos, quando o processo deautorização for finalizado será apresentado ao usuário a tela principal da aplicação.Na aplicação de controle de contas esta tela é a apresentada na Figura 9.
  • 59 Figura 9: Tela inicial da aplicação de finanças Fonte: Autoria Própria Nesta tela é apresentado ao usuário o nome com que ele se autenticou e osdados de suas finanças, junto com um balanço calculado a partir da diferença entreos créditos e os débitos. Caso o resultado seja negativo o campo de saldo seráapresentado em vermelho. Caso seja positivo será apresentado em verde. Ao seacessar o botão “Adicionar Nova” o usuário poderá cadastrar um novo lançamentono formulário apresentado na Figura 10. Figura 10: Tela para adicionar um lançamento Fonte: Autoria Própria
  • 605 CONSIDERAÇÕES FINAIS A segurança de uma aplicação é um ponto crucial para garantir o sigilo dosdados dos usuários e para fornecer uma aplicação robusta e confiável. Ao secentralizar a base de dados de um usuário a algum protocolo que não exija que omesmo trafegue suas credenciais entre diversas aplicações, essa segurança é aindamaior, pois, principalmente, a segurança está centralizada em um único local. O protocolo OAuth fornece um meio de centralizar essa base de dados,utilizando as credenciais de token para fazer a comunicação entre autorização dosconsumidores autorizados pelo proprietário do recurso. Este protocolo é amplamenteutilizado no mercado, tendo como aplicações famosas o Twitter, Facebook,aplicativos do Google como Calendar e Gmail, além de outras grandes corporaçõesdo mercado. Um reflexo da fama do OAuth pôde ser percebido pela quantidade debibliotecas disponíveis, não só para as linguagens escolhidas no escopo dessetrabalho, mas para outras tecnologias como .NET, Python, Perl e outras. Com essasbibliotecas é possível ganhar produtividade no desenvolvimento de provedores econsumidores de OAuth, pois elas escondem toda a lógica principal da utilização doprotocolo e, além disso, fornecem meios fáceis e intuitivos para customizar outrasregras, como, por exemplo, a de expiração de tokens. Uma conclusão que também vale ressaltar é a de transparência para ousuário. Para o usuário, tudo que está acontecendo internamente pelas aplicaçõesnão têm suma importância, ele vê a tela de autenticação principal e centralizada, e afácil integração das aplicações com o provedor da autenticação. Além disso, ele temtotal controle sobre o que poderá acessar seus dados, e, além de esse controle,também os desenvolvedores e administradores podem gerenciar quaisconsumidores podem efetuar uma tentativa de utilização do provedor OAuth.5.1 TRABALHOS FUTUROS Os trabalhos futuros deste trabalho estão relacionados, principalmente, aadicionar novas funcionalidades à estrutura desenvolvida. Estas funcionalidades não
  • 61foram incluídas por fugirem do escopo do trabalho, porém são essenciais para umprovedor de autenticação OAuth. Dentre as principais melhorias, estão incluídas: • Adicionar os tokens gerados pelo framework Spring Security OAuth a um banco de dados, ao invés de uma fonte de dados volátil como a memória RAM. Isso pode ser implementado criando-se um novo serviço de tokens, que implemente a interface OAuthProviderTokenServices; • Após implementar o serviço de tokens mencionado acima, implementar um serviço de consumidores, permitindo que um administrador de sistema cadastre novas aplicações que podem tentar consumir dados dos proprietários de recursos capazes de se autenticar no sistema. Para isso é necessário implementar um novo serviço de consumidores, que implemente a interface ConsumerDetailsService; • Com estas duas melhorias implementadas, outro trabalho futuro é a capacidade de listar para o usuário as aplicações que o mesmo autorizou e, permitir que o mesmo possa revogar o acesso das aplicações cadastradas; • Outra melhoria é, ao revogar o acesso de uma aplicação, a capacidade de limpar os dados do usuário armazenados nessa aplicação, permitindo que a base de dados não fique inconsistente já que o proprietário do recurso não autoriza mais que o consumidor utilize seus dados. Essas melhorias estão relacionadas à aplicação desenvolvida aqui, porém,quando a versão 2.0 do Oauth, que até esta data encontra-se em rascunho, setornar uma especificação estável, uma melhoria importante é a atualização daestrutura para utilizar esta versão.
  • 62 REFERÊNCIASCORREIA, Miguel Pupo; SOUSA, Paulo Jorge. Segurança no Software. Lisboa:FCA – Editora de Informática, 2010.GIL, A. C. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas, 2002.GOURLEY, David; TOTTY, Brian. HTTP The Definitive Guide. Sebastopol: OReillyMedia, 2002.HIBERNATE. Hibernate Getting Started Guide. Disponível em:<http://docs.jboss.org/hibernate/core/3.6/quickstart/en-US/html/>. Acesso em 28 nov.2011.HOGAN, Brian P. HTML5 and CSS3 – Develop with Tomorrows StandardsToday. Dallas: Pragmatic Bookshelf, 2010.LEBLANC, Jonathan. Programming Social Applications. Sebastopol: OReillyMedia, 2011.MULARIEN, Peter. Spring Security 3: Secure your web applications againstmalicious intruders with this easy to follow practice guide. Birmingham: PacktPublishing, 2010.MYSQL. MySQL Documentation – General Information. Disponível em:<http://dev.mysql.com/doc/refman/5.5/en/introduction.html>. Acesso em 29 nov.2011.OAUTH. RFC 5849 - The OAuth 1.0 Protocol. Disponível em:<http://tools.ietf.org/html/rfc5849>. Acesso em 08 ago. 2011.PARRA, D. F.; SANTOS, J. A. Metodologia Científica. 4. ed. São Paulo: Futura,2002.PHP. PHP Manual. Disponível em: <http://www.php.net/manual/en>. Acesso em 28nov. 2011.
  • 63PLAY. Play Framework Overview. Disponível em:<http://www.playframework.org/documentation/1.2.3/overview>. Acesso em 28 nov.2011.SANKAR, Krishna; BOUCHARD, Susan A. Enterprise Web 2.0 Fundamentals.Indianapolis: Cisco Press, 2009.SPELL, Brett. Pro Java Programming, Second Edition. New York: Apress, 2005.SPRING. Spring Framework – Reference Documentation. Disponível em:<http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/overview.html>. Acesso em 28 nov. 2011.SPRINGOAUTH. Home of Spring OAuth. Disponível em:<https://github.com/SpringSource/spring-security-oauth/wiki>. Acesso em 28 nov.2011.WALLS, Craig. Spring in Action – Third Edition. Shelter Island: ManningPublications, 2011.ZEND. Zend Framework Introduction. Disponível em:<http://framework.zend.com/manual/en/introduction.overview.html>. Acesso em 28nov. 2011.