Estudo de Caso de uma Estrutura de Autenticao nica utilizando o protocolo OAuth

  • Published on
    13-May-2015

  • View
    15.008

  • Download
    8

DESCRIPTION

This monograph, developed in my post-graduation course in Universidade Tecnolgica 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

Transcript

  • 1.UNIVERSIDADE TECNOLGICA FEDERAL DO PARANPROGRAMA DE PS-GRADUAO EM TECNOLOGIA ESPECIALIZAO EM DESENVOLVIMENTO DE SISTEMAS BASEADOS EM OBJETOS PARA AMBIENTE INTERNETFERNANDO GERALDO MANTOANESTUDO DE CASO DE UMA ESTRUTURA DE AUTENTICAO NICA UTILIZANDO O PROTOCOLO OAUTH MONOGRAFIA DE ESPECIALIZAOMEDIANEIRA 2011

2. FERNANDO GERALDO MANTOANESTUDO DE CASO DE UMA ESTRUTURA DE AUTENTICAO NICA UTILIZANDO O PROTOCOLO OAUTH Trabalho de Concluso de Curso apresentado Universidade Tecnolgica Federal do Paran Cmpus Medianeira como requisito parcial obteno do grau de Especialista em Projeto e Desenvolvimento de Sistemas Baseados em Objetos para Ambiente Internet. Orientador: Prof. Esp. Diego de Carvalho MEDIANEIRA2011 3. Ministrio da EducaoUniversidade Tecnolgica Federal do Paran Diretoria de Pesquisa e Ps-Graduao Especializao em Projeto e Desenvolvimento de Sistemas baseados em Objetos para Ambiente InternetTERMO DE APROVAOEstudo de Caso de uma Estrutura de Autenticao nica utilizando o protocolo OAuthPor Fernando Geraldo Mantoan Esta monografia foi apresentada s 11:00h do dia 08 de dezembro de 2011como requisito parcial para a obteno do ttulo de ESPECIALISTA, no curso deEspecializao em Projeto e Desenvolvimento de Sistemas baseados em Objetospara Ambiente Internet, da Universidade Tecnolgica Federal do Paran, CmpusMedianeira. O acadmico foi arguido pela Banca Examinadora composta pelosprofessores abaixo assinados. Aps deliberao, a Banca Examinadora considerouo trabalho aprovado.Prof. Esp. Diego de CarvalhoProf. Me. Alan Gavioli Orientador Convidado UTFPR Cmpus Pato Branco UTFPR Cmpus Medianeira Prof. Dr. Hermes Irineu Del Monego Prof. Me. Fernando Schtz ConvidadoCoordenador do Curso de EspecializaoUTFPR Cmpus Medianeira UTFPR Cmpus Medianeira UTFPR DIRPPGAv. Brasil, 4232 Pq Independncia 85884000 Medianeira PRwww.utfpr.edu.br/medianeira+55(45) 3240-8074A FOLHA DE APROVAO ASSINADA ENCONTRA-SE NA DIRETORIA DE PS-GRADUAO DA UTFPRCMPUS MEDIANEIRA 4. AGRADECIMENTOSPrimeiramente a Deus, por sempre me iluminar e ser o meu apoio nas horas maisdifceis. minha namorada Aline Regina Marzurkiewicz e aos meus pais, pelo incentivo,pelo apoio, pelo amor e carinho, pela compreenso, por sempre me cobrarem e pela foraque sempre me deram.Ao meu orientador, professor Diego de Carvalho, por toda assistncia, pelo apoio,pelas idias, pela pacincia, e por sempre me ajudar, mesmo no estando presentefisicamente.Agradeo aos meus amigos e colegas, pelos momentos de discusso, estudo ediverso. 5. A coisa mais bonita que podemos experimentar omistrio. Ele a fonte de toda a verdadeira arte ecincia.Albert Einstein 6. RESUMOMANTOAN, Fernando Geraldo. Estudo de caso de uma estrutura de autenticao nicautilizando o protocolo OAuth. 56 f. Monografia (Especializao em Projeto eDesenvolvimento de Sistemas Baseados em Objetos para Ambiente Internet) Programade Ps-graduao em Tecnologia, Universidade Tecnolgica Federal do Paran.Medianeira, 2011.O presente trabalho tem como principal objetivo apresentar um estudo de caso de umaestrutura de autenticao nica utilizando o protocolo OAuth. Com este protocolo omodelo tradicional de autenticao cliente-servidor ganha um terceiro papel que o deproprietrio do recurso, um usurio com credenciais vlidas no provedor OAuthresponsvel por permitir ou negar acesso de consumidores aos seus dados pessoais.Tambm feito um estudo sobre conceitos de segurana, apresentao das tecnologiasutilizadas no estudo de caso, e toda a parte de implementao, composta por umprovedor OAuthe duas aplicaes consumidoras, utilizada para verificar asfuncionalidades do OAuth.Palavras-chave: Segurana, Spring Framework, Java, Play Framework, PHP, ZendFramework. 7. ABSTRACTMANTOAN, Fernando Geraldo. Case study of a structure of single sign on with the OAuthprotocol. 56 f. Monografia (Especializao em Projeto e Desenvolvimento de SistemasBaseados em Objetos para Ambiente Internet) Programa de Ps-graduao emTecnologia, Universidade Tecnolgica 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. 8. LISTA DE FIGURASFIGURA 1: TELA DE AUTORIZAO DO TWITTER.........................................................34FIGURA 2: TELA DE AUTORIZAO DO YAHOO!............................................................35FIGURA 3: ARQUITETURA DEFINIDA...............................................................................44FIGURA 4: TELA DE AUTENTICAO...............................................................................49FIGURA 5: TELA DE AUTORIZAO.................................................................................52FIGURA 6: TELA DE ACESSO REVOGADO......................................................................52FIGURA 7: TELA INICIAL DA APLICAO DE CONTATOS..............................................55FIGURA 8: TELA PARA ADICIONAR UM CONTATO..........................................................55FIGURA 9: TELA INICIAL DA APLICAO DE FINANAS................................................59FIGURA 10: TELA PARA ADICIONAR UM LANAMENTO................................................59 9. LISTA DE SIGLASAPI Application Programming InterfaceAOP Aspect Oriented ProgrammingCAS Central Authentication ServiceCSS Cascading Style SheetsHTMLHyperText Markup LanguageHTTPHyperText Transfer ProtocolHTTPS HyperText Transfer Protocol SecureIoC Inversion of ControlJ2EEJava 2 Platform Enterprise EditionJ2MEJava 2 Platform Micro EditionJ2SEJava 2 Platform Standard EditionJPA Java Persistence APIJVM Java Virtual MachineMVC Model View ControllerOAUTH Open AuthenticationORM Object Relational MapperPHP Hypertext PreprocessorRESTRepresentational 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 10. SUMRIO1 INTRODUO..................................................................................................................121.1 JUSTIFICATIVA..............................................................................................................121.2 OBJETIVOS...................................................................................................................131.2.1 Objetivo Geral.............................................................................................................131.2.2 Objetivos Especficos..................................................................................................132 FUNDAMENTAO TERICA........................................................................................142.1 SEGURANA................................................................................................................142.2 AUTENTICAO...........................................................................................................152.3 AUTORIZAO.............................................................................................................152.4 CLOUD COMPUTING...................................................................................................162.5 HTTP..............................................................................................................................162.5.1 URIs............................................................................................................................172.5.2 URLs...........................................................................................................................172.5.3 Transaes..................................................................................................................182.5.4 Mtodos......................................................................................................................182.5.5 Cdigos de Estado......................................................................................................192.5.6 Mensagens..................................................................................................................192.6 OPENID.........................................................................................................................202.6.1 Fluxo de Autenticao.................................................................................................212.7 CAS................................................................................................................................212.7.1 Fluxo de Autenticao.................................................................................................222.8 OAUTH...........................................................................................................................232.8.1 Terminologia................................................................................................................232.8.2 Benefcios...................................................................................................................242.8.3 Funcionamento...........................................................................................................252.8.4 Credenciais Temporrias............................................................................................262.8.5 Autorizao do proprietrio do recurso.......................................................................272.8.6 Credenciais de Token.................................................................................................292.8.7 Requisies Autenticadas...........................................................................................302.8.8 Experincia do Usurio...............................................................................................333 PROCEDIMENTOS METODOLGICOS.........................................................................363.1 PROCEDIMENTOS DE PESQUISA..............................................................................363.1.1 Tipo de Pesquisa........................................................................................................363.2 ESTRUTURA FSICA.....................................................................................................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 TECNOLGICAS.............................................................................414 IMPLEMENTAO...........................................................................................................434.1 SERVIDOR DE AUTENTICAO.................................................................................434.1.1 Configurao do Spring Security e OAuth..................................................................444.1.2 Autenticao de Usurios...........................................................................................474.1.3 Confirmao do Proprietrio do Recurso...................................................................49 11. 4.2 APLICAO 1: AGENDA DE CONTATOS....................................................................524.3 APLICAO 2: CONTROLE DE FINANAS................................................................565 CONSIDERAES FINAIS.............................................................................................605.1 TRABALHOS FUTUROS...............................................................................................60REFERNCIAS...................................................................................................................62 12. 121 INTRODUOAplicaes no geral possuem a necessidade comum de restringir o acessoaos seus recursos utilizando meios de segurana como, por exemplo, autenticaode usurios. Comumente, cada aplicao fornece uma fonte de dados paraarmazenar informaes de usurios do software e, utilizando estas fontes de dados,fornece restrio baseada em credenciais de acesso (usurio e senha por exemplo).No modelo tradicional de autenticao cliente-servidor, o cliente usa suascredenciais para acessar os recursos hospedados pelo servidor. Com o advento douso de web services distribudos e de cloud computing, aplicaes de terceirosprecisam acessar estes recursos hospedados pelo servidor. (OAUTH, 2010)O protocolo OAuth introduz um terceiro papel no modelo tradicional deautenticao cliente-servidor: o resource owner (proprietrio do recurso). No modeloOAuth, o cliente (que no o proprietrio do recurso, mas est atuando como um)requisita acesso a recursos controlados pelo proprietrio, mas hospedados noservidor. Alm disso, o OAuth permite que o servidor verifique no apenas aautorizao do proprietrio do recurso, mas tambm a identidade do cliente que estfazendo a requisio. (OAUTH, 2010)A proposta deste trabalho fazer um estudo sobre o protocolo OAuth,destacando os princpios pelos quais ele foi elaborado, seu funcionamento,utilizao no mercado e aspectos principais. Ser implementada uma estruturabsica de autenticao nica, com a definio de uma arquitetura para a parte deautenticao utilizando o protocolo OAuth, e duas mini-aplicaes, que utilizam aestrutura de autenticao desenvolvida, permitindo ou negando acesso aos recursosdisponibilizados, de acordo com cada uma das aplicaes.1.1 JUSTIFICATIVACom o advento do uso de web services distribudos e de cloud computing,aplicaes de terceiro precisam acessar estes recursos hospedados pelo servidor,fugindo do modelo tradicional de autenticao entre cliente e servidor. (OAUTH,2010) 13. 13O protocolo OAuth fornece um mtodo para que clientes acessem recursosdo servidor em nome de um proprietrio do recurso. Com ele tambm possvelfornecer um processo para usurios finais autorizarem acesso de terceiros aosrecursos de seus servidores sem compartilhar suas credenciais (como o conjuntousurio/senha), usando redirecionamento de seus agentes de usurios. (OAUTH,2010)1.2 OBJETIVOS1.2.1 Objetivo GeralPropor uma estrutura para fornecer autenticao nica com o protocoloOAuth na plataforma Java, e implementar duas mini-aplicaes que utilizem estaestrutura de autenticao, sendo elas de plataformas de programao diferentes.1.2.2 Objetivos Especficos Explicar os conceitos de segurana; Explanar o protocolo OAuth, seguindo sua especificao e apresentar sua utilizao no mercado; Apresentar as tecnologias utilizadas no desenvolvimento das aplicaes; Implementar uma aplicao que fornea autenticao nica utilizando o protocolo OAuth; Realizar um estudo de caso, elaborando duas aplicaes que se autenticam utilizando a estrutura OAuth implementada. 14. 142 FUNDAMENTAO TERICANeste captulo apresentada toda a fundamentao terica levantadadurante a anlise bibliogrfica dos principais conceitos necessrios para o estudodeste trabalho. Sero abordados os principais aspectos sobre segurana,autorizao, autenticao, cloud computing, o protocolo HTTP, alguns protocolos deautenticao similares ao OAuth (OpenID e CAS) e os principais conceitosfornecidos pela especificao do protocolo OAuth.2.1 SEGURANASegurana sem dvida um dos componentes arquiteturais mais crticos dequalquer aplicao baseada na web escrita no sculo vinte e um. Em uma era ondemalwares, crimonosos, e funcionrios mal intencionados esto sempre presentes eativamente testando falhas de software, o uso inteligente e abrangente de segurana um elemento chave para novos projetos a serem desenvolvidos. (MULARIEN,2010)O objetivo da segurana consiste em garantir um conjunto de trs atributos:confidencialidade, integridade e disponibilidade. A confidencialidade a ausnciade divulgao no autorizada de contedo. A integridade a ausncia dealteraes no autorizadas ao sistema ou informao. A disponibilidade aprontido do servio fornecido ou da informao. Alm das trs, comumenteadicionada a autenticidade, que a medida em que a informao ou o serviofornecido so genunos. (CORREIA; SOUSA, 2010)Um dos principais conceitos na segurana desoftware o devulnerabilidades, que um defeito relevante no sistema que pode ser explorado porum atacante com o objetivo de subverter sua poltica de segurana. Existem trstipos de vulnerabilidades, podendo ser uma vulnerabilidade de projeto, que introduzida durante o projeto do sistema; vulnerabilidade de codificao que introduzida durante a codificao e resulta em bugs de segurana; e avulnerabilidade operacional, causada pelo ambiente onde o sistema executadoou por sua configurao. (CORREIA; SOUSA, 2010) 15. 152.2 AUTENTICAOAutenticao um dos dois conceitos chave que deve ser implementado aose desenvolver aplicaes seguras. A autenticao lida com a identificaoespecfica de um usurio do sistema, e com o mapeamento deste usurio para umaentidade identificvel (e, portanto, protegida). Tipicamente, um software est divididoem dois domnios de alto nvel como annimo e autenticado. (MULARIEN, 2010)As funcionalidades da aplicao para o domnio annimo so independentesde uma identificao de usurio, como por exemplo, uma listagem de produtos emum site de comrcio eletrnico. As sees que permitem acesso annimo norequerem a autenticao do usurio para sua utilizao, no exibem informaesconfidenciais como nomes e cartes de crditos, e no fornecem meios paramanipulao geral do sistema ou de seus dados. (MULARIEN, 2010)2.3 AUTORIZAOAutorizao o segundo dos dois principais conceitos de segurana cruciaisna implementao e compreenso de segurana de aplicaes. Autorizao lidacom a disponibilidade adequada de funcionalidades e dados para usurios queesto autorizados para acess-los. Construdo em torno do modelo de autorizaopara a aplicao est a atividade de particionar as funcionalidades e os dados daaplicao de tal forma que a disponibilidade destes itens possam ser controlados poruma combinao de privilgios, funcionalidades e dados, e usurios. (MULARIEN,2010)O processo de autorizao tipicamente envolve dois aspectos separadosque se combinam para descrever a acessibilidade do sistema seguro. O primeiro omapeamento de um usurio autenticado para um ou mais papis, por exemplo opapel de administrador do sistema ou o papel de visitante. O segundo aspecto aatribuio das checagens de autoridade para os recursos protegidos do sistema, oque tipicamente feito durante o desenvolvimento do sistema, atravs dedeclarao explcita no cdigo ou por meios de configurao. Um recurso protegidopode ser uma funcionalidade do sistema, como, por exemplo, gerenciamento deprodutos. (MULARIEN, 2010) 16. 162.4 CLOUD COMPUTINGCloud Computing (computao na nuvem) um fenmeno recente queimpacta na forma com que infra-estruturas so arquitetadas, compradas eimplantadas. No modelo de computao na nuvem, computao e infra-estruturasde armazenamento esto disponveis para uso como um utilitrio e no apenasdentro de uma infra-estrutura prpria. O modelo de utilitrio estende-se a partir deapenas um hardware de computador de plataforma de servios para aplicativoscompletos como um servio externo. (SANKAR; BOUCHARD, 2009)Computao na nuvem uma otimizao ttica assim como um artefatoarquitetural estratgico. uma otimizao ttica, porque ao se ter aplicaes ad-hocque precisam funcionar em um curto perodo de tempo (como uma enquete oualguma pesquisa) possvel execut-la em uma infra-estrutura de nuvem, como, porexemplo, o Amazon Elastic Compute Cloud. Mas tambm estratgica porqueagora os acionistas de empresa (e envolvidos em TI) podem trabalhar alm daslimitaes de largura de banda finita de computao e otimizar os sistemas ativos auma era de poder de processamento infinito, que flexvel. (SANKAR; BOUCHARD,2009)Uma nuvem um conjunto de solues escalveis, com infra-estruturaabstrata que hospeda aplicaes 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 pblica. A deciso de se utilizar a nuvemprivada ou pblica para um aplicativo determinada por polticas, conformidade eregulamentos relevantes para uma organizao, bem como as condies devisibilidade e controle de uma empresa comparado com os recursos fornecidos porum provedor de nuvem pblico. (SANKAR; BOUCHARD, 2009)2.5 HTTPTodos os navegadores de internet, servidores, e aplicaes webrelacionadas se comunicam entre si atravs do Hypertext Transfer Protocol (HTTP), 17. 17que uma linguagem comum da Internet mundial moderna. (GOURLEY; TOTTY,2002)O contedo da web reside em servidores web, que falam o protocolo HTTP,dessa forma sendo comumente chamados de servidores HTTP. Estes servidoresfornecem os dados quando so 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 bsicos da WorldWide Web (WWW). (GOURLEY; TOTTY, 2002)O protocolo HTTP possui diversos blocos necessrios 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), transaes, mtodos, cdigos de estado e mensagens.2.5.1 URIsCada recurso de um servidor web tem um nome, assim clientes podemapontar quais recursos eles esto interessados em acessar. O nome do recurso deservidor chamado de Unified Resource Identifier (URI), em portugus Identificadornico de Recurso. URIs so como os endereos postais da Internet, identificandoexclusivamente e localizando informao 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 URLsO Uniform Resource Locator (URL) a forma mais comum de umidentificador de recurso. URLs descrevem a localizao especfica de um recursoem um servidor particular. Elas descrevem exatamente como obter um recurso deuma localizao precisa e fixa. (GOURLEY; TOTTY, 2002)De acordo com Gourley e Totty (2002) muitas URLs seguem um formato 18. 18padronizado de trs 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 endereo 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 Transaes Uma transao HTTP consiste em um comando de pedido (enviado docliente ao servidor), e um resultado de resposta (enviado de volta ao cliente). Estacomunicao acontece com blocos formatados de dados chamados de mensagensHTTP. (GOURLEY; TOTTY, 2002)2.5.4 Mtodos O protocolo HTTP suporta diferentes comandos de pedido, chamados demtodos HTTP. Cada mensagem de pedido HTTP possui um mtodo, que diz aoservidor qual ao deve ser executada (obter uma pgina, executar um programa,excluir um arquivo, etc). O Quadro 2 lista os cinco mtodos HTTP comuns.(GOURLEY; TOTTY, 2002)MtodoDescrioGET Envia um recurso nomeado do servidor ao cliente.PUT Armazena dados de um cliente em um recurso nomeado do servidor.DELETEExclui o recurso nomeado de um servidor.POSTEnvia dados do cliente a uma aplicao servidora de gateway.HEADEnvia apenas os cabealhos HTTP da resposta para o recurso nomeado.Quadro 2: Mtodos HTTPFonte: Gourley e Totty (2002) 19. 192.5.5 Cdigos de EstadoCada mensagem de resposta HTTP retorna com um cdigo de estado. Ocdigo de estado um nmero de trs dgitos que diz ao cliente se o pedido foiexecutado com sucesso, ou se outras aes so necessrias. O HTTP tambmenvia uma explicao textual com cada cdigo numrico, que inclusa apenas parafins descritivos; e o cdigo numrico utilizado para todo o processamento. Algunscdigos de estado comuns so apresentados no Quadro 3. (GOURLEY; TOTTY,2002) Cdigo de EstadoDescrio200OK. Documento retornado com sucesso.302Redirect. Redireciona o usurio para outro lugar para obter o recurso.404Not Found. No foi possvel encontrar este recurso.Quadro 3: Cdigos de EstadoFonte: Gourley e Totty (2002)2.5.6 MensagensMensagens HTTP so simples sequncias de caracteres orientadas porlinha. Devido ao fato de serem texto simples, no binrios, eles so fceis paraseres humanos lerem e escreverem. Mensagens HTTP enviadas de clientes webaos servidores so denominados mensagens de pedido. Mensagens de servidores aclientes so chamados de mensagens de resposta. No 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 trspartes:Linha de incio: A primeira linha da mensagem a linha de incio, indicandoo que fazer para um pedido e o que aconteceu para um recurso;Campos de cabealho: Nenhum ou muitos campos de cabealho seguem alinha de incio. Cada campo de cabealho consiste de um nome e um valor,separados pelo caractere dois pontos (:) para facilitar a leitura. Os cabealhosterminam com uma linha em branco;Corpo: Aps a linha branca existe um corpo de mensagem opcional 20. 20contendo qualquer tipo de dado. Corpos de pedido carregam dados para o servidorweb; corpos de resposta carregam dados para o cliente. Diferentemente da linha deincio e dos cabealhos, que so textuais e estruturados, o corpo pode conter dadosbinrios arbitrrios (por exemplo, imagens, vdeos etc.), assim como podem contertexto simples.2.6 OPENIDOpenID fornece sites e servios com um protocolo descentralizado deautenticao de usurios atravs de uma ampla variedade de provedores. Issosignifica que um site integrando OpenID pode permitir que seus usurios seautentiquem utilizando, por exemplo, suas contas do Yahoo!, Google ou AOL. O siteem questo pode no apenas evitar a criao de seu prprio sistema deautenticao, mas tambm pode tirar vantagem das contas que seus usurios jpossuem, aumentando assim o registro de usurios e as taxas de autenticao.(LEBLANC, 2011)Alm da autenticao simples, o OpenID tambm oferece diversasextenses atravs do qual um provedor de OpenID pode permitir que as aplicaesobtenham informaes do perfil de um usurio ou integrar camadas adicionais desegurana para o procedimento de autenticao. (LEBLANC, 2011)O fator mais interessante do OpenID o de que ele oferece um padro que totalmente descentralizado dos provedores e dos consumidores. Este aspecto oque d a um site consumidor simples a possibilidade de autenticao a partir decontas do Yahoo! e Google, enquanto outro site pode querer que seus usurios seautentiquem atravs do Blogger ou Wordpress. Cabe ao consumidor OpenID (umsite ou servio) escolher quais mtodos de autenticao ele gostaria de oferecer aosseus usurios. (LEBLANC, 2011)Cada provedor de OpenID possui um endereo de OpenID associado comseu sistema de autenticao para habilitar o mtodo de descoberta requirido para oprocesso de autenticao. Existem diversos provedores de OpenID, entre osprincipais esto o Google, Yahoo!, Flickr, Wordpress, AOL, Blogger, MySpace,MyOpenID entre outros. (LEBLANC, 2011) 21. 212.6.1 Fluxo de Autenticao Segundo Leblanc (2011) o OpenID define um fluxo padronizado pelo qualum usurio pode se autenticar em um site de terceiro de retransmisso de umprovedor de OpenID como Yahoo! ou Google. Existem trs participantes no fluxo deautenticao do OpenID: O usurio: Usurio final que est tentando se autenticar em um site ou servio utilizando um dos provedores de OpenID; Partido confivel: Site consumidor de OpenID, que implementa um processo de autenticao de um provedor de OpenID, para permitir aos usurios a autenticao com suas contas; O provedor de OpenID: Site ou servio que possui o banco de dados de membros que o partido confivel se autenticar e atravs do qual o usurio ir fornecer seus dados de acesso. O processo de autenticao do OpenID necessita de quatro passosdiferentes, iniciando quando o usurio escolhe um provedor para se autenticar eterminando com o resultado de sucesso/falha do provedor quando o usurio tenta seautenticar. No primeiro passo solicitada a autenticao do usurio, passando umaURI identificadora de OpenID. No segundo passo feita a descoberta do endpointdo OpenID. No terceiro passo solicitado ao usurio que o mesmo se autentiquecom sua conta. E finalmente, no quarto passo, fornecido um estado desucesso/falha baseado na autenticao. (LEBLANC, 2011)2.7 CAS Central Authentication Service (CAS) um portal de autenticao nica decdigo aberto, que fornece controle de acesso centralizado, e autenticao pararecursos baseados na web dentro de uma organizao. Mularien (2010) destaca queos principais benefcios do CAS so: O acesso individual ou em grupo a recursos (aplicaes) pode ser configurado em um nico local; Suporte a uma ampla variedade de locais de autenticao (para centralizar a gesto de usurios), fornecendo um ponto nico de autenticao e 22. 22 controle para um amplo ambiente multi-mquina; O suporte amplo de autenticao fornecido por aplicaes Java baseadas ou no baseadas na web atravs de bibliotecas de clientes CAS; Um nico ponto de referncia para credenciais de usurio (atravs de CAS), para que aplicaes clientes CAS no necessitam saber nada sobre as credenciais do usurio, ou como verificar elas.2.7.1 Fluxo de Autenticao Segundo Mularien (2010), o fluxo bsico de autenticao do CAS executado atravs das seguintes aes: Primeiramente o usurio tenta acessar um recurso protegido de uma aplicao; O usurio redirecionado para o portal CAS atravs do mecanismo de segurana da aplicao, para fornecer suas credenciais; O portal CAS responsvel pela autenticao do usurio. Se o usurio for autenticado com sucesso no CAS, ele redirecionado para o recurso protegido com um ticket CAS nico definido na requisio; O mecanismo de segurana da aplicao chama novamente o servidor CAS para validar se o ticket aceitvel ( vlido, no est expirado, etc). O servidor CAS responde com uma afirmao indicando que a confiana foi estabelecida. Caso o ticket seja aceitvel, a confiana foi estabelecida e o usurio pode proceder atravs de checagem de autorizao comum. Com este fluxo possvel visualizar que existe uma grande interao entre oservidor CAS e a aplicao segurada, com a necessidade de bastante troca dedados antes que a confiana do usurio possa ser estabelecida. O resultado destacomplexidade um protocolo de autenticao nica que difcil para falsificaratravs de tcnicas comuns (assumindo que outras precaues de segurana foramtomadas, como o uso de Secure Sockets Layer e monitorao de rede).(MULARIEN, 2010) 23. 232.8 OAUTHOpen Authentication (OAuth), um padro aberto para autorizao deaplicaes para acessar dados em nome de um usurio. Atravs do OAuth, possvel proteger informaes pessoais de um usurio. 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 delegao de acesso a recursos protegidos. O protocolo OAuthresultante foi estabilizado na verso 1.0 em Outubro de 2007, e revisado em Junhode 2009 (Reviso A), conforme publicado online. (OAUTH, 2010)O protocolo OAuth fornece um mtodo para que clientes acessem recursosdo servidor em nome de um resource owner (dono de recursos). Tambm possvelfornecer um processo para usurios finais autorizarem acesso de terceiros aosrecursos de seus servidores sem compartilhar suas credenciais (como, por exemplo,usurio/senha), usando redirecionamento de seus agentes de usurios. (OAUTH,2010)Para que o cliente acesse recursos do servidor, ele primeiramente precisaobter permisso do dono de recursos. Essa permisso expressada na forma deum token e de uma chave secreta correspondente. O objetivo do token fazer comque no 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 TerminologiaO protocolo OAuth apresenta diversos conceitos com um significadoparticular para seu contexto, conforme apresentado abaixo:Cliente: Um cliente HTTP capaz de fazer requisies OAuth autenticadas.(OAUTH, 2010)Servidor: Um servidor HTTP capaz de aceitar requisies OAuth 24. 24autenticadas. (OAUTH, 2010)Recurso protegido: Um recurso de acesso restrito que pode ser obtido deum servidor utilizando uma requisio OAuth autenticada. (OAUTH, 2010)Proprietrio do recurso: Uma entidade capaz de acessar e controlarrecursos protegidos utilizando credenciais para se autenticar no servidor. (OAUTH,2010)Credenciais: Credenciais so um par composto de um identificador nico eum segredo correspondente compartilhado. O OAuth define trs classes decredenciais: cliente, temporrio e token, usados, respectivamente, para identificar eautenticar o cliente que est fazendo a requisio, a requisio de autorizao, e aconcesso do acesso. (OAUTH, 2010)Token: Um identificador nico emitido pelo servidor e usado pelo clientepara associar requisies autenticadas com o proprietrio do recurso cujaautorizao 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 proprietriodo recurso. (OAUTH, 2010)2.8.2 BenefciosSegundo Leblanc (2011, p. 319) o protocolo OAuth oferece algumasmelhorias sobre os modelos tradicionais de autenticao, incluindo: Ao invs de ter que enviar o nome de usurio e senha ao servidor comcada requisio de autenticao, possvel trabalhar com tokens deacesso abstratos que no compartilham nenhuma das senhas do usurio; Como tokens so emitidos a partir de um servidor, eles podem serrevogados a qualquer momento, colocando mais controle nas mos dousurio. Diversos provedores tambm implementam um mecanismo deexpirao de tokens, que requerem que uma aplicao periodicamenterenove o token de acesso para continuar executando requisies de dadosdos usurios; Usurios podem ver os tokens que eles possuem ativos (isto , quais 25. 25aplicaes podem acessar seus dados) no site do provedor, significandoque eles podem manualmente revogar o acesso de uma aplicao. J quea aplicao no possui as credenciais de autenticao do usurio, ela nopode fazer mais requisies de dados uma vez que o usurio revogue aautorizao da aplicao.2.8.3 FuncionamentoO OAuth utiliza tokens para representar a autorizao garantida ao clientepelo proprietrio de recurso. Tipicamente, credenciais de token so emitidos peloservidor na requisio do proprietrio de recurso, aps a autenticao da identidadedo proprietrio de recurso (comumente utilizando um nome de usurio 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 usurio do proprietrio de recurso. Este redirecionamento inclui trsetapas:1. O cliente obtm um conjunto de credenciais temporrias do servidor (na forma de um identificador e uma chave secreta compartilhada). As credenciais temporrias so utilizadas para identificar o pedido de acesso em todo o processo de autorizao;2. O proprietrio de recurso autoriza o pedido de acesso do cliente no servidor (identificado pelas credenciais temporrias);3. O cliente utiliza as credenciais temporrias para requisitar um conjunto de credenciais de token do servidor, que lhe permitir acessar recursos protegidos do proprietrio de recurso.O servidor deve revogar as credenciais temporrias aps elas seremutilizadas para obter as credenciais de token. recomendado que as credenciaistemporrias tenham um tempo de vida limitado. Servidores devem permitir que osproprietrios de recursos possam revogar as credenciais de token aps elas serememitidas aos clientes. (OAUTH, 2010)De acordo com OAuth (2010, p. 8), para permitir que o cliente execute astrs etapas, o servidor deve anunciar os endereos dos seguintes endpoints: 26. 26Pedido de Credencial Temporria: O endpoint utilizado pelo cliente paraobter um conjunto de credenciais temporrias.Autorizao do Proprietrio do Recurso: Endpoint onde o proprietrio dorecurso redirecionado para garantir a autorizao.Pedido de Token: O endpoint utilizado pelo cliente para requisitar umconjunto de credenciais de token utilizando as credenciais temporrias.2.8.4 Credenciais TemporriasO cliente obtm um conjunto de credenciais temporrias do servidor fazendopedido HTTP POST autenticado para o endpoint de Pedido de CredencialTemporrio. O cliente constri uma URI de pedido adicionando o parmetroobrigatrio oauth_callback, que define um endereo para o qual o servidorredirecionar o proprietrio de recurso aps o processo de autorizao doproprietrio do recurso estar completo. (OAUTH, 2010)Ao fazer o pedido, o cliente se autentica utilizando apenas suas credenciais.O cliente pode omitir o parmetro vazio de protocolo oauth_token da requisio edeve utilizar a string vazia como o valor secreto do token. (OAUTH, 2010)Uma vez que o pedido resulta na transmisso 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 protees equivalentes). (OAUTH,2010)O servidor deve verificar o pedido e se for vlido, responder ao cliente comum conjunto de credenciais temporrias (na forma de um identificador e um segredocompartilhado). As credenciais temporrias so includas no corpo da respostaHTTP utilizando o tipo de contedo application/x-www-form-urlencoded com umcdigo de estado 200, que significa sucesso na requisio. (OAUTH, 2010)Segundo OAuth (2010) a resposta contm os seguintes parmetrosobrigatrios: oauth_token: O identificador de credenciais temporrias; oauth_token_secret:Osegredocompartilhado de credenciaistemporrias; 27. 27 oauth_callback_confirmed: Deve estar presente e definido como true.Este parmetro utilizado para diferenciar de verses antigas doprotocolo.Note que mesmo que o parmetro inclua o termo token, essas credenciaisno so as credenciais de token, mas so utilizadas nas prximas duas etapas deuma maneira similar s credenciais de token. O Quadro 4 contm um exemplo deresposta HTTP de credenciais temporrias. (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 TemporriasFonte: OAuth (2010)2.8.5 Autorizao do proprietrio do recursoAntes do cliente solicitar o conjunto de credenciais de token doservidor, ele deve enviar o usurio ao servidor para autorizar a requisio. O clienteconstri uma URI de pedido para o endpoint de Autorizao do proprietrio dorecurso, adicionando o parmetro obrigatrio oauth_token, que contm oidentificador de credenciais temporrias, obtido na etapa anterior no parmetrooauth_token da resposta. (OAUTH, 2010)O cliente direciona o proprietrio de recursos para a URI construdautilizando uma resposta HTTP de redirecionamento, ou outros meios disponveisutilizando o agente de usurio do proprietrio de recursos. A requisio deve utilizaro mtodo HTTP GET. (OAUTH, 2010)Por exemplo, o cliente redireciona o agente de usurio do proprietrio 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 autorizaoFonte: OAuth (2010)Independente da maneira na qual o servidor processa o pedido de 28. 28autorizao, incluindo ou no um canal seguro, o servidor sempre dever verificarprimeiramente a identidade do proprietrio do recurso.Ao pedir para o proprietrio de recurso para autorizar o pedido de acesso, oservidor deve apresentar ao proprietrio de recurso informaes sobre o cliente queest solicitando o acesso baseado na associao das credenciais de acessotemporrias com a identidade do cliente. Ao exibir qualquer uma dessasinformaes, o servidor deve indicar se as informaes foram verificadas.Aps receber uma deciso de autorizao do proprietrio do recurso, oservidor redireciona o usurio para o endereo de retorno, caso algum tenha sidoinformado no parmetro oauth_callback ou por outros meios.Para garantir que o proprietrio de recurso que est concedendo o acesso o mesmo proprietrio de recurso que est retornando de volta ao cliente paracompletar o processo, o servidor deve gerar um cdigo de verificao: um valor noadivinhvel passado para o cliente atravs do proprietrio de recurso e obrigatriopara concluir o processo. O servidor constri uma URI de solicitao adicionando osseguintes parmetros obrigatrios para o endereo de retorno:oauth_token: O identificador de credenciais temporrias recebido do cliente;oauth_verifier: O cdigo de verificao.O endereo de retorno j possui um componente de consulta, o servidordeve acrescentar os parmetros do OAuth no final da consulta existente. Porexemplo, o servidor redireciona o agente de usurio do proprietrio do recurso paraefetuar a seguinte requisio HTTP:GET /cb?x=1&oauth_token=hdk48Djdsa&oauth_verifier=473f82d3 HTTP/1.1Host: client.example.netQuadro 6: Redirecionamento para o endereo de retorno com parmetros do OauthFonte: OAuth (2010)Se o cliente no forneceu um endereo de retorno, o servidor deve exibir ovalor do cdigo de configurao, e instruir o proprietrio de recurso para informarmanualmente o cliente que a autorizao est completa. Se o servidor conhece umcliente que est rodando em um dispositivo limitado, ele deve garantir que o valor deverificao acessvel para o registro manual. 29. 292.8.6 Credenciais de TokenO cliente obtm um conjunto de credenciais de token do servidor fazendoum pedido HTTP POST autenticado para o endpoint de Pedido de token. O clienteconstri uma URI de pedido adicionando o seguinte parmetro obrigatrio:oauth_verifier: Cdigo de verificao recebido do servidor no passoanterior.Ao efetuar o pedido, o cliente faz a autenticao utilizando suas credenciais(identificadores do cliente) assim como as credenciais temporrias. As credenciaistemporrias so utilizadas como um substituto para as credenciais de token nopedido autenticado e transmitidas utilizando o parmetro oauth_token.Uma vez que o pedido resulta na transmisso 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 protees 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 proprietrio dorecurso autorizou o fornecimento de credenciais de token ao cliente, e garantir queas credenciais temporrias no foram expiradas ou usadas anteriormente. Oservidor deve verificar tambm o cdigo de verificao recebido do cliente. Se opedido vlido e autorizado, as credenciais de token so includas no corpo daresposta HTTP utilizando o tipo de contedo "application/x-www-form-urlencoded"com um cdigo de estado 200 (OK).A resposta contm os seguintes parmetros obrigatrios, e um exemplo deresposta contendo credenciais de token apresentado no Quadro 8: 30. 30oauth_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, durao e outros atributos aprovados peloproprietrio de recurso, e reforar essas restries ao receber uma requisio 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 proprietrio de recursofazendo requisies autenticadas utilizando as credenciais de cliente em conjuntocom as credenciais de token recebidas.2.8.7 Requisies AutenticadasAlguns mtodos especiais do protocolo HTTP permitem que clientes faamrequisies autenticadas, permitindo que eles ganhem acesso a recursos protegidosutilizando suas credenciais (tipicamente o par usurio/senha), que permitem que oservidor verifique a autenticidade dos mesmos. Utilizar estes mtodos paradelegao exige que o cliente assuma o papel do proprietrio do recurso. (OAUTH,2010)O OAuth fornece um mtodo projetado para incluir dois conjuntos decredenciais com cada requisio, um para identificar o cliente e outro para identificaro proprietrio do recurso. Antes do cliente ter permisso para fazer uma requisioautenticada em nome do proprietrio do recurso, ele deve obter um token autorizadopelo proprietrio do recurso, seguindo o mtodo explicado nas sees 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 requisiesautenticadas, o cliente estabelece esse conjunto de credenciais com o servidor. Oprocesso e os requisitos para prover essas credenciais variam de acordo com o 31. 31implementador do protocolo. (OAUTH, 2010) De acordo com a especificao de OAuth (2010), uma requisioautenticada inclui diversos parmetros do protocolo. Cada nome de parmetro iniciacom o prefixo oauth_, e os nomes e valores dos parmetros so sensveis caixa.Clientes fazem requisies autenticadas calculando os valores de um conjunto deparmetros de protocolo e adicionando-os requisio HTTP da seguinte forma: 1. O cliente define o valor de cada um dos seguintes parmetros deprotocolo: oauth_consumer_key: A poro de identificao das credenciais docliente (equivalente ao nome de usurio). O nome do parmetro refleteum termo depreciado (Chave do Consumidor) utilizado nas revisesda especificao, e mantido para manter compatibilidade. oauth_token: O valor de token utilizado para associar o pedido com oproprietrio do recurso. Se o pedido no est associado a umproprietrio do recurso (nenhum token disponvel), os clientes devemomitir o parmetro. oauth_signature_method: O nome do mtodo de assinatura utilizadopelo cliente para assinar o pedido. oauth_timestamp: Valor de estampa de tempo. oauth_nonce: Valor nonce. oauth_version: Valor opcional, caso esteja presente dever serdefinido como 1.0. Fornece a verso do processo de autenticao aser utilizado. 2. Os parmetros de protocolo so adicionados ao pedido utilizando algummtodo de transmisso. Cada parmetro no deve aparecer mais de umavez no pedido . 3. O cliente calcula e define o valor do parmetro oauth_signature eadiciona o parmetro ao pedido utilizando o mesmo mtodo do passoanterior . 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 parmetros do protocolo do Quadro 10, utilizando 32. 32suas credenciais de cliente, credenciais de token, a estampa de tempo atual, umvalor nonce gerado automaticamento e indica que o mtodo de assinatura ser oHMAC-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: Parmetros de ProtocoloFonte: OAuth (2010)O cliente adiciona parmetros do protocolo para o pedido utilizando o campode cabealho 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 Parmetro de AutorizaoFigura: OAuth (2010)Por ltimo o cliente calcula o valor do parmetro oauth_signature,adiciona-o ao pedido e envia o pedido HTTP ilustrado no Quadro 12 ao servidor.(OAUTH, 2010) 33. 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 Experincia do UsurioQuando o OAuth utilizado em uma aplicao, a experincia para o usuriofinal que interage com a aplicao muito menos intrusiva e complicada do que oprocesso necessrio para o desenvolvimento da mesma. (LEBLANC, 2011)Implementaes da tela de permisso, onde usurios permitem que umaaplicao faam aes em seu nome, podem variar muito dependendo daplataforma onde ela implementada, mas o princpio bsico o mesmo. Aplataforma exibe uma pgina contendo uma informao bsica sobre a aplicao efornece meios para que o usurio possa permitir ou negar que a aplicao utilizeseus dados pessoais. (LEBLANC, 2011)Leblanc (2011, p. 327) destaca as telas de autorizao de algumasplataformas que utilizam o OAuth, na Figura 1 apresentada a tela de autorizaodo Twitter e na Figura 2 apresentada a tela do Yahoo!. 34. 34Figura 1: Tela de Autorizao do TwitterFonte: Leblanc (2011)No caso da implementao do Yahoo!, o usurio primeiramente deveinformar seu usurio e senha e, posteriormente, ele ser redirecionado para a telade permisso. Nesta tela tambm so exibidas as aplicaes necessrias para ofornecimento de dados da aplicao que est requisitando autorizao. (LEBLANC,2011) 35. 35Figura 2: Tela de Autorizao do Yahoo!Fonte: Leblanc (2011) 36. 363 PROCEDIMENTOS METODOLGICOSPara a realizao do estudo de caso proposto neste trabalho foram adotadosmtodos que envolvem desde a parte de pesquisa at os estudos tecnolgicos e autilizao de uma estrutura fsica para o correto funcionamento das implementaes.O objetivo deste captulo descrever detalhadamente cada um dos procedimentosadotados, assim como as principais justificativas das escolhas tecnolgicas desteestudo.3.1 PROCEDIMENTOS DE PESQUISATratando-se dos procedimentos de pesquisa ser utilizado, inicialmente, apesquisa bibliogrfica, por ser [...] desenvolvida com base em material j elaboradoconstitudo principalmente de livros e artigos cientficos. (GIL, 2002). Posterior etapa da pesquisa bibliogrfica, ser adotada a pesquisa experimental porque,segundo Gil (2002), consiste em determinar um objeto de estudo, selecionar asvariveis que seriam capazes de influenci-lo, definir as formas de controle e deobservao dos efeitos que a varivel produz no objeto.3.1.1 Tipo de PesquisaQuanto a natureza da pesquisa ela pode ser classificada como aplicada pois[...] feita a partir de objetivos que visam sua utilizao prtica. Valem-se essaspesquisas das contribuies das teorias e leis j existentes. (PARRA FILHO et al,2001).Quanto aos objetivos, esta pesquisa classifica-se como exploratria pois [...]tm como objetivo proporcionar maior familiaridade com o problema, com vistas atorn-lo mais explcito ou a constituir hipteses. (GIL, 2002).3.2 ESTRUTURA FSICAA estrutura fsica utilizada para o desenvolvimento e testes das aplicaes composta de um notebook domstico com sistema operacional GNU/Linux Ubuntu 37. 3711.10, os navegadores de internet Opera 11 e Chromium, e a rede utilizada a FastEthernet 100.A configurao de hardware do notebook utilizado para o desenvolvimento etestes a seguinte: CPU Pentium Dual Core T2130 1.86GHz; 2 GB de memria DDR2 667MHz; HD de 160 GB SATA.3.3 TECNOLOGIASPara a implementao das aplicaes que so objetos de estudo destetrabalho foram utilizadas diversas tecnologias que, juntas, fornecem o corretofuncionamento do protocolo OAuth e das funcionalidades desenvolvidas em cadaaplicao.3.3.1 JavaDe acordo com a Sun Microsystems (atualmente Oracle) o Java umambiente de programao simples, robusto, orientado a objetos, independente deplataforma, dinmico e de propsito geral. Esta definio 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 programao de aplicaes (APIs) e verses foramdesenvolvidas. (SPELL, 2005)Segundo Spell (2005) a arquitetura Java completa composta por quatrocomponentes: A linguagem de programao 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 MicroEdition (J2ME); E a mquina virtual do Java (JVM). 38. 383.3.2 Spring MVC e Spring Security O Spring Framework uma soluo leve utilizada para desenvolveraplicaes corporativas. Ele modular, permitindo a utilizao apenas das partesnecessrias, sem a necessidade de utilizar o pacote completo. O Spring Frameworksuporta gerenciamento transacional declarativo, acesso remoto lgica com RMI eweb services, e diversas opes de persistncia de dados. Alm disso ele ofereceum framework MVC completo, e habilita a utilizao de linguagem orientada aaspectos (AOP) transparentemente no software. O componente de Inversion ofControl (IoC) prov um meio de injetar dependncias de uma classe utilizando meiosformais de compor componentes diferentes em uma aplicao totalmente funcionalpronta para utilizao. (SPRING, 2010) Spring MVC um componente do framework projetado para auxiliar efacilitar o desenvolvimento de aplicaes web, oferecendo uma ferramenta paradesenvolver aplicaes flexveis e com baixo acoplamento, assim como o prprioSpring Framework . Ele fornece funcionalidades de gerenciar o estado, fluxo detrabalho, validao. (WALLS, 2011) Spring Security outro componente do framework que oferece diversosrecursos que permitem que prticas de segurana comuns possam ser declaradasou configuradas de uma forma direta e declarativa. Com o Spring Security possvelmapear usurios a classes da aplicao, definir nveis de autorizao a papis deusurio, definir papis de usurios s classes, aplicar regras de autenticao portodos os recursos da aplicao, assim como regras de autorizao e prevenir tiposcomuns de ataque com o intuito de manipular ou roubar a sesso dos usurios.(MULARIEN, 2010) O componente Spring Security OAuth fornece uma implementao doprotocolo OAuth ao Spring Security. Ele suporta a especificao 1.0 e a 2.0, queainda est em fase de desenvolvimento. Ele suporta componentes para consumir efornecer servios de autenticao que suportam OAuth. (SRINGOAUTH, 2010)3.3.3 Hibernate O Hibernate uma soluo de Mapeamento Objeto-Relacional (ORM) para 39. 39ambientes Java. O termo Mapeamento Objeto-Relacional refere-se tcnica demapear dados de um modelo de representao em objetos para um modelo derepresentao relacional (e vice e versa). Alm do Hibernate lidar com estemapeamento ele tambm prov recursos para consulta e obteno de dados. OHibernate ajuda no encapsulamento de cdigo SQL especfico dos bancos de dados,abstraindo os mesmos do desenvolvedor, e fornece integrao 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 cdigo HTML final que ser enviado ao cliente. O clientereceber o resultado da execuo do script, mas no saber o cdigo que geroueste resultado. O PHP pode ser utilizado para, entre outras coisas, coletar dados deformulrios, gerar contedo de pginas dinamicamente, enviar e receber cookies emanipular banco de dados. (PHP, 2011)3.3.5 Zend Framework Zend Framework um framework de cdigo aberto utilizado nodesenvolvimento de aplicaes e servios web utilizando a linguagem PHP naverso 5. O framework desenvolvido utilizando um cdigo totalmente orientado aobjetos. A estrutura de componentes fornecida pelo Zend Framework foi projetadade forma a diminuir a dependncia entre eles, permitindo a utilizao decomponentes individuais. O framework tambm fornece uma implementao robustae de alta performance do padro MVC, alm da abstrao com o banco de dados,componentes para formulrios com validao e filtros, componentes de autenticaoe autorizao, incluindo suporte ao protocolo OAuth. (ZEND, 2010) 40. 403.3.6 Play FrameworkO 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 aplicaes web e, aomesmo tempo, se manter alinhado ao Java. Ele foi escrito puramente em Java, emantm 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, alm de fornecer JPA como a APIde mapeamento objeto-relacional, utilizada na persistncia de dados. (PLAY, 2010)3.3.7 HTML 5 e CSS3HyperText Markup Language 5 (HTML5) e Cascading Style Sheets 3 (CSS3)so dois padres novos propostos pela World Wide Web Consortium (W3C). Essastecnologias so a evoluo das tecnologias utilizadas no dia a dia de envolvidos coma internet, e existem para ajudar na construo de aplicaes web modernas einovadoras. Diversas novas funcionalidades ajudam na melhora da sintaxe dalinguagem, assim como adicionam um suporte maior a animaes interoperveis(independentes de plugins de terceiros), trazem novas funcionalidades parautilizao de sockets, armazenamento offline, melhorias de formulrios e muito mais.(HOGAN, 2010)O CSS3 adiciona novos seletores para melhorar a estilizao decomponentes, como, por exemplo, at a identificao de colunas pares e mpares deuma tabela. A nova verso do CSS tambm traz efeitos visuais sofisticados, comosombras, gradientes, cantos arredondados e etc. Ambas as novas tecnologias aindaso trabalhos em andamento, porm cada vez mais as ferramentas de acesso internet (como navegadores) esto adotando e suportando essas tecnologias.(HOGAN, 2010) 41. 413.3.8 MySQL O software MySQL prov um servidor de banco de dados Structured QueryLanguage (SQL) robusto, multi-usurio, rpido e eficaz. Ele indicado para sistemasem produo de alta carga assim como para incorporao em massa de sistemas jimplantados. O servidor MySQL possui uma licena comercial, fornecida pela Oraclee uma verso de cdigo-aberto. (MYSQL)3.4 JUSTIFICATIVAS TECNOLGICAS O protocolo OAuth foi escolhido principalmente por sua facilidade deimplementao, tanto na parte servidor quanto para os consumidores. Quandocomparado ao OpenID e CAS, a implementao 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 padres abertos como HTTP junto com todos os seus recursos e permitegrande flexibilidade com relao a mecanismos de criptografia, e exigncias deobrigatoriedade de parmetros, ficando a cargo do desenvolvedor decidir o que mais adequado para o seu caso. A tecnologia Java foi escolhida para ser utilizada na aplicao servidor deOAuth principalmente por ser uma das mais utilizadas no ambiente corporativo, que o ambiente ideal para a implantao do OAuth, principalmente por, na maioria doscasos, um ambiente corporativo ser dividido em diversas aplicaes independentesentre si, mas que utilizam uma base de autenticao de usurios. 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 mdulo OAuth foram utilizados para provermeios de autenticao, segurana das funcionalidades, recursos web para cadastrode usurios, injeo de dependncias, mapeamento de URL e gerencia de beans. OHibernate foi o escolhido por suportar a especificao 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 42. 42a aplicao de controle de finanas, 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 (graas ao Groovy), integrao nativa comJPA, mapeamento de requisies, e por sua fcil integrao com o OAuth. HTML5 e CSS3 foram as linguagens escolhidas para a parte de visualizaodas aplicaes. Foram utilizados seletores avanados do CSS3, validao nativa doHTML5, novas tags, cantos arredondados, sombras e gradientes. O banco de dados MySQL foi escolhido por sua fcil integrao com cadauma das tecnologias utilizadas nas aplicaes. 43. 434 IMPLEMENTAO Este captulo descreve as trs aplicaes desenvolvidas para demonstrar ofuncionamento do protocolo OAuth. Cada aplicao foi construda em um escoposeparado visando demonstrar a capacidade de integrao das tecnologias com oprotocolo OAuth e os recursos bsicos necessrios para um provedor deautenticao. Foram elaboradas as seguintes aplicaes, explanadas maisdetalhadamente a seguir: Servidor de Autenticao OAuth: Fornece as capacidades de autenticao utilizando o protocolo OAuth; Agenda de contatos: Uma aplicao de agenda de contatos simples que se autentica com o servidor de autenticao OAuth; Controle de Finanas: Uma aplicao para controle de finanas, utiliza o servidor de autenticao OAuth para permitir sua utilizao.4.1 SERVIDOR DE AUTENTICAO O servidor de autenticao foi desenvolvido com o propsito de fornecer oendpoint de autenticao para consumidores OAuth. Sua estrutura foi definidautilizando o framework Spring MVC, com o padro arquitetural Model-View-Controller (MVC), alm de definir servios, entidades e repositrios conformeapresentado na Figura 3. 44. 44Figura 3: Arquitetura DefinidaFonte: Autoria Prpria4.1.1 Configurao do Spring Security e OAuthPara fornecer os recursos de segurana e proteo de acessos foi utilizadoo framework Spring Security, em conjunto com o componente Spring Security OAuth.Para configur-los necessrio definir um arquivo XML com todos os parmetros deconfigurao necessrios para a aplicao. O Quadro 13 apresenta o arquivo deconfigurao utilizado na aplicao. 45. 45Quadro 13: Arquivo de Configurao do Spring SecurityFonte: Autoria PrpriaOs principais pontos a se destacar neste arquivo de configurao so osparmetros com o prefixo security:. Primeiramente so definidos dois endpointsque no tero segurana: a pasta de imagens, arquivos de folhas de estilos ejavascript nomeada resources, e o endereo utilizado para acessar o formulrio deautenticao /user/login. 46. 46 A prxima etapa adicionar restries para que os endereos internos dosistema s possam ser acessados por usurios autenticados. Os endereos quecontm as palavras oauth, request_token_authorized.jsp, dashboard,index.jsp, user/profile, user/info sero protegidos pelo framework desegurana, exigindo que um usurio esteja autenticado para acessar algum destesendereos. Tambm definido o endereo para o formulrio de autenticao. Aps definir a configurao de recursos protegidos, necessrio configuraro servio que fornece os meios de autenticao do usurio. Neste caso foi definidoum servio customizado, contendo o cdigo apresentado no Quadro 14, assim comoum bean para criptografia de senha. As prximas linhas definem a configurao do provedor de OAuth daaplicao. necessrio definir o servio que fornece dados dos consumidoressuportados pela aplicao. Somente os consumidores definidos na tag consumer-details-service podero consumir o servio de autenticao, requisitando aautorizao de acesso pelo proprietrio do recurso autenticado. Para este trabalhoforam definidos dois consumidores: uma aplicao de finanas e outra de agenda decontatos. O parmetro token-services-ref, define o servio que fornecer asfuncionalidades para: Gerar credenciais temporrias; Gerar tokens de acesso; Verificar a validade dos tokens; Vincular consumidores, proprietrios de recursos e tokens. Para a aplicao desenvolvida,foi utilizada a classeInMemoryProviderTokenServices, que um servio de tokens nativo dabiblioteca Spring Security OAuth, que armazena em memria os tokens gerados eutiliza mecanismos de tempo para validar um token utilizado para uma tentativa deautorizao ou para uma requisio autenticada. Os demais parmetros definidos na tag provider definem os endpointspara, respectivamente, a requisio de tokens temporrios, a autenticaoautorizada por um proprietrio do recurso, a pgina de autorizao de umconsumidor pelo proprietrio do recurso, a pgina de confirmao de que o acesso 47. 47foi concebido (caso no seja definido o parmetro oauth_callback) e o endereopara obter as credenciais de token.4.1.2 Autenticao de UsuriosO arquivo de configurao do Spring Security, define um servio deautenticao de usurios, que nada mais do que um bean que implementa ainterface UserDetailsService e o mtodo loadByUsername. O Quadro 14 mostraum trecho do servio implementado, que busca na base de dados por um nome deusurio passado como parmetro do mtodo.@Service("userService")public class UserServiceImpl implements UserService{@Autowiredprivate UserRepository userRepository;@Overridepublic UserDetails loadUserByUsername(String username){return userRepository.findByUsername(username);}}Quadro 14: Servio de UsurioFonte: Autoria PrpriaO banco de dados da aplicao composto apenas por uma tabela deusurios e para manipular esta tabela foi implementado um repositrio, que utiliza oEntityManager fornecido pelo Hibernate para efetuar uma consulta baseando-se nonome de usurio passado como parmetro. O cdigo deste repositrio apresentado no Quadro 15. 48. 48@Repositorypublic class UserRepository extends AbstractRepository {public User findByUsername(String username) {try {TypedQuery 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: Repositrio de usuriosFonte: Autoria PrpriaNo Quadro 16 apresentado o cdigo do formulrio de autenticao,utilizando HTML5. Foram utilizados os novos atributos da tecnologia que permitemque o prprio navegador de internet faa a validao dos campos, sem anecessidade de programar Javascript para essa funcionalidade. Tambm foramutilizadas as tags novas que do mais semntica ao cdigo implementado.

MyPortal - Login
Ocorreu um erro. Verifique seu usurio/senha.
" class="form-login">

Nome de Usurio:

Senha:

Quadro 16: Tela com o Formulrio de LoginFonte: Autoria PrpriaO resultado deste cdigo apresentado na Figura 4. Esta tela deautenticao apresentada ao usurio ao se acessar alguma das aplicaes 49. 49desenvolvidas e permite que o usurio fornea suas credenciais de acesso,prosseguindo com o fluxo de autorizao.Figura 4: Tela de autenticaoFonte: Autoria Prpria4.1.3 Confirmao do Proprietrio do RecursoPara que o consumidor possa utilizar os dados do proprietrio do recurso oOAuth exige que, aps efetuar a autenticao, o provedor apresente uma telasolicitando ao proprietrio do recurso se ele autoriza ou no o acesso do consumidoraos seus dados. Para esta funcionalidade foi desenvolvido um controlador, queresponde URL configurada no arquivo de configurao do Spring Security,responsvel por direcionar o usurio para a tela de confirmao de acesso daaplicao, validar as credenciais e tokens temporrios, e, tambm, revogar umacesso a um token temporrio. O Quadro 17, apresenta o cdigo implementado paraeste controlador. 50. 50@Controllerpublic class AccessConfirmationController{@Autowiredprivate OAuthProviderTokenServices tokenServices;@Autowiredprivate 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 derequisio");}OAuthProviderToken providerToken = tokenServices.getToken(token);ConsumerDetails consumer =consumerDetailsService.loadConsumerByConsumerKey(providerToken.getConsumerKey());String callback = request.getParameter("oauth_callback");TreeMap model = new TreeMap();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 Confirmao de AcessoFonte: Autoria PrpriaA primeira etapa verificar se os parmetros de token foram informados narequisio, aps isso o token obtido do servio definido no arquivo deconfigurao, e logo aps, os dados do consumidor so obtidos. Caso em algumadessas etapas algum dado no seja informado, ser lanada uma exceo e ocdigo HTTP de erro ser o 401 UNAUTHORIZED. Caso o parmetrooauth_callback esteja definido, ele ser definido tambm na tela de autorizao,para que o Spring OAuth redirecione o usurio caso o mesmo permita o acesso doconsumidor.O mtodo de revogao de acesso, faz com que o token temporrio expire 51. 51e, redireciona o usurio para informar que o consumidor foi revogado com sucesso.O Quadro 18 apresenta o cdigo da tela de autorizao do proprietrio dorecurso. Ele aponta o endereo para o endpoint definido de confirmao daautorizao do acesso. Caso exista o parmetro oauth_callback o mesmo adicionado a um campo escondido do formulrio, e internamente, o Spring SecurityOAuth define este endereo como o ponto de redirecionamento aps concluir oprocesso de autorizao.Confirmar Acesso

Voc confirma a autorizao daaplicao "" para acessar os seguintes recursos:

" method="post">"type="hidden" />" type="hidden"/>

"class="button red">Revogar

Quadro 18: Formulrio de Autorizao de um ConsumidorFonte: Autoria PrpriaA tela de autorizao do proprietrio do recurso apresentada na Figura 5,ela exibe as informaes sobre a aplicao que est requirindo autorizao doproprietrio do recurso autenticado, e as opes de autorizar ou revogar o acesso daaplicao em questo. 52. 52 Figura 5: Tela de autorizao Fonte: Autoria Prpria Caso o proprietrio do recurso revogue o acesso do consumidor ele sermantido na aplicao servidor de OAuth, e ser exibida a tela apresentada na Figura6, que indica que o consumidor foi revogado com sucesso. Se o proprietrio dorecurso autorizar o acesso do consumidor ele ser redirecionado para as telasprincipais do consumidor em questo. Essas telas so apresentadas na e .Figura 6: Tela de acesso revogadoFonte: Autoria Prpria4.2 APLICAO 1: AGENDA DE CONTATOS A primeira aplicao desenvolvida tem como foco principal fornecer umaagenda simples de contatos. Ela foi desenvolvida utilizando o Play! Framework, juntocom seu mdulo OAuth, e permite que o usurio, aps a autenticao e autorizaodo consumidor, mantenha uma lista de contatos com nome, endereo, telefone, e-mail e data de nascimento de cada contato. Os controladores possuem um mtodo para verificar se existe um usurio 53. 53definido em sesso e, caso no exista, redireciona o usurio para que o mesmo faaautenticao como proprietrio do recurso e autorize o consumidor a obter os dadosdo perfil do usurio. O cdigo do Quadro 19 apresenta o mtodo do controlador quefaz essa verificao, simplesmente validando um parmetro da sesso.@Beforestatic void checkAuthentication() throws Exception {if (session.get("user") == null) AuthenticationController.auth();}Quadro 19: Mtodo de verificao de usurio logadoFonte: Autoria PrpriaCaso seja necessrio efetuar a autenticao do proprietrio do recurso como OAuth, o controlador de autenticao ser executado, ficando responsvel porredirecionar o agente de usurio para o servidor Oauth, onde sero apresentadas aousurio as telas apresentadas nas Figuras 5 e 6, e obter o retorno do servidor.O Quadro 20 apresenta o cdigo utilizado para criar o cliente OAuthutilizando o mdulo disponvel para o Play Framework onde os seguintes parmetrosde configurao so definidos: Endereo para obter o token temporrio; Endereo para obter o token de acesso; Endereo para obter a autorizao do proprietrio do recurso; Chave identificadora do consumidor; Segredo compartilhado do consumidor.Aps a criao do cliente OAuth, criado um objeto que armazenar osdados de credenciais de token. E, aps isso, o mtodo authenticate, redireciona ousurio para o servidor OAuth, e define o endereo de retorno, a partir do parmetrooauth_callback da requisio, que apontar para o mtodo callback, apresentadono Quadro 21. 54. 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: Mtodo de autenticao com o servidor OAuthFonte: Autoria PrpriaO mtodo de retorno, ir obter o parmetro oauth_verifier, que contm ocdigo de verificao indicando que o token para o consumidor em questo foidefinido e autorizado. Aps obter o cdigo verificador, o cliente OAuth obtm ascredenciais de token para, a partir deste ponto em diante, fazer requisiesautenticadas em nome do proprietrio do recurso. A requisio efetuada obtm asinformaes do perfil do proprietrio do recurso, para definir em sesso o cdigoidentificador do mesmo, o nome real e o nome de usurio utilizado por ele. Emseguida so utilizados os componentes do Play! Framework para mapear a respostaJSON retornada pelo servidor a um objeto do tipo User, so armazenados os dadosdo usurio em sesso 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: Mtodo de retorno do processo de autorizao OAuthFonte: Autoria PrpriaAps concluir o fluxo de autorizao e armazenar uma instncia de User emsesso apresentada a tela principal do sistema ao usurio, ilustrada na Figura 7. 55. 55Figura 7: Tela inicial da aplicao de contatosFonte: Autoria PrpriaNesta tela o usurio poder ver com que credenciais se autenticou, e solistados todos os contatos cadastrados pelo usurio autenticado. Ao acessar o botoAdicionar Novo apresentado o formulrio de cadastro de um contato, conformeapresentado na Figura 8.Figura 8: Tela para Adicionar um ContatoFonte: Autoria Prpria 56. 564.3 APLICAO 2: CONTROLE DE FINANASA aplicao de controle de finanas tem como objetivo fornecer ao usurio ocadastro de lanamentos de crdito e de dbito e, baseando-se na soma doscrditos e dbitos, 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 aplicao de agenda de contatos, o controle de finanasexige a autenticao e autorizao do proprietrio do recurso e, aps isso, guardaem sesso os dados de seu perfil. O banco de dados utilizado define apenas atabela de contas.Seguindo o mesmo modelo da aplicao de contatos, o controle de finanasfaz a verificao se existe um usurio autenticado e, caso no exista, redireciona ousurio para um controlador de autenticao que implementa um consumidor OAuth.O Quadro 22 apresenta o plugin, configurado na pilha de plugins de controladoresdo Zend Framework, que faz a verificao se o componente Zend_Auth possui umaidentidade definida e, caso no possua, muda a requisio para o controlador deautenticao.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 verificao de usurio autenticadoFonte: Autoria PrpriaOs parmetrosparaaconfigurao do componente 57. 57Zend_Oauth_Consumer so definidos no arquivo de configurao application.inida aplicao. Estes parmetros so 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: Parmetros de configurao dos servios OAuthFonte: Autoria PrpriaO controlador de autenticao, apresentado no Quadro 24, responsvelpor criar uma instncia do componente Zend_Oauth_Consumer, utilizando osparmetros de configurao definidos no arquivo de configurao, estes sendoobtidos na primeira linha do mtodo init. As linhas subsequentes tm a funo,respectivamente, de inicializar a sesso do Zend Framework, configurar osparmetros do OAuth, que definem o endereo de retorno, o endereo do servidorOAuth, a chave de consumidor e o segredo de consumidor compartilhado. Apsinstanciar o componente, definido o endereo de autorizao 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: Mtodos de inicializao e de redirecionamento do controlador de autenticaoFonte: Autoria PrpriaO mtodo loginAction ficar responsvel por utilizar o componenteZend_Oauth_Consumer para obter o token temporrio, armazen-lo em sesso e 58. 58redirecionar o proprietrio do recurso para que o mesmo inicie o processo deautorizao. Aps autorizar a aplicao, o mtodo callbackAction, apresentado noQuadro 25 executado. Este mtodo obtm o token temporrio da sesso, obtmos parmetros passados por GET no cabealho HTTP, e, caso os parmetros sejamvlidos, obtm as credenciais de token baseando-se nestes parmetros.Aps isso as credenciais de token so armazenadas em sesso, e osparmetros de configurao do servio que obtm os dados do perfil do proprietriodo recurso autenticado so obtidos, para efetuar uma requisio POST que obtmos dados do perfil em JSON. Aps obter os dados, os mesmos so convertidos a umobjeto do tipo stdClass do PHP, e so armazenados na sesso do componenteZend_Auth. Aps todo o processo estar concludo, o usurio redirecionado para atela principal da aplicao de finanas.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 autorizao);}}Quadro 25: Mtodo de Retorno do processo de autorizaoFonte: Autoria PrpriaSimilarmente aplicao de Agenda de Contatos, quando o processo deautorizao for finalizado ser apresentado ao usurio a tela principal da aplicao.Na aplicao de controle de contas esta tela a apresentada na Figura 9. 59. 59Figura 9: Tela inicial da aplicao de finanasFonte: Autoria Prpria Nesta tela apresentado ao usurio o nome com que ele se autenticou e osdados de suas finanas, junto com um balano calculado a partir da diferena entreos crditos e os dbitos. Caso o resultado seja negativo o campo de saldo serapresentado em vermelho. Caso seja positivo ser apresentado em verde. Ao seacessar o boto Adicionar Nova o usurio poder cadastrar um novo lanamentono formulrio apresentado na Figura 10.Figura 10: Tela para adicionar um lanamentoFonte: Autoria Prpria 60. 605 CONSIDERAES FINAIS A segurana de uma aplicao um ponto crucial para garantir o sigilo dosdados dos usurios e para fornecer uma aplicao robusta e confivel. Ao secentralizar a base de dados de um usurio a algum protocolo que no exija que omesmo trafegue suas credenciais entre diversas aplicaes, essa segurana aindamaior, pois, principalmente, a segurana 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 comunicao entre autorizao dosconsumidores autorizados pelo proprietrio do recurso. Este protocolo amplamenteutilizado no mercado, tendo como aplicaes famosas o Twitter, Facebook,aplicativos do Google como Calendar e Gmail, alm de outras grandes corporaesdo mercado. Um reflexo da fama do OAuth pde ser percebido pela quantidade debibliotecas disponveis, no s para as linguagens escolhidas no escopo dessetrabalho, mas para outras tecnologias como .NET, Python, Perl e outras. Com essasbibliotecas possvel ganhar produtividade no desenvolvimento de provedores econsumidores de OAuth, pois elas escondem toda a lgica principal da utilizao doprotocolo e, alm disso, fornecem meios fceis e intuitivos para customizar outrasregras, como, por exemplo, a de expirao de tokens. Uma concluso que tambm vale ressaltar a de transparncia para ousurio. Para o usurio, tudo que est acontecendo internamente pelas aplicaesno tm suma importncia, ele v a tela de autenticao principal e centralizada, e afcil integrao das aplicaes com o provedor da autenticao. Alm disso, ele temtotal controle sobre o que poder acessar seus dados, e, alm de esse controle,tambmos desenvolvedores e administradorespodemgerenciarquaisconsumidores podem efetuar uma tentativa de utilizao do provedor OAuth.5.1 TRABALHOS FUTUROS Os trabalhos futuros deste trabalho esto relacionados, principalmente, aadicionar novas funcionalidades estrutura desenvolvida. Estas funcionalidades no 61. 61foram includas por fugirem do escopo do trabalho, porm so essenciais para umprovedor de autenticao OAuth. Dentre as principais melhorias, esto includas: Adicionar os tokens gerados pelo framework Spring Security OAuth a umbanco de dados, ao invs de uma fonte de dados voltil como a memriaRAM. Isso pode ser implementado criando-se um novo servio de tokens,que implemente a interface OAuthProviderTokenServices; Aps implementar o servio de tokens mencionado acima, implementarum servio de consumidores, permitindo que um administrador de sistemacadastre novas aplicaes que podem tentar consumir dados dosproprietrios de recursos capazes de se autenticar no sistema. Para isso necessrio implementar um novo servio de consumidores, queimplemente a interface ConsumerDetailsService; Com estas duas melhorias implementadas, outro trabalho futuro acapacidade de listar para o usurio as aplicaes que o mesmo autorizoue, permitir que o mesmo possa revogar o acesso das aplicaescadastradas; Outra melhoria , ao revogar o acesso de uma aplicao, a capacidade delimpar os dados do usurio armazenados nessa aplicao, permitindo quea base de dados no fique inconsistente j que o proprietrio do recursono autoriza mais que o consumidor utilize seus dados.Essas melhorias esto relacionadas aplicao desenvolvida aqui, porm,quando a verso 2.0 do Oauth, que at esta data encontra-se em rascunho, setornar uma especificao estvel, uma melhoria importante aatualizao daestrutura para utilizar esta verso. 62. 62 REFERNCIASCORREIA, Miguel Pupo; SOUSA, Paulo Jorge. Segurana no Software. Lisboa:FCA Editora de Informtica, 2010.GIL, A. C. Como elaborar projetos de pesquisa. 4. ed. So Paulo: Atlas, 2002.GOURLEY, David; TOTTY, Brian. HTTP The Definitive Guide. Sebastopol: OReillyMedia, 2002.HIBERNATE.Hibernate Getting Started Guide. Disponvel em:. 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. Disponvel em:. Acesso em 29 nov.2011.OAUTH. RFC 5849 - TheOAuth 1.0 Protocol. Disponvel em:. Acesso em 08 ago. 2011.PARRA, D. F.; SANTOS, J. A. Metodologia Cientfica. 4. ed. So Paulo: Futura,2002.PHP. PHP Manual. Disponvel em: . Acesso em 28nov. 2011. 63. 63PLAY.PlayFramework Overview.Disponvel em:. 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. Disponvel em:. Acesso em 28 nov. 2011.SPRINGOAUTH.Home ofSpringOAuth. Disponvel em:. Acesso em 28 nov.2011.WALLS, Craig. Spring in Action Third Edition. Shelter Island: ManningPublications, 2011.ZEND.ZendFrameworkIntroduction.Disponvelem:. Acesso em 28nov. 2011.

Recommended

View more >