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

63
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 MANTOAN ESTUDO DE CASO DE UMA ESTRUTURA DE AUTENTICAÇÃO ÚNICA UTILIZANDO O PROTOCOLO OAUTH MONOGRAFIA DE ESPECIALIZAÇÃO MEDIANEIRA 2011

description

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

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

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

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 MANTOAN

ESTUDO DE CASO DE UMA ESTRUTURA DE AUTENTICAÇÃO ÚNICA UTILIZANDO O PROTOCOLO OAUTH

MONOGRAFIA DE ESPECIALIZAÇÃO

MEDIANEIRA2011

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

FERNANDO GERALDO MANTOAN

ESTUDO 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

MEDIANEIRA2011

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

Ministério da EducaçãoUniversidade Tecnológica Federal do Paraná

Diretoria de Pesquisa e Pós-GraduaçãoEspecialização em Projeto e Desenvolvimento de Sistemas baseados em

Objetos para Ambiente Internet

TERMO DE APROVAÇÃO

Estudo 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 2011

como requisito parcial para a obtenção do título de ESPECIALISTA, no curso de

Especialização em Projeto e Desenvolvimento de Sistemas baseados em Objetos

para Ambiente Internet, da Universidade Tecnológica Federal do Paraná, Câmpus

Medianeira. O acadêmico foi arguido pela Banca Examinadora composta pelos

professores abaixo assinados. Após deliberação, a Banca Examinadora considerou

o trabalho aprovado.

Prof. Esp. Diego de Carvalho

Orientador

UTFPR – Câmpus Pato Branco

Prof. Me. Alan Gavioli

Convidado

UTFPR – Câmpus Medianeira

Prof. Dr. Hermes Irineu Del Monego

Convidado

UTFPR – Câmpus Medianeira

Prof. Me. Fernando Schütz

Coordenador do Curso de Especialização

UTFPR – Câmpus Medianeira

UTFPR – DIRPPGAv. Brasil, 4232 – Pq Independência

85884000 – Medianeira – PRwww.utfpr.edu.br/medianeira

+55(45) 3240-8074

A FOLHA DE APROVAÇÃO ASSINADA ENCONTRA-SE NA DIRETORIA DE PÓS-GRADUAÇÃO DA UTFPR CÂMPUS MEDIANEIRA

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

AGRADECIMENTOS

Primeiramente a Deus, por sempre me iluminar e ser o meu apoio nas horas mais

difí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ça

que 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 presente

fisicamente.

Agradeço aos meus amigos e colegas, pelos momentos de discussão, estudo e

diversão.

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

“A coisa mais bonita que podemos experimentar é o mistério. Ele é a fonte de toda a verdadeira arte e ciência.”Albert Einstein

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

RESUMO

MANTOAN, Fernando Geraldo. Estudo de caso de uma estrutura de autenticação única

utilizando o protocolo OAuth. 56 f. Monografia (Especialização em Projeto e

Desenvolvimento de Sistemas Baseados em Objetos para Ambiente Internet) – Programa

de 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 uma

estrutura de autenticação única utilizando o protocolo OAuth. Com este protocolo o

modelo tradicional de autenticação cliente-servidor ganha um terceiro papel que é o de

proprietário do recurso, um usuário com credenciais válidas no provedor OAuth

responsá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 tecnologias

utilizadas no estudo de caso, e toda a parte de implementação, composta por um

provedor OAuth e duas aplicações consumidoras, utilizada para verificar as

funcionalidades do OAuth.

Palavras-chave: Segurança, Spring Framework, Java, Play Framework, PHP, Zend

Framework.

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

ABSTRACT

MANTOAN, Fernando Geraldo. Case study of a structure of single sign on with the OAuth

protocol. 56 f. Monografia (Especialização em Projeto e Desenvolvimento de Sistemas

Baseados em Objetos para Ambiente Internet) – Programa de Pós-graduação em

Tecnologia, Universidade Tecnológica Federal do Paraná. Medianeira, 2011.

This assignment has the main goal of presenting a case study of an structure of single

sign on with the OAuth protocol. With OAuth the traditional client-server authentication

model gains a third role, which is the role of the resource owner, an user with valid

credentials in the OAuth provider responsible of allowing or revoking consumers access to

its personal data. It also makes a study about the main security concepts, an overview of

the 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 to

check the OAuth functionalitys.

Keywords: Security, Spring Framework, Java, Play Framework, PHP, Zend Framework.

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

LISTA DE FIGURAS

FIGURA 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

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

LISTA DE SIGLAS

API Application Programming Interface

AOP Aspect Oriented Programming

CAS Central Authentication Service

CSS Cascading Style Sheets

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

HTTPS HyperText Transfer Protocol Secure

IoC Inversion of Control

J2EE Java 2 Platform Enterprise Edition

J2ME Java 2 Platform Micro Edition

J2SE Java 2 Platform Standard Edition

JPA Java Persistence API

JVM Java Virtual Machine

MVC Model View Controller

OAUTH Open Authentication

ORM Object Relational Mapper

PHP Hypertext Preprocessor

REST Representational State Transfer

RMI Remote Method Invocation

SQL Structured Query Language

SSL Secure Sockets Layer

URI Unified Resource Identifier

URL Uniform Resource Locator

W3C World Wide Web Consortium

WWW World Wide Web

XML Extensible Markup Language

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

SUMÁRIO

1 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

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

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

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

12

1 INTRODUÇÃO

Aplicações no geral possuem a necessidade comum de restringir o acesso

aos seus recursos utilizando meios de segurança como, por exemplo, autenticação

de usuários. Comumente, cada aplicação fornece uma fonte de dados para

armazenar 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 suas

credenciais para acessar os recursos hospedados pelo servidor. Com o advento do

uso de web services distribuídos e de cloud computing, aplicações de terceiros

precisam acessar estes recursos hospedados pelo servidor. (OAUTH, 2010)

O protocolo OAuth introduz um terceiro papel no modelo tradicional de

autenticação cliente-servidor: o resource owner (proprietário do recurso). No modelo

OAuth, 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 no

servidor. Além disso, o OAuth permite que o servidor verifique não apenas a

autorizaçã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 estrutura

básica de autenticação única, com a definição de uma arquitetura para a parte de

autenticação utilizando o protocolo OAuth, e duas mini-aplicações, que utilizam a

estrutura de autenticação desenvolvida, permitindo ou negando acesso aos recursos

disponibilizados, 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)

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

13

O protocolo OAuth fornece um método para que clientes acessem recursos

do servidor em nome de um proprietário do recurso. Com ele também é possível

fornecer um processo para usuários finais autorizarem acesso de terceiros aos

recursos de seus servidores sem compartilhar suas credenciais (como o conjunto

usuário/senha), usando redirecionamento de seus agentes de usuários. (OAUTH,

2010)

1.2 OBJETIVOS

1.2.1 Objetivo Geral

Propor uma estrutura para fornecer autenticação única com o protocolo

OAuth na plataforma Java, e implementar duas mini-aplicações que utilizem esta

estrutura 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.

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

14

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo é apresentada toda a fundamentação teórica levantada

durante a análise bibliográfica dos principais conceitos necessários para o estudo

deste trabalho. Serão abordados os principais aspectos sobre segurança,

autorização, autenticação, cloud computing, o protocolo HTTP, alguns protocolos de

autenticação similares ao OAuth (OpenID e CAS) e os principais conceitos

fornecidos pela especificação do protocolo OAuth.

2.1 SEGURANÇA

Segurança é sem dúvida um dos componentes arquiteturais mais críticos de

qualquer aplicação baseada na web escrita no século vinte e um. Em uma era onde

malwares, crimonosos, e funcionários mal intencionados estão sempre presentes e

ativamente 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ência

de divulgação não autorizada de conteúdo. A integridade é a ausência de

alterações não autorizadas ao sistema ou à informação. A disponibilidade é a

prontidão do serviço fornecido ou da informação. Além das três, é comumente

adicionada a autenticidade, que é a medida em que a informação ou o serviço

fornecido são genuínos. (CORREIA; SOUSA, 2010)

Um dos principais conceitos na segurança de software é o de

vulnerabilidades, que é um defeito relevante no sistema que pode ser explorado por

um atacante com o objetivo de subverter sua política de segurança. Existem três

tipos 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 a

vulnerabilidade operacional, causada pelo ambiente onde o sistema é executado

ou por sua configuração. (CORREIA; SOUSA, 2010)

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

15

2.2 AUTENTICAÇÃO

Autenticação é um dos dois conceitos chave que deve ser implementado ao

se desenvolver aplicações seguras. A autenticação lida com a identificação

específica de um usuário do sistema, e com o mapeamento deste usuário para uma

entidade identificável (e, portanto, protegida). Tipicamente, um software está dividido

em 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 independentes

de uma identificação de usuário, como por exemplo, uma listagem de produtos em

um site de comércio eletrônico. As seções que permitem acesso anônimo não

requerem a autenticação do usuário para sua utilização, não exibem informações

confidenciais como nomes e cartões de créditos, e não fornecem meios para

manipulaçã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 cruciais

na implementação e compreensão de segurança de aplicações. Autorização lida

com a disponibilidade adequada de funcionalidades e dados para usuários que

estão autorizados para acessá-los. Construído em torno do modelo de autorização

para a aplicação está a atividade de particionar as funcionalidades e os dados da

aplicação de tal forma que a disponibilidade destes itens possam ser controlados por

uma combinação de privilégios, funcionalidades e dados, e usuários. (MULARIEN,

2010)

O processo de autorização tipicamente envolve dois aspectos separados

que se combinam para descrever a acessibilidade do sistema seguro. O primeiro é o

mapeamento de um usuário autenticado para um ou mais papéis, por exemplo o

papel de administrador do sistema ou o papel de visitante. O segundo aspecto é a

atribuição das checagens de autoridade para os recursos protegidos do sistema, o

que tipicamente é feito durante o desenvolvimento do sistema, através de

declaração explícita no código ou por meios de configuração. Um recurso protegido

pode ser uma funcionalidade do sistema, como, por exemplo, gerenciamento de

produtos. (MULARIEN, 2010)

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

16

2.4 CLOUD COMPUTING

Cloud Computing (computação na nuvem) é um fenômeno recente que

impacta na forma com que infra-estruturas são arquitetadas, compradas e

implantadas. No modelo de computação na nuvem, computação e infra-estruturas

de armazenamento estão disponíveis para uso como um utilitário e não apenas

dentro de uma infra-estrutura própria. O modelo de utilitário estende-se a partir de

apenas um hardware de computador de plataforma de serviços para aplicativos

completos como um serviço externo. (SANKAR; BOUCHARD, 2009)

Computação na nuvem é uma otimização tática assim como um artefato

arquitetural estratégico. É uma otimização tática, porque ao se ter aplicações ad-hoc

que precisam funcionar em um curto período de tempo (como uma enquete ou

alguma pesquisa) é possível executá-la em uma infra-estrutura de nuvem, como, por

exemplo, o Amazon Elastic Compute Cloud. Mas também é estratégica porque

agora os acionistas de empresa (e envolvidos em TI) podem trabalhar além das

limitações de largura de banda finita de computação e otimizar os sistemas ativos a

uma era de poder de processamento infinito, que é flexível. (SANKAR; BOUCHARD,

2009)

Uma nuvem é um conjunto de soluções escaláveis, com infra-estrutura

abstrata que hospeda aplicações de uso final, cobrado pelo consumo. Em suma,

uma nuvem é um conjunto grande de infra-estrutura de servidores, rede e

armazenamento, hospedado em algum lugar para ser alugado ou usado conforme a

necessidade. Ele pode ser interno a uma empresa (chamado de nuvem “privada”) ou

hospedado na internet como uma nuvem “pública”. A decisão de se utilizar a nuvem

privada ou pública para um aplicativo é determinada por políticas, conformidade e

regulamentos relevantes para uma organização, bem como as condições de

visibilidade e controle de uma empresa comparado com os recursos fornecidos por

um provedor de nuvem público. (SANKAR; BOUCHARD, 2009)

2.5 HTTP

Todos os navegadores de internet, servidores, e aplicações web

relacionadas se comunicam entre si através do Hypertext Transfer Protocol (HTTP),

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

17

que é 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 servidores

fornecem os dados quando são requisitados pelos clientes HTTP, que enviam

pedidos HTTP para servidores e recebem os dados pedidos em respostas HTTP. O

conjunto de clientes e servidores HTTP fazem os componentes básicos da World

Wide Web (WWW). (GOURLEY; TOTTY, 2002)

O protocolo HTTP possui diversos blocos necessários para seu correto

funcionamento, cada um com uma finalidade distinta para compor este protocolo

que, segundo Gourley e Totty (2002) é o mais utilizado pela internet atual. Dentre

estes 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 podem

apontar quais recursos eles estão interessados em acessar. O nome do recurso de

servidor é chamado de Unified Resource Identifier (URI), em português Identificador

Único de Recurso. URIs são como os endereços postais da Internet, identificando

exclusivamente e localizando informação de recursos em todo o mundo. Um

exemplo de URI de uma imagem em um servidor web é apresentado no Quadro 1.

(GOURLEY; TOTTY, 2002)

http://www.site.com/imagens/imagem.gif

Quadro 1: Exemplo de URI

2.5.2 URLs

O Uniform Resource Locator (URL) é a forma mais comum de um

identificador de recurso. URLs descrevem a localização específica de um recurso

em um servidor particular. Elas descrevem exatamente como obter um recurso de

uma localização precisa e fixa. (GOURLEY; TOTTY, 2002)

De acordo com Gourley e Totty (2002) muitas URLs seguem um formato

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

18

padronizado 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 do

cliente ao servidor), e um resultado de resposta (enviado de volta ao cliente). Esta

comunicação acontece com blocos formatados de dados chamados de mensagens

HTTP. (GOURLEY; TOTTY, 2002)

2.5.4 Métodos

O protocolo HTTP suporta diferentes comandos de pedido, chamados de

métodos HTTP. Cada mensagem de pedido HTTP possui um método, que diz ao

servidor 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ção

GET 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 HTTP

Fonte: Gourley e Totty (2002)

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

19

2.5.5 Códigos de Estado

Cada mensagem de resposta HTTP retorna com um código de estado. O

código de estado é um número de três dígitos que diz ao cliente se o pedido foi

executado com sucesso, ou se outras ações são necessárias. O HTTP também

envia uma explicação textual com cada código numérico, que é inclusa apenas para

fins descritivos; e o código numérico é utilizado para todo o processamento. Alguns

códigos de estado comuns são apresentados no Quadro 3. (GOURLEY; TOTTY,

2002)

Código de Estado Descrição

200 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 Estado

Fonte: Gourley e Totty (2002)

2.5.6 Mensagens

Mensagens HTTP são simples sequências de caracteres orientadas por

linha. Devido ao fato de serem texto simples, não binários, eles são fáceis para

seres humanos lerem e escreverem. Mensagens HTTP enviadas de clientes web

aos servidores são denominados mensagens de pedido. Mensagens de servidores a

clientes são chamados de mensagens de resposta. Não existem outros tipos de

mensagens HTTP e o formato de ambas as mensagens é similar. (GOURLEY;

TOTTY, 2002)

Segundo Gourley e Totty (2002) as mensagens HTTP consistem de três

partes:

Linha de início: A primeira linha da mensagem é a linha de início, indicando

o que fazer para um pedido e o que aconteceu para um recurso;

Campos de cabeçalho: Nenhum ou muitos campos de cabeçalho seguem a

linha 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çalhos

terminam com uma linha em branco;

Corpo: Após a linha branca existe um corpo de mensagem opcional

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

20

contendo qualquer tipo de dado. Corpos de pedido carregam dados para o servidor

web; corpos de resposta carregam dados para o cliente. Diferentemente da linha de

início e dos cabeçalhos, que são textuais e estruturados, o corpo pode conter dados

binários arbitrários (por exemplo, imagens, vídeos etc.), assim como podem conter

texto simples.

2.6 OPENID

OpenID fornece sites e serviços com um protocolo descentralizado de

autenticação de usuários através de uma ampla variedade de provedores. Isso

significa que um site integrando OpenID pode permitir que seus usuários se

autentiquem utilizando, por exemplo, suas contas do Yahoo!, Google ou AOL. O site

em questão pode não apenas evitar a criação de seu próprio sistema de

autenticaçã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 diversas

extensões através do qual um provedor de OpenID pode permitir que as aplicações

obtenham informações do perfil de um usuário ou integrar camadas adicionais de

seguranç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 é o

que dá a um site consumidor simples a possibilidade de autenticação a partir de

contas do Yahoo! e Google, enquanto outro site pode querer que seus usuários se

autentiquem através do Blogger ou Wordpress. Cabe ao consumidor OpenID (um

site ou serviço) escolher quais métodos de autenticação ele gostaria de oferecer aos

seus usuários. (LEBLANC, 2011)

Cada provedor de OpenID possui um endereço de OpenID associado com

seu sistema de autenticação para habilitar o método de descoberta requirido para o

processo de autenticação. Existem diversos provedores de OpenID, entre os

principais estão o Google, Yahoo!, Flickr, Wordpress, AOL, Blogger, MySpace,

MyOpenID entre outros. (LEBLANC, 2011)

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

21

2.6.1 Fluxo de Autenticação

Segundo Leblanc (2011) o OpenID define um fluxo padronizado pelo qual

um usuário pode se autenticar em um site de terceiro de retransmissão de um

provedor de OpenID como Yahoo! ou Google. Existem três participantes no fluxo de

autenticaçã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 passos

diferentes, iniciando quando o usuário escolhe um provedor para se autenticar e

terminando com o resultado de sucesso/falha do provedor quando o usuário tenta se

autenticar. No primeiro passo é solicitada a autenticação do usuário, passando uma

URI identificadora de OpenID. No segundo passo é feita a descoberta do endpoint

do OpenID. No terceiro passo é solicitado ao usuário que o mesmo se autentique

com sua conta. E finalmente, no quarto passo, é fornecido um estado de

sucesso/falha baseado na autenticação. (LEBLANC, 2011)

2.7 CAS

Central Authentication Service (CAS) é um portal de autenticação única de

código aberto, que fornece controle de acesso centralizado, e autenticação para

recursos baseados na web dentro de uma organização. Mularien (2010) destaca que

os 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

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

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 o

servidor CAS e a aplicação segurada, com a necessidade de bastante troca de

dados antes que a confiança do usuário possa ser estabelecida. O resultado desta

complexidade é um protocolo de autenticação única que é difícil para falsificar

através de técnicas comuns (assumindo que outras precauções de segurança foram

tomadas, como o uso de Secure Sockets Layer e monitoração de rede).

(MULARIEN, 2010)

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

23

2.8 OAUTH

Open Authentication (OAuth), é um padrão aberto para autorização de

aplicaçõ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 de

desenvolvedores web de diversos websites, que queriam resolver o problema

comum de permitir a delegação de acesso a recursos protegidos. O protocolo OAuth

resultante foi estabilizado na versão 1.0 em Outubro de 2007, e revisado em Junho

de 2009 (Revisão A), conforme publicado online. (OAUTH, 2010)

O protocolo OAuth fornece um método para que clientes acessem recursos

do servidor em nome de um resource owner (dono de recursos). Também é possível

fornecer um processo para usuários finais autorizarem acesso de terceiros aos

recursos 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 precisa

obter permissão do dono de recursos. Essa permissão é expressada na forma de

um token e de uma chave secreta correspondente. O objetivo do token é fazer com

que não haja necessidade do dono de recursos compartilhar suas credenciais com o

sistema. Diferentemente das credenciais do dono de recursos, tokens podem ser

emitidas com um escopo restrito e um tempo de vida limitado, e podem ser

revogados independentemente. (OAUTH, 2010)

2.8.1 Terminologia

O protocolo OAuth apresenta diversos conceitos com um significado

particular 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

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

24

autenticadas. (OAUTH, 2010)

Recurso protegido: Um recurso de acesso restrito que pode ser obtido de

um servidor utilizando uma requisição OAuth autenticada. (OAUTH, 2010)

Proprietário do recurso: Uma entidade capaz de acessar e controlar

recursos protegidos utilizando credenciais para se autenticar no servidor. (OAUTH,

2010)

Credenciais: Credenciais são um par composto de um identificador único e

um segredo correspondente compartilhado. O OAuth define três classes de

credenciais: cliente, temporário e token, usados, respectivamente, para identificar e

autenticar o cliente que está fazendo a requisição, a requisição de autorização, e a

concessão do acesso. (OAUTH, 2010)

Token: Um identificador único emitido pelo servidor e usado pelo cliente

para associar requisições autenticadas com o proprietário do recurso cuja

autorização é solicitada ou tenha sido obtida pelo cliente. Tokens possuem uma

chave secreta compartilhada correspondente que é utilizada pelo cliente para

estabelecer a sua posse do token, e sua autoridade para representar o proprietário

do recurso. (OAUTH, 2010)

2.8.2 Benefícios

Segundo Leblanc (2011, p. 319) o protocolo OAuth oferece algumas

melhorias 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

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

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 cliente

pelo proprietário de recurso. Tipicamente, credenciais de token são emitidos pelo

servidor na requisição do proprietário de recurso, após a autenticação da identidade

do 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 servidor

prover as credenciais de token. Uma delas é utilizando a redirecionamentos HTTP

no agente de usuário do proprietário de recurso. Este redirecionamento inclui três

etapas:

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 serem

utilizadas para obter as credenciais de token. É recomendado que as credenciais

temporárias tenham um tempo de vida limitado. Servidores devem permitir que os

proprietários de recursos possam revogar as credenciais de token após elas serem

emitidas aos clientes. (OAUTH, 2010)

De acordo com OAuth (2010, p. 8), para permitir que o cliente execute as

três etapas, o servidor deve anunciar os endereços dos seguintes endpoints:

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

26

Pedido de Credencial Temporária: O endpoint utilizado pelo cliente para

obter um conjunto de credenciais temporárias.

Autorização do Proprietário do Recurso: Endpoint onde o proprietário do

recurso é redirecionado para garantir a autorização.

Pedido de Token: O endpoint utilizado pelo cliente para requisitar um

conjunto 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 fazendo

pedido HTTP “POST” autenticado para o endpoint de Pedido de Credencial

Temporário. O cliente constrói uma URI de pedido adicionando o parâmetro

obrigatório “oauth_callback”, que define um endereço para o qual o servidor

redirecionará o proprietário de recurso após o processo de autorização do

proprietá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 e

deve 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 servidor

deve exigir o uso de um mecanismo de camada de transporte como o Secure

Sockets 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 com

um conjunto de credenciais temporárias (na forma de um identificador e um segredo

compartilhado). As credenciais temporárias são incluídas no corpo da resposta

HTTP utilizando o tipo de conteúdo “application/x-www-form-urlencoded” com um

código de estado 200, que significa sucesso na requisição. (OAUTH, 2010)

Segundo OAuth (2010) a resposta contém os seguintes parâmetros

obrigatórios:

• oauth_token: O identificador de credenciais temporárias;

• oauth_token_secret: O segredo compartilhado de credenciais

temporárias;

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

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 credenciais

não são as credenciais de token, mas são utilizadas nas próximas duas etapas de

uma maneira similar às credenciais de token. O Quadro 4 contém um exemplo de

resposta HTTP de credenciais temporárias. (OAUTH, 2010)

HTTP/1.1 200 OK Content-Type: application/x-www-form-urlencoded oauth_token=hdk48Djdsa&oauth_token_secret=xyz4992k83j47x0b&oauth_callback_confirmed=true

Quadro 4: Exemplo de Resposta HTTP de Credenciais Temporárias

Fonte: OAuth (2010)

2.8.5 Autorização do proprietário do recurso

Antes do cliente solicitar o conjunto de credenciais de token do

servidor, ele deve enviar o usuário ao servidor para autorizar a requisição. O cliente

constrói uma URI de pedido para o endpoint de Autorização do proprietário do

recurso, adicionando o parâmetro obrigatório “oauth_token”, que contém o

identificador 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ída

utilizando uma resposta HTTP de redirecionamento, ou outros meios disponíveis

utilizando o agente de usuário do proprietário de recursos. A requisição deve utilizar

o método HTTP “GET”. (OAUTH, 2010)

Por exemplo, o cliente redireciona o agente de usuário do proprietário do

recurso para efetuar o seguinte pedido HyperText Transfer Protocol Secure (HTTPS)

apresentado no Quadro 5.

GET /authorize_access?oauth_token=hdk48Djdsa HTTP/1.1 Host: server.example.com

Quadro 5: Exemplo de pedido de autorização

Fonte: OAuth (2010)

Independente da maneira na qual o servidor processa o pedido de

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

28

autorização, incluindo ou não um canal seguro, o servidor sempre deverá verificar

primeiramente a identidade do proprietário do recurso.

Ao pedir para o proprietário de recurso para autorizar o pedido de acesso, o

servidor deve apresentar ao proprietário de recurso informações sobre o cliente que

está solicitando o acesso baseado na associação das credenciais de acesso

temporárias com a identidade do cliente. Ao exibir qualquer uma dessas

informaçõ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, o

servidor redireciona o usuário para o endereço de retorno, caso algum tenha sido

informado 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 para

completar o processo, o servidor deve gerar um código de verificação: um valor não

adivinhável é passado para o cliente através do proprietário de recurso e obrigatório

para concluir o processo. O servidor constrói uma URI de solicitação adicionando os

seguintes 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 servidor

deve acrescentar os parâmetros do OAuth no final da consulta existente. Por

exemplo, o servidor redireciona o agente de usuário do proprietário do recurso para

efetuar a seguinte requisição HTTP:

GET /cb?x=1&oauth_token=hdk48Djdsa&oauth_verifier=473f82d3 HTTP/1.1Host: client.example.net

Quadro 6: Redirecionamento para o endereço de retorno com parâmetros do Oauth

Fonte: OAuth (2010)

Se o cliente não forneceu um endereço de retorno, o servidor deve exibir o

valor do código de configuração, e instruir o proprietário de recurso para informar

manualmente o cliente que a autorização está completa. Se o servidor conhece um

cliente que está rodando em um dispositivo limitado, ele deve garantir que o valor de

verificação é acessível para o registro manual.

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

29

2.8.6 Credenciais de Token

O cliente obtém um conjunto de credenciais de token do servidor fazendo

um pedido HTTP “POST” autenticado para o endpoint de Pedido de token. O cliente

constrói uma URI de pedido adicionando o seguinte parâmetro obrigatório:

oauth_verifier: Código de verificação recebido do servidor no passo

anterior.

Ao efetuar o pedido, o cliente faz a autenticação utilizando suas credenciais

(identificadores do cliente) assim como as credenciais temporárias. As credenciais

temporárias são utilizadas como um substituto para as credenciais de token no

pedido autenticado e transmitidas utilizando o parâmetro “oauth_token”.

Uma vez que o pedido resulta na transmissão das credenciais em texto puro

na resposta HTTP, o servidor deve requerer o uso de um mecanismo de camada de

transporte como o SSL (ou um canal seguro com proteções equivalentes). Um

exemplo de um pedido de credenciais de token utilizando um pedido HTTPS é

apresentado no Quadro 7.

POST /request_token HTTP/1.1 Host: server.example.com Authorization: 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 Token

Fonte: OAuth (2010)

O servidor deve verificar a validade do pedido, garantir que o proprietário do

recurso autorizou o fornecimento de credenciais de token ao cliente, e garantir que

as credenciais temporárias não foram expiradas ou usadas anteriormente. O

servidor deve verificar também o código de verificação recebido do cliente. Se o

pedido é válido e autorizado, as credenciais de token são incluídas no corpo da

resposta 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 de

resposta contendo credenciais de token é apresentado no Quadro 8:

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

30

oauth_token: O identificador do token.

oauth_token_secret: O segredo compartilhado do token.

HTTP/1.1 200 OK Content-Type: application/x-www-form-urlencoded oauth_token=j49ddk933skd9dks&oauth_token_secret=ll399dj47dskfjdk

Quadro 8: Resposta do servidor com as credenciais de token

Fonte: OAuth (2010)

O servidor deve reter o escopo, duração e outros atributos aprovados pelo

proprietário de recurso, e reforçar essas restrições ao receber uma requisição de um

cliente com as credenciais de token emitidas.

Uma vez que o cliente receba e armazene as credenciais de token, ele pode

proceder para acessar recursos protegidos em nome do proprietário de recurso

fazendo requisições autenticadas utilizando as credenciais de cliente em conjunto

com as credenciais de token recebidas.

2.8.7 Requisições Autenticadas

Alguns métodos especiais do protocolo HTTP permitem que clientes façam

requisições autenticadas, permitindo que eles ganhem acesso a recursos protegidos

utilizando suas credenciais (tipicamente o par usuário/senha), que permitem que o

servidor verifique a autenticidade dos mesmos. Utilizar estes métodos para

delegaçã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 de

credenciais com cada requisição, um para identificar o cliente e outro para identificar

o proprietário do recurso. Antes do cliente ter permissão para fazer uma requisição

autenticada em nome do proprietário do recurso, ele deve obter um token autorizado

pelo 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 um

segredo compartilhado único ou um par de chaves RSA. Antes de fazer requisições

autenticadas, o cliente estabelece esse conjunto de credenciais com o servidor. O

processo e os requisitos para prover essas credenciais variam de acordo com o

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

31

implementador do protocolo. (OAUTH, 2010)

De acordo com a especificação de OAuth (2010), uma requisição

autenticada inclui diversos parâmetros do protocolo. Cada nome de parâmetro inicia

com 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 de

parâ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

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

32

suas credenciais de cliente, credenciais de token, a estampa de tempo atual, um

valor 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+q

Quadro 9: Pedido HTTP

Fonte: OAuth (2010)

oauth_consumer_key: 9djdj82h48djs9d2oauth_token: kkk9d7dh3k39sjv7oauth_signature_method: HMAC-SHA1oauth_timestamp: 137131201oauth_nonce: 7d8f3e4a

Quadro 10: Parâmetros de Protocolo

Fonte: OAuth (2010)

O cliente adiciona parâmetros do protocolo para o pedido utilizando o campo

de 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ção

Figura: 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)

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

33

POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Authorization: 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+q

Quadro 12: Pedido HTTP autorizado completo

Fonte: OAuth (2010)

2.8.8 Experiência do Usuário

Quando o OAuth é utilizado em uma aplicação, a experiência para o usuário

final que interage com a aplicação é muito menos intrusiva e complicada do que o

processo necessário para o desenvolvimento da mesma. (LEBLANC, 2011)

Implementações da tela de permissão, onde usuários permitem que uma

aplicação façam ações em seu nome, podem variar muito dependendo da

plataforma onde ela é implementada, mas o princípio básico é o mesmo. A

plataforma exibe uma página contendo uma informação básica sobre a aplicação e

fornece meios para que o usuário possa permitir ou negar que a aplicação utilize

seus dados pessoais. (LEBLANC, 2011)

Leblanc (2011, p. 327) destaca as telas de autorização de algumas

plataformas que utilizam o OAuth, na Figura 1 é apresentada a tela de autorização

do Twitter e na Figura 2 é apresentada a tela do Yahoo!.

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

34

Figura 1: Tela de Autorização do Twitter

Fonte: Leblanc (2011)

No caso da implementação do Yahoo!, o usuário primeiramente deve

informar seu usuário e senha e, posteriormente, ele será redirecionado para a tela

de permissão. Nesta tela também são exibidas as aplicações necessárias para o

fornecimento de dados da aplicação que está requisitando autorização. (LEBLANC,

2011)

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

35

Figura 2: Tela de Autorização do Yahoo!

Fonte: Leblanc (2011)

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

36

3 PROCEDIMENTOS METODOLÓGICOS

Para a realização do estudo de caso proposto neste trabalho foram adotados

métodos que envolvem desde a parte de pesquisa até os estudos tecnológicos e a

utilização de uma estrutura física para o correto funcionamento das implementações.

O objetivo deste capítulo é descrever detalhadamente cada um dos procedimentos

adotados, assim como as principais justificativas das escolhas tecnológicas deste

estudo.

3.1 PROCEDIMENTOS DE PESQUISA

Tratando-se dos procedimentos de pesquisa será utilizado, inicialmente, a

pesquisa bibliográfica, por ser “[...] desenvolvida com base em material já elaborado

constituí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 as

variáveis que seriam capazes de influenciá-lo, definir as formas de controle e de

observaçã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 essas

pesquisas 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 a

torná-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

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

37

11.10, os navegadores de internet Opera 11 e Chromium, e a rede utilizada é a Fast

Ethernet 100.

A configuração de hardware do notebook utilizado para o desenvolvimento e

testes é 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 deste

trabalho foram utilizadas diversas tecnologias que, juntas, fornecem o correto

funcionamento do protocolo OAuth e das funcionalidades desenvolvidas em cada

aplicação.

3.3.1 Java

De acordo com a Sun Microsystems (atualmente Oracle) o Java é um

ambiente de programação simples, robusto, orientado a objetos, independente de

plataforma, dinâmico e de propósito geral. Esta definição permitiu ao Java crescer e

se expandir para diversos nichos. Atualmente ele é utilizado em plataformas

empresariais e em pequenos dispositivos. Para que o Java suporte esta gama de

ambientes diversas interfaces de programação de aplicações (APIs) e versões foram

desenvolvidas. (SPELL, 2005)

Segundo Spell (2005) a arquitetura Java completa é composta por quatro

componentes:

• 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).

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

38

3.3.2 Spring MVC e Spring Security

O Spring Framework é uma solução leve utilizada para desenvolver

aplicações corporativas. Ele é modular, permitindo a utilização apenas das partes

necessárias, sem a necessidade de utilizar o pacote completo. O Spring Framework

suporta gerenciamento transacional declarativo, acesso remoto à lógica com RMI e

web services, e diversas opções de persistência de dados. Além disso ele oferece

um framework MVC completo, e habilita a utilização de linguagem orientada a

aspectos (AOP) transparentemente no software. O componente de Inversion of

Control (IoC) provê um meio de injetar dependências de uma classe utilizando meios

formais de compor componentes diferentes em uma aplicação totalmente funcional

pronta para utilização. (SPRING, 2010)

Spring MVC é um componente do framework projetado para auxiliar e

facilitar o desenvolvimento de aplicações web, oferecendo uma ferramenta para

desenvolver aplicações flexíveis e com baixo acoplamento, assim como o próprio

Spring Framework é. Ele fornece funcionalidades de gerenciar o estado, fluxo de

trabalho, validação. (WALLS, 2011)

Spring Security é outro componente do framework que oferece diversos

recursos que permitem que práticas de segurança comuns possam ser declaradas

ou configuradas de uma forma direta e declarativa. Com o Spring Security é possível

mapear usuários a classes da aplicação, definir níveis de autorização a papéis de

usuário, definir papéis de usuários às classes, aplicar regras de autenticação por

todos os recursos da aplicação, assim como regras de autorização e prevenir tipos

comuns 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 do

protocolo OAuth ao Spring Security. Ele suporta a especificação 1.0 e a 2.0, que

ainda está em fase de desenvolvimento. Ele suporta componentes para consumir e

fornecer 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

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

39

ambientes Java. O termo Mapeamento Objeto-Relacional refere-se à técnica de

mapear dados de um modelo de representação em objetos para um modelo de

representação relacional (e vice e versa). Além do Hibernate lidar com este

mapeamento ele também provê recursos para consulta e obtenção de dados. O

Hibernate ajuda no encapsulamento de código SQL específico dos bancos de dados,

abstraindo os mesmos do desenvolvedor, e fornece integração com diversos

sistemas gerenciadores de banco de dados. (HIBERNATE, 2010)

3.3.4 PHP

PHP é uma linguagem de script amplamente utilizada, especialmente

adequada para o desenvolvimento web e pode ser incorporada ao HTML. O que

diferencia o PHP de linguagens como o Javascript é que ele é executado no

servidor, gerando o código HTML final que será enviado ao cliente. O cliente

receberá o resultado da execução do script, mas não saberá o código que gerou

este resultado. O PHP pode ser utilizado para, entre outras coisas, coletar dados de

formulários, gerar conteúdo de páginas dinamicamente, enviar e receber cookies e

manipular banco de dados. (PHP, 2011)

3.3.5 Zend Framework

Zend Framework é um framework de código aberto utilizado no

desenvolvimento de aplicações e serviços web utilizando a linguagem PHP na

versão 5. O framework é desenvolvido utilizando um código totalmente orientado a

objetos. A estrutura de componentes fornecida pelo Zend Framework foi projetada

de forma a diminuir a dependência entre eles, permitindo a utilização de

componentes individuais. O framework também fornece uma implementação robusta

e 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ção

e autorização, incluindo suporte ao protocolo OAuth. (ZEND, 2010)

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

40

3.3.6 Play Framework

O Play Framework é uma alternativa limpa para o conjunto inchado do Java

Enterprise. Seu principal foco é a produtividade do desenvolvedor e sua meta é

arquiteturas REST. O Play é um ótimo auxiliar para o desenvolvimento ágil de

software. Seu principal objetivo é facilitar o desenvolvimento de aplicações web e, ao

mesmo tempo, se manter alinhado ao Java. Ele foi escrito puramente em Java, e

mantém bibliotecas e ferramentas comuns deste ecossistema. O framework compila

os fontes Java diretamente e recarrega-os na JVM sem a necessidade de reiniciar o

servidor. 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 API

de 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). Essas

tecnologias são a evolução das tecnologias utilizadas no dia a dia de envolvidos com

a internet, e existem para ajudar na construção de aplicações web modernas e

inovadoras. Diversas novas funcionalidades ajudam na melhora da sintaxe da

linguagem, assim como adicionam um suporte maior a animações interoperáveis

(independentes de plugins de terceiros), trazem novas funcionalidades para

utilização de sockets, armazenamento offline, melhorias de formulários e muito mais.

(HOGAN, 2010)

O CSS3 adiciona novos seletores para melhorar a estilização de

componentes, como, por exemplo, até a identificação de colunas pares e ímpares de

uma tabela. A nova versão do CSS também traz efeitos visuais sofisticados, como

sombras, gradientes, cantos arredondados e etc. Ambas as novas tecnologias ainda

sã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)

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

41

3.3.8 MySQL

O software MySQL provê um servidor de banco de dados Structured Query

Language (SQL) robusto, multi-usuário, rápido e eficaz. Ele é indicado para sistemas

em 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 Oracle

e uma versão de código-aberto. (MYSQL)

3.4 JUSTIFICATIVAS TECNOLÓGICAS

O protocolo OAuth foi escolhido principalmente por sua facilidade de

implementação, tanto na parte servidor quanto para os consumidores. Quando

comparado ao OpenID e CAS, a implementação de um servidor de recursos se

mostra menos complexa. Outro motivo é que grandes empresas utilizam o OAuth

em casos de sucesso, como o Facebook ou Twitter. E, finalmente, o protocolo OAuth

utiliza padrões abertos como HTTP junto com todos os seus recursos e permite

grande flexibilidade com relação a mecanismos de criptografia, e exigências de

obrigatoriedade 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 de

OAuth principalmente por ser uma das mais utilizadas no ambiente corporativo, que

é o ambiente ideal para a implantação do OAuth, principalmente por, na maioria dos

casos, um ambiente corporativo ser dividido em diversas aplicações independentes

entre 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 e

JPA com Hibernate.

O Spring e Spring Security com o módulo OAuth foram utilizados para prover

meios de autenticação, segurança das funcionalidades, recursos web para cadastro

de usuários, injeção de dependências, mapeamento de URL e gerencia de beans. O

Hibernate foi o escolhido por suportar a especificação Java Persistence API (JPA),

suportar diversos bancos de dados e fornecer recursos para consultas e

mapeamento objeto-relacional.

O PHP foi utilizado, em conjunto com o Zend Framework, para desenvolver

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

42

a aplicação de controle de finanças, e ambos foram escolhidos pela baixa curva de

aprendizado, por sua robustez e produtividade. O Zend Framework é desenvolvido

pela Zend, principal mantenedora da linguagem PHP, e é muito bem projetado, com

uma estrutura de componentes similar ao Spring.

O Play! Framework foi escolhido devido à sua simplicidade, alta

produtividade, sintaxe limpa de templates (graças ao Groovy), integração nativa com

JPA, 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ção

das aplicações. Foram utilizados seletores avançados do CSS3, validação nativa do

HTML5, novas tags, cantos arredondados, sombras e gradientes.

O banco de dados MySQL foi escolhido por sua fácil integração com cada

uma das tecnologias utilizadas nas aplicações.

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

43

4 IMPLEMENTAÇÃO

Este capítulo descreve as três aplicações desenvolvidas para demonstrar o

funcionamento do protocolo OAuth. Cada aplicação foi construída em um escopo

separado visando demonstrar a capacidade de integração das tecnologias com o

protocolo OAuth e os recursos básicos necessários para um provedor de

autenticação. Foram elaboradas as seguintes aplicações, explanadas mais

detalhadamente 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 o

endpoint de autenticação para consumidores OAuth. Sua estrutura foi definida

utilizando o framework Spring MVC, com o padrão arquitetural Model-View-

Controller (MVC), além de definir serviços, entidades e repositórios conforme

apresentado na Figura 3.

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

44

4.1.1 Configuração do Spring Security e OAuth

Para fornecer os recursos de segurança e proteção de acessos foi utilizado

o 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 de

configuração necessários para a aplicação. O Quadro 13 apresenta o arquivo de

configuração utilizado na aplicação.

Figura 3: Arquitetura Definida

Fonte: Autoria Própria

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

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 Security

Fonte: Autoria Própria

Os principais pontos a se destacar neste arquivo de configuração são os

parâmetros com o prefixo “security:”. Primeiramente são definidos dois endpoints

que não terão segurança: a pasta de imagens, arquivos de folhas de estilos e

javascript nomeada “resources”, e o endereço utilizado para acessar o formulário de

autenticação “/user/login”.

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

46

A próxima etapa é adicionar restrições para que os endereços internos do

sistema só possam ser acessados por usuários autenticados. Os endereços que

contém as palavras “oauth”, “request_token_authorized.jsp”, “dashboard”,

“index.jsp”, “user/profile”, “user/info” serão protegidos pelo framework de

segurança, exigindo que um usuário esteja autenticado para acessar algum destes

endereç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 configurar

o serviço que fornece os meios de autenticação do usuário. Neste caso foi definido

um serviço customizado, contendo o código apresentado no Quadro 14, assim como

um bean para criptografia de senha.

As próximas linhas definem a configuração do provedor de OAuth da

aplicação. É necessário definir o serviço que fornece dados dos consumidores

suportados pela aplicação. Somente os consumidores definidos na tag “consumer-

details-service” poderão consumir o serviço de autenticação, requisitando a

autorização de acesso pelo proprietário do recurso autenticado. Para este trabalho

foram definidos dois consumidores: uma aplicação de finanças e outra de agenda de

contatos.

O parâmetro “token-services-ref”, define o serviço que fornecerá as

funcionalidades 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 da

biblioteca Spring Security OAuth, que armazena em memória os tokens gerados e

utiliza mecanismos de tempo para validar um token utilizado para uma tentativa de

autorização ou para uma requisição autenticada.

Os demais parâmetros definidos na tag “provider” definem os endpoints

para, respectivamente, a requisição de tokens temporários, a autenticação

autorizada por um proprietário do recurso, a página de autorização de um

consumidor pelo proprietário do recurso, a página de confirmação de que o acesso

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

47

foi concebido (caso não seja definido o parâmetro “oauth_callback”) e o endereço

para 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 de

autenticação de usuários, que nada mais é do que um bean que implementa a

interface UserDetailsService e o método loadByUsername. O Quadro 14 mostra

um trecho do serviço implementado, que busca na base de dados por um nome de

usuá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ário

Fonte: Autoria Própria

O banco de dados da aplicação é composto apenas por uma tabela de

usuários e para manipular esta tabela foi implementado um repositório, que utiliza o

EntityManager fornecido pelo Hibernate para efetuar uma consulta baseando-se no

nome de usuário passado como parâmetro. O código deste repositório é

apresentado no Quadro 15.

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

48

@Repository public class UserRepository extends AbstractRepository<User> { public User findByUsername(String username) { try { TypedQuery<User> query = this.entityManager.createQuery("select u from 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ários

Fonte: 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 permitem

que o próprio navegador de internet faça a validação dos campos, sem a

necessidade de programar Javascript para essa funcionalidade. Também foram

utilizadas 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 Login

Fonte: Autoria Própria

O resultado deste código é apresentado na Figura 4. Esta tela de

autenticação é apresentada ao usuário ao se acessar alguma das aplicações

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

49

desenvolvidas e permite que o usuário forneça suas credenciais de acesso,

prosseguindo com o fluxo de autorização.

4.1.3 Confirmação do Proprietário do Recurso

Para que o consumidor possa utilizar os dados do proprietário do recurso o

OAuth exige que, após efetuar a autenticação, o provedor apresente uma tela

solicitando ao proprietário do recurso se ele autoriza ou não o acesso do consumidor

aos seus dados. Para esta funcionalidade foi desenvolvido um controlador, que

responde à 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 da

aplicação, validar as credenciais e tokens temporários, e, também, revogar um

acesso a um token temporário. O Quadro 17, apresenta o código implementado para

este controlador.

Figura 4: Tela de autenticação

Fonte: Autoria Própria

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

50

@Controller public 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 de requisiçã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 Acesso

Fonte: Autoria Própria

A primeira etapa é verificar se os parâmetros de token foram informados na

requisição, após isso o token é obtido do serviço definido no arquivo de

configuração, e logo após, os dados do consumidor são obtidos. Caso em alguma

dessas etapas algum dado não seja informado, será lançada uma exceção e o

có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 do

consumidor.

O método de revogação de acesso, faz com que o token temporário expire

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

51

e, 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 do

recurso. Ele aponta o endereço para o endpoint definido de confirmação da

autorização do acesso. Caso exista o parâmetro “oauth_callback” o mesmo é

adicionado a um campo escondido do formulário, e internamente, o Spring Security

OAuth define este endereço como o ponto de redirecionamento após concluir o

processo 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 da aplica&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:out value="${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 Consumidor

Fonte: 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 do

proprietário do recurso autenticado, e as opções de autorizar ou revogar o acesso da

aplicação em questão.

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

52

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 Figura

6, que indica que o consumidor foi revogado com sucesso. Se o proprietário do

recurso autorizar o acesso do consumidor ele será redirecionado para as telas

principais do consumidor em questão. Essas telas são apresentadas na e .

4.2 APLICAÇÃO 1: AGENDA DE CONTATOS

A primeira aplicação desenvolvida tem como foco principal fornecer uma

agenda simples de contatos. Ela foi desenvolvida utilizando o Play! Framework, junto

com seu módulo OAuth, e permite que o usuário, após a autenticação e autorização

do 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

Figura 5: Tela de autorização

Fonte: Autoria Própria

Figura 6: Tela de acesso revogado

Fonte: Autoria Própria

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

53

definido em sessão e, caso não exista, redireciona o usuário para que o mesmo faça

autenticação como proprietário do recurso e autorize o consumidor a obter os dados

do perfil do usuário. O código do Quadro 19 apresenta o método do controlador que

faz essa verificação, simplesmente validando um parâmetro da sessão.

@Before static void checkAuthentication() throws Exception { if (session.get("user") == null) AuthenticationController.auth(); }

Quadro 19: Método de verificação de usuário logado

Fonte: Autoria Própria

Caso seja necessário efetuar a autenticação do proprietário do recurso com

o OAuth, o controlador de autenticação será executado, ficando responsável por

redirecionar o agente de usuário para o servidor Oauth, onde serão apresentadas ao

usuá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 OAuth

utilizando o módulo disponível para o Play Framework onde os seguintes parâmetros

de 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á os

dados de credenciais de token. E, após isso, o método authenticate, redireciona o

usuá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, apresentado

no Quadro 21.

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

54

public 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 OAuth

Fonte: Autoria Própria

O método de retorno, irá obter o parâmetro “oauth_verifier”, que contém o

código de verificação indicando que o token para o consumidor em questão foi

definido e autorizado. Após obter o código verificador, o cliente OAuth obtém as

credenciais de token para, a partir deste ponto em diante, fazer requisições

autenticadas em nome do proprietário do recurso. A requisição efetuada obtém as

informações do perfil do proprietário do recurso, para definir em sessão o código

identificador do mesmo, o nome real e o nome de usuário utilizado por ele. Em

seguida são utilizados os componentes do Play! Framework para mapear a resposta

JSON retornada pelo servidor a um objeto do tipo User, são armazenados os dados

do 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 OAuth

Fonte: Autoria Própria

Após concluir o fluxo de autorização e armazenar uma instância de User em

sessão é apresentada a tela principal do sistema ao usuário, ilustrada na Figura 7.

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

55

Nesta tela o usuário poderá ver com que credenciais se autenticou, e são

listados todos os contatos cadastrados pelo usuário autenticado. Ao acessar o botão

“Adicionar Novo” é apresentado o formulário de cadastro de um contato, conforme

apresentado na Figura 8.

Figura 7: Tela inicial da aplicação de contatos

Fonte: Autoria Própria

Figura 8: Tela para Adicionar um Contato

Fonte: Autoria Própria

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

56

4.3 APLICAÇÃO 2: CONTROLE DE FINANÇAS

A aplicação de controle de finanças tem como objetivo fornecer ao usuário o

cadastro de lançamentos de crédito e de débito e, baseando-se na soma dos

créditos e débitos, apresentar o saldo do mesmo, destacando se é positivo ou

negativo. Este aplicativo foi desenvolvido utilizando PHP 5.3 junto com o Zend

Framework e seus componentes Zend_Auth, Zend_Oauth_Consumer, Zend_Db e

Zend_Mvc. Assim como a aplicação de agenda de contatos, o controle de finanças

exige a autenticação e autorização do proprietário do recurso e, após isso, guarda

em sessão os dados de seu perfil. O banco de dados utilizado define apenas a

tabela de contas.

Seguindo o mesmo modelo da aplicação de contatos, o controle de finanças

faz a verificação se existe um usuário autenticado e, caso não exista, redireciona o

usuário para um controlador de autenticação que implementa um consumidor OAuth.

O Quadro 22 apresenta o plugin, configurado na pilha de plugins de controladores

do Zend Framework, que faz a verificação se o componente Zend_Auth possui uma

identidade definida e, caso não possua, muda a requisição para o controlador de

autenticação.

class FernandoMantoan_Auth_OAuth_Plugin extends Zend_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 autenticado

Fonte: Autoria Própria

Os parâmetros para a configuração do componente

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

57

Zend_Oauth_Consumer são definidos no arquivo de configuração application.ini

da 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 OAuth

Fonte: Autoria Própria

O controlador de autenticação, apresentado no Quadro 24, é responsável

por criar uma instância do componente Zend_Oauth_Consumer, utilizando os

parâmetros de configuração definidos no arquivo de configuração, estes sendo

obtidos 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 os

parâmetros do OAuth, que definem o endereço de retorno, o endereço do servidor

OAuth, a chave de consumidor e o segredo de consumidor compartilhado. Após

instanciar o componente, é definido o endereço de autorização de consumidores do

servidor 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ção

Fonte: Autoria Própria

O método loginAction ficará responsável por utilizar o componente

Zend_Oauth_Consumer para obter o token temporário, armazená-lo em sessão e

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

58

redirecionar o proprietário do recurso para que o mesmo inicie o processo de

autorização. Após autorizar a aplicação, o método callbackAction, apresentado no

Quadro 25 é executado. Este método obtém o token temporário da sessão, obtém

os parâmetros passados por GET no cabeçalho HTTP, e, caso os parâmetros sejam

vá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 os

parâmetros de configuração do serviço que obtém os dados do perfil do proprietário

do recurso autenticado são obtidos, para efetuar uma requisição POST que obtém

os dados do perfil em JSON. Após obter os dados, os mesmos são convertidos a um

objeto do tipo stdClass do PHP, e são armazenados na sessão do componente

Zend_Auth. Após todo o processo estar concluído, o usuário é redirecionado para a

tela 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ção

Fonte: Autoria Própria

Similarmente à aplicação de Agenda de Contatos, quando o processo de

autorizaçã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.

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

59

Nesta tela é apresentado ao usuário o nome com que ele se autenticou e os

dados de suas finanças, junto com um balanço calculado a partir da diferença entre

os 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 se

acessar o botão “Adicionar Nova” o usuário poderá cadastrar um novo lançamento

no formulário apresentado na Figura 10.

Figura 9: Tela inicial da aplicação de finanças

Fonte: Autoria Própria

Figura 10: Tela para adicionar um lançamento

Fonte: Autoria Própria

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

60

5 CONSIDERAÇÕES FINAIS

A segurança de uma aplicação é um ponto crucial para garantir o sigilo dos

dados dos usuários e para fornecer uma aplicação robusta e confiável. Ao se

centralizar a base de dados de um usuário a algum protocolo que não exija que o

mesmo trafegue suas credenciais entre diversas aplicações, essa segurança é ainda

maior, 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 dos

consumidores autorizados pelo proprietário do recurso. Este protocolo é amplamente

utilizado no mercado, tendo como aplicações famosas o Twitter, Facebook,

aplicativos do Google como Calendar e Gmail, além de outras grandes corporações

do mercado.

Um reflexo da fama do OAuth pôde ser percebido pela quantidade de

bibliotecas disponíveis, não só para as linguagens escolhidas no escopo desse

trabalho, mas para outras tecnologias como .NET, Python, Perl e outras. Com essas

bibliotecas é possível ganhar produtividade no desenvolvimento de provedores e

consumidores de OAuth, pois elas escondem toda a lógica principal da utilização do

protocolo e, além disso, fornecem meios fáceis e intuitivos para customizar outras

regras, como, por exemplo, a de expiração de tokens.

Uma conclusão que também vale ressaltar é a de transparência para o

usuário. Para o usuário, tudo que está acontecendo internamente pelas aplicações

não têm suma importância, ele vê a tela de autenticação principal e centralizada, e a

fácil integração das aplicações com o provedor da autenticação. Além disso, ele tem

total controle sobre o que poderá acessar seus dados, e, além de esse controle,

também os desenvolvedores e administradores podem gerenciar quais

consumidores podem efetuar uma tentativa de utilização do provedor OAuth.

5.1 TRABALHOS FUTUROS

Os trabalhos futuros deste trabalho estão relacionados, principalmente, a

adicionar novas funcionalidades à estrutura desenvolvida. Estas funcionalidades não

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

61

foram incluídas por fugirem do escopo do trabalho, porém são essenciais para um

provedor 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, se

tornar uma especificação estável, uma melhoria importante é a atualização da

estrutura para utilizar esta versão.

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

62

REFERÊNCIAS

CORREIA, 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: O'Reilly

Media, 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 Tomorrow's Standards

Today. Dallas: Pragmatic Bookshelf, 2010.

LEBLANC, Jonathan. Programming Social Applications. Sebastopol: O'Reilly

Media, 2011.

MULARIEN, Peter. Spring Security 3: Secure your web applications against

malicious intruders with this easy to follow practice guide. Birmingham: Packt

Publishing, 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 28

nov. 2011.

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

63

PLAY. 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: Manning

Publications, 2011.

ZEND. Zend Framework Introduction. Disponível em:

<http://framework.zend.com/manual/en/introduction.overview.html>. Acesso em 28

nov. 2011.