Captulo

1
Gerncia de Identidades Federadas em Nuvens: Enfoque na Utilizao de Solues Abertas
Guilherme Feliciano1 , Lucio Agostinho1 , Eliane Guimares2 , Eleri Cardozo1
1 Faculdade

de Engenharia Eltrica e de Computao Universidade Estadual de Campinas - UNICAMP

2 Centro

de Tecnologia da Informao Renato Archer 13083-970 - Campinas - SP

{gof,larocha,eleri}@dca.fee.unicamp.br, eliane.guimaraes@cti.gov.br

Abstract Cloud computing emerges as a new paradigm for the offering of services in the Web. The main idea is to transfer most of the processing and storage of user applications to a remote cloud of services. Although this approach leads to new business opportunities, the issue of security is still an open and difcult to solve problem. This is because in a cloud there are several applications available as services, many of which have their own access control systems. Furthermore, applications that support service compositions across distinct domains require authentication mechanisms that take into account this collaborative nature. This short course addresses the offering of federated services under an Identity Management perspective. The main concepts related to this subject are introduced in the context of cloud computing as well as the main solutions employed in open federated cloud environments. Finally, a case study in a eld of networked robotics that uses one of the solutions discussed in this short course is presented. Resumo A computao em nuvem surge como um novo paradigma para a oferta de servios na Web. A ideia principal transferir a maior parte do processamento e armazenamento das aplicaes dos usurios para uma nuvem remota de servios. Apesar desta abordagem trazer novas oportunidades de negcios, a questo da segurana ainda um problema em aberto e de difcil soluo. Isso porque em uma nuvem h diversas aplicaes

oferecidas como servios, sendo que muitas delas possuem seus prprios sistemas para controle de acesso. Alm disso, aplicaes que suportam a composio de servios entre domnios distintos exigem mecanismos de autenticao que levem em conta esta realidade colaborativa. Este minicurso explora a oferta de servios em federaes sob a tica da Gerncia de Identidades. So apresentados os principais conceitos relacionados a esse tema no contexto de computao em nuvem e as principais solues abertas empregadas em nuvens federadas. Ao nal, apresentado um estudo de caso no domnio da robtica em rede que utiliza uma das solues discutidas neste minicurso.

1.1. Introduo
No nal da dcada de 90, a Gerncia de Identidades (IdM - Identity Management) e a segurana da informao eram tratadas separadamente. Mais especicamente, a infraestrutura de IdM se destinava proviso de servios, especialmente servios centralizados de autenticao [Suess and Morooney 2009]. Nesta autenticao centralizada empregava-se tecnologias, tais como GSS-API (Generic Security Service Application Programming Interface), SASL (Simple Authentication and Security Layer) e/ou SSL/TLS (Secure Sockets Layer/Transport Layer Security) para o estabelecimento de um contexto de segurana entre dois pares comunicantes [Johansson 2009]. Neste cenrio, organizaes (empresas ou universidades) empregavam servios de diretrios baseados em LDAP (Lightweight Directory Access Protocol). Esses servios eram destinados a fornecer mecanismos de autenticao de forma centralizada, com o objetivo de facilitar a gerncia deste ambiente e prover uma forma de autenticao nica, conhecida como SSO (Single Sign-On). Como a identidade do usurio e o seu identicador geralmente eram os mesmos, um servio de e-mail, por exemplo, poderia utilizar o identicador do usurio como chave para armazenar todas as suas mensagens e conguraes de sua caixa postal no servio de diretrio [Johansson 2009]. Este modelo ainda muito utilizado e funciona bem em ambientes onde h uma nica organizao ou um nico servio de diretrio. As limitaes deste modelo centralizado surgem quando as organizaes precisam utilizar servios compartilhados, como por exemplo, em cenrios de B2B (business-to-business) ou necessitam fundir seus repositrios, como por exemplo, em fuses de empresas [Johansson 2009]. A falha deste modelo centralizado em tratar a autenticao em cenrios fora do domnio de uma organizao, ocorre em razo da falha do LDAP em fornecer um mecanismo de autenticao escalvel, que no prenda a organizao a uma soluo de um fabricante especco ou que no obrigue a organizao a permitir acesso externo s suas bases de dados [Johansson 2009]. Com a realidade da computao em nuvem e o surgimento da chamada Web 2.0, o cenrio para a IdM tornou-se mais complexo. A Web 2.0 aprofundou os conceitos de colaborao, interoperabilidade entre aplicaes e compartilhamento de informaes na Internet [Shelly and Frydenberg 2010]. A nuvem surge como uma alternativa para oferecer servios na Web de forma rpida, escalvel e com custos proporcionais demanda. A gerncia de identidades federadas (Federated IdM) tm como desao oferecer

uma infraestrutura que permita tanto aos usurios uma experincia de SSO, quanto aos administradores um mecanismo de autenticao e controle de acesso aos recursos federados entre parceiros [Olden 2011]. Segundo Stallings [Stallings 2011], um ambiente de gerncia de identidades federadas deve ter principalmente os seguintes elementos: autenticao, autorizao, logging, provisionamento de usurios, automao com workow, delegao, federao, SSO e mecanismo de password reset oferecido aos usurios. Esta infraestrutura formada por um sistema integrado de polticas, processos de negcios e tecnologias para o tratamento das identidades, denio, certicao e gerncia do ciclo de vida das identidades, mecanismos para troca segura e validao destas informaes e aspectos legais [Wangham et al. 2010]. A gerncia de identidades federadas tambm tm como meta permitir que os usurios possam estabelecer ligaes entre suas diversas identidades. Esta ligao lgica denominada federao de identidades [Bertino and Takahashi 2011]. Este minicurso tem como principal objetivo explorar os padres para gerncia de identidades federadas, bem como as tecnologias que implementam estes padres, com vistas aplicao em ambientes de computao em nuvem. As solues so apresentadas com um enfoque prtico e um estudo de caso ilustra o estabelecimento de uma nuvem federada para a realizao de experimentos robticos via rede. O captulo est dividido em sete sees, incluindo esta. A seo 1.2 apresenta os conceitos gerais relacionados computao em nuvem e suas tcnicas fundamentais. A seo 1.3 descreve os principais conceitos e tcnicas relacionados a gerncia de identidades federadas. A seo 1.4 apresenta o cenrio da gerncia de identidades federadas em ambientes de computao em nuvem, bem como seus principais desaos e tendncias da rea. A seo 1.5 apresenta os principais padres e solues para a implantao da gerncia de identidades federadas em ambientes de computao em nuvem. A seo 1.6 apresenta um estudo de caso detalhando um ambiente de computao em nuvem desenvolvido pelos autores e a motivao para a aplicao da gerncia de identidades federadas neste ambiente. Por m, a seo 1.7 resume os principais assuntos abordados e relata a experincia dos autores no uso de ferramentas para implantao de ambientes federados e integrao de recursos em nuvens.

1.2. Viso Geral sobre Computao em Nuvem

Computao em nuvem um modelo de computao distribuda que deriva caractersticas da computao em grades, no que diz respeito proviso de informao sob demanda para mltiplos usurios concorrentes. Um domnio oferece aplicaes na nuvem sem se preocupar com o local onde os servios esto sediados ou como eles so oferecidos. Fatias do poder computacional dos ns da rede so oferecidas, reduzindo os custos para fornecer uma infraestrutura prpria para prover os servios. Os recursos so cedidos apenas durante o perodo de uso, reduzindo o consumo de energia quando a utilizao no for mais necessria [Endo et al. 2010]. A virtualizao fornece a tecnologia base para muitas solues de nuvem. Alm disso, em muitas solues so oferecidos ambientes onde os usurios so capazes de escolher seus recursos virtualizados tais como linguagem de programao, sistema operacional e outros servios

personalizados. Os principais benefcios so a reduo dos custos de investimento em infraestrutura, dos custos operacionais e a escalabilidade para a proviso de servios sob demanda [Verdi et al. 2010]. Segundo [Mell and Grace 2010] a computao em nuvem possui caractersticas, denies e atributos que ainda esto sendo elaborados. Ainda que possua o agrupamento de muitos modelos, as seguintes caractersticas prprias podem ser enumeradas: 1. Oferta de servios sob demanda: alocao dinmica dos servios requisitados (resource pooling), sem interao humana com o provedor dos servios. 2. Amplo acesso aos recursos computacionais: acesso por meio de diversos protocolos padronizados, para uma grande variedade de dispositivos como PCs, laptops, dispositivos mveis, dentre outros. 3. Transparncia: o usurio no precisa conhecer a localizao fsica dos recursos computacionais oferecidos. 4. Elasticidade: os servios devem ser alocados e desalocados rapidamente, apenas no decorrer da requisio do usurio. 5. Gerncia: a infraestrutura deve oferecer mecanismos para a gerncia de recursos, de armazenagem, de processamento e largura de banda, dentre outros. Outras caractersticas comuns de ambientes que utilizam computao em nuvem so [Endo et al. 2010]: Escalabilidade: a oferta de recursos sob demanda viabiliza a oferta de servios para um nmero maior de usurios. Os recursos sero alocados apenas pelo perodo contratado, reduzindo a sub-utilizao da rede de servios. Essa caracterstica implica na elasticidade da oferta de recursos para muitos usurios concorrentes. Modelo pay-per-use: cobrana proporcional ao uso dos recursos. A computao em nuvem um exemplo de utility computing (computao vista como uma utilidade) porque a oferta desses servios similar a outros tradicionais, onde o usurio paga pelo fornecimento de eletricidade, gua, gs natural ou servios de telefonia [Breitman and Viterbo 2010]. Virtualizao: o usurio tem a iluso de que interage com os recursos de um host real quando, na verdade, utiliza um ambiente que simula o acesso fsico do host no qual esto hospedados. Na computao em nuvem um provedor de servios pode utilizar um ou mais modelos para a oferta de servios. Ainda assim, a administrao do domnio responsvel por controlar a infraestrutura, sistema operacional, servidores, operaes de persistncia e demais requisitos para a oferta de servios para uma grande quantidade de usurios concorrentes. Os modelos para prestao de servios em nuvem so os seguintes:

 IaaS (Infrastructure as a Service): destaca a importncia da infraestrutura na proviso de servios. O provedor capaz de oferecer uma infraestrutura de armazenagem, processamento e demais recursos de hardware, tais como servidores e componentes de rede, de maneira transparente para o usurio. Exemplo de provedores: Amazon AWS [Amazon 2010] e FlexiScale [FlexiScale 2010]. PaaS (Platform as a Service): destaca a importncia de plataformas na proviso de servios. O usurio capaz de desenvolver suas prprias aplicaes, respeitando o modelo de desenvolvimento da plataforma. Tambm so oferecidos servios de comunicao (servios Web, por exemplo), armazenagem e linguagens de programao. Exemplo de provedores: Ning [Ning 2010] e Microsoft Windows Azure Platform [Windows Azure 2010]. SaaS (Software as a Service): o provedor de servios habilita a execuo de aplicaes de uso exclusivo do usurio e/ou aplicaes fornecidas pelo prprio provedor e/ou terceiros, tais como aplicativos de e-mail empresariais, grupos de discusso, ferramentas para edio de sites e demais aplicaes que so compartilhadas por um grande nmero de usurios. Nesse modelo, os servios so mantidos em um provedor de servios e so acessveis pela Internet. O uso de tecnologias como servios Web, arquiteturas orientadas a servio (SOA - Service Oriented Architecture) e AJAX (Asynchronous JavaScript and XML) impulsionaram o desenvolvimento de aplicaes remotas que inclusive podem ser incorporadas a Web sites como servios. Aliado a isso, o aumento da largura de banda entre os usurios nais e os provedores de servios contribui para o aumento de aplicaes sediadas remotamente. Exemplo de provedores: Salesforce [Salesforce 2010] e Google Apps [Google 2010].

Fig. 1.1. Viso Geral dos Principais Componentes para Ambientes de Computao em Nuvem. Adaptado de [Zappert 2010].

A Fig. 1.1 apresenta uma viso geral dos principais componentes encontrados em ambientes de computao em nuvem. A descrio detalhada de cada um desses

componentes pode ser encontrada em [Zappert 2010]. Nessa gura destaca-se os relacionamentos entre os elementos Provedor de Servios, Consumidor de Servios e Desenvolvedor de Servios, os quais so interligados por tecnologias de comunicao baseadas em padres abertos. No Provedor de Servios observado um nvel crescente de abstrao em cada uma das camadas. Por exemplo, infraestruturas de nuvem so altamente dependentes do tipo de hardware escolhido, alm do sistema operacional base de toda a infraestrutura. O suporte a virtualizao oferecido pelo componente Hypervisor que mantido sobre o sistema operacional. A virtualizao de recursos de hardware e software oferece a base para que um amplo conjunto de aplicaes de nuvem sejam oferecidas de vrias formas diferentes (*aaS - Everything as a Service). O componente de Gerncia deve incluir funcionalidades para contabilidade de uso, balanceamento de carga, medio de trfego e uso de recursos, provisionamento de mquinas virtuais e demais funes de monitoramento. O componente Segurana deve incluir funcionalidades tanto para a segurana do trfego de dados, quanto para a segurana relacionada ao acesso ao ambiente. Tanto os componentes de gerncia quanto os componentes de segurana devem abordar desde as camadas inferiores do hardware/rmware at as camadas superiores no nvel das aplicaes e infraestrutura de suporte. O Consumidor de Servios tem acesso aos recursos por meio de interfaces baseadas em regras de acesso compatveis com os mecanismos de segurana da nuvem. Alm disso, acordos de nvel de servio (SLAs - Service Level Agreements) so necessrios para garantir a qualidade da oferta de servios e disponibilidade de acesso, o qual realizado por meio de interfaces de programao para aplicaes (APIs Application Programming Interfaces) que se comunicam com os servios oferecidos por meio de interfaces pblicas. O Desenvolvedor de Servios utiliza uma gama de servios para desenvolver novas aplicaes para a nuvem. Esses servios utilizam padres abertos para se comunicar e estender as funcionalidades dos servios j existentes. O desenvolvimento de novos servios demanda o uso de frameworks prprios para o desenvolvimento e demais ferramentas de suporte, bem como a publicao dos mesmos com o auxlio de APIs (componentes Publicao e APIs). A infraestrutura da nuvem oferecida em diversos nveis de abrangncia e disponibilidade, de acordo com as nalidades da organizao e de seus usurios. Cada um desses modelos admite que uma entidade terceirizada mantenha a nuvem: a) nuvem privada: centrada no domnio de uma organizao; b) nuvem pblica: acessvel pela Internet, geralmente para uso pblico em geral; c) nuvem comunitria: nuvens compartilhadas entre vrias organizaes com nalidades em comum; d) nuvem hbrida: uma combinao das anteriores. O uso desse ltimo modelo uma alternativa para estender o pool de recursos utilizando servios de outros provedores de nuvem. Nesses casos, a organizao utiliza os servios de uma nuvem pblica para prover a maioria das funcionalidades para seus clientes, mas os dados restritos so mantidos e gerenciados em datacenters particulares na organizao. Outra funcionalidade de destaque a possibilidade de migrao de servios para reduo de custos durante o ciclo de vida das mquinas virtuais (live migration) para cumprir os requisitos de armazenagem, desempenho, capacidade de processamento, largura de banda e demais quesitos relacionados a qualidade de servio (QoS - Quality of Service). Isso sugere que

relacionamentos de conana precisam assegurar SLA entre os domnios parceiros. De acordo com essa anlise, com os recentes avanos das solues de virtualizao e de computao em nuvem, a interoperabilidade ser um fator fundamental para manter a cooperao mtua entre provedores de nuvem. Nesse cenrio, uma federao de nuvens hbridas uma soluo onde cada domnio capaz de expandir seus recursos virtualizados sob demanda, requisitando mais recursos computacionais de outros domnios federados, quando necessrio. A gerncia de identidades federadas aplica-se a esse cenrio de forma a gerenciar o uso seguro de recursos por parte dos usurios e sistemas de sites parceiros. 1.2.1. Tcnicas Fundamentais em Computao em Nuvem Virtualizao

Em essncia, a virtualizao consiste em imitar um comportamento, seja por extenso ou substituio de um recurso por outro [Carissimi 2008]. A virtualizao tambm denida como um sistema ou um mtodo de dividir os recursos computacionais em mltiplos ambientes isolados [OpenVZ 2010]. O conceito de virtualizao remonta virtualizao de recursos em sistemas operacionais. Solues de alto nvel como interfaces grcas, bibliotecas e APIs so exemplos de recursos de software que tornam transparente para o usurio o acesso aos recursos de hardware, em especial, o acesso aos perifricos de entrada e sada. Ou seja, cria-se a iluso no sistema operacional de que se tem a interao direta com os recursos de hardware. Diz-se tambm que a virtualizao uma metodologia para dividir os recursos de um computador em mltiplos ambientes de execuo conhecidos como mquinas virtuais, aplicando conceitos de particionamento, time-sharing, simulao completa ou parcial de mquina, emulao, QoS, entre outros [Carissimi 2008]. Portanto, a virtualizao uma tcnica para ocultar caractersticas fsicas de recursos computacionais, de forma que os sistemas, aplicaes e end users interajam com esses recursos. Nesta tcnica, um nico recurso fsico, como um servidor, dispositivo de armazenagem ou sistema operacional, passa a ser visto como mltiplos recursos lgicos. A virtualizao remonta s dcadas de 60 e 70. Com o uso de mquinas virtuais era possvel executar e migrar aplicaes legadas entre plataformas distintas, desde que houvesse uma verso da mquina virtual para a plataforma alvo. A principal motivao era ampliar e melhorar a utilizao e o compartilhamento de recursos nos mainframes [Carissimi 2008]. Com a reduo do custo do hardware em meados da dcada de 80, ocorreu uma mudana do foco de processamento centralizado em mainframes para o processamento distribudo em microcomputadores. O modelo cliente-servidor foi estabelecido para a computao distribuda, reduzindo a necessidade da virtualizao para a integrao de recursos computacionais. A reduo do custo de aquisio do hardware e do compartilhamento de informaes tornaram a virtualizao pouco explorada por alguns anos [Menasc 2005]. Apenas em meados da dcada de 90, com o aumento do poder de processamento do hardware e dos computadores pessoais (PCs), a virtualizao voltou a ganhar

destaque em produtos tais como o VMware [VMware Inc. 2011], User Mode Linux (UML) [Dike 2006], Xen [Xen 2010], KVM [Warnke and Ritzau 2010] e VirtualBox [Oracle 2010]. De certa forma, esses produtos trazem o conceito de virtualizao como uma alternativa para executar diversos sistemas operacionais sem a necessidade de se aumentar proporcionalmente o nmero de hosts fsicos que os mantm. Isso implica em reduzir os custos relativos aquisio de hardware, infraestrutura fsica, consumo de energia, ventilao, suporte e manuteno de vrios hosts. A virtualizao recomendada para consolidar mltiplos servidores em um mesmo host, isolar diferentes aplicaes de usurios em um mesmo host, executar/depurar softwares e sistemas operacionais construdos para uma arquitetura em outra, alm de simplicar a instalao de infraestruturas de software em diferentes domnios e testar aplicativos em hardwares no existentes. O sistema operacional que executa o software de virtualizao denominado hospedeiro (host). O sistema operacional virtualizado denominado convidado (guest). Mltiplos sistemas operacionais convidados podem executar no mesmo hospedeiro, sem interferncia entre eles. Uma mquina virtual (VM - Virtual Machine) uma camada de software que simula um computador real (fsico) e que capaz de executar instrues como se fosse a mquina fsica. O ncleo do sistema operacional hospedeiro fornece bibliotecas para suportar mltiplas mquinas virtuais. Sistemas operacionais convidados executam sobre mquinas virtuais. SOC - Service Oriented Computing A computao em nuvem supre as necessidades de provedores de servios na Internet quanto maneira de se aumentar a capacidade de processamento sob demanda, sem a necessidade de se ampliar os investimentos na prpria infraestrutura. Alm disso, reduz os custos com o treinamento de pessoal e aquisio de licenas adicionais de software. Muitas solues de nuvem utilizam servios Web para disponibilizar interfaces Web (APIs) para acesso aos seus servios. Servios Web seguem a arquitetura SOA que baseada em um modelo cliente/servidor em que o cliente faz o papel de requisitante de servios e o servidor de provedor de servios. A comunicao baseada na troca de mensagens sncronas ou assncronas independentes do protocolo de transporte utilizado [Ma 2005]. A Fig. 1.2 ilustra uma viso geral da arquitetura SOA. A computao orientada a servios (SOC - Service Oriented Computing) dene um conjunto de princpios, modelos arquiteturais, tecnologias e frameworks para o projeto e desenvolvimento de aplicaes distribudas. Segundo [Gonalves et al. 2011], orientao a servio um paradigma que prope a criao de unidades lgicas (ou servios) bem denidas que podem ser utilizadas coletivamente e repetidamente. Na arquitetura SOA as aplicaes distribudas utilizam os servios como blocos de construo [IBM 2011]. Para simplicar a localizao desses servios em provedores distintos, SOA integra um componente para o registro e a descoberta. Com isso, os provedores registram os seus servios em um repositrio centralizado. O registro descreve as informaes de cada servio e a localizao do provedor que os mantm. Quando o cliente deseja utilizar um servio, ele faz uma consulta nesse repositrio e

Registro UDDI Registro do Servio Busca do Servio Provedor de Servios

<SOAP> Requisitante de Servios

WSDL Web Service

Fig. 1.2. Viso Geral da Arquitetura Orientada a Servio.

informa quais os requisitos desejados. O repositrio ento devolve uma lista de servios que satisfazem os requisitos solicitados. Aps a escolha do servio, o cliente acessa diretamente o provedor de servios com base na informao de sua localizao. Essa localizao dinmica pode ser feita no momento da execuo do aplicativo. UDDI (Universal Description, Discovery, and Integration) especica um mtodo padro para publicao e descoberta de componentes de software na Web segundo a arquitetura SOA [OASIS 2006]. Interfaces de servios so descritas em WSDL (Web Services Description Language) e o protocolo SOAP (Simple Object Access Protocol) empregado na interao cliente/servidor. WSDL e SOAP so padres baseados em XML (Extensible Markup Language). Em SOA, as unidades de software podem ser desenvolvidas separadamente. Tais unidades encapsulam a lgica da implementao do servio e expem apenas a interface de acesso funcionalidade. Isso torna possvel o desenvolvimento de aplicaes distribudas com fraco acoplamento. Alm disso, a possibilidade de reuso de cdigo e de disponibilidade na Web permite o desenvolvimento de aplicaes em ambientes colaborativos distintos.

Datacenters Infraestruturas de virtualizao para nuvens geralmente utilizam um ou mais datacenters. Os datacenters so infraestruturas formadas por componentes que fornecem capacidades em larga escala para processamento, armazenagem e servios de rede para uma ou mais organizaes [Veras 2009]. Datacenters podem ser agrupados nas categorias de PDC (Private Data Center) e IDC (Internet Data Center). Um PDC voltado para empresas privadas, instituies ou rgos governamentais, com a nalidade de processar informaes internas. Um IDC, por outro lado, geralmente mantido por um provedor de servios de telecomunicaes ou informao. Um datacenter agrupa de centenas a milhares de componentes, desde switches e roteadores, a poderosos servidores, balanceadores de carga e dispositivos de armazenagem. Essas caractersticas exigem que a infraestrutura tenha suporte adequado para o funcionamento, incluindo a proviso adequada de energia, ventilao/ar condicionado, segurana, monitoramento e redundncia de dados. Alm disso, equipamentos especializados requerem congurao

e treinamento, o que encarece os custos para a proviso de uma infraestrutura particular [Gonalves et al. 2011]. Em ambientes de computao em nuvem, o uso de datacenters uma soluo adequada para o oferecimento de ambientes virtualizados, visando o desenvolvimento e rpido provisionamento de aplicaes empresariais. Empresas no precisam empregar grandes quantias para a aquisio e congurao de infraestruturas de tecnologia que mudam rapidamente, mas sim utilizar infraestruturas pr-conguradas de ambientes, como os da Amazon ou IBM, por exemplo. O custo para o processamento e armazenagem de dados pode reduzir ou ampliar, conforme a demanda. 1.2.2. Sistemas Abertos para Gerncia de Nuvens Atualmente existem diversas solues de cdigo aberto para a gerncia de recursos virtuais em nuvens. Uma classicao detalhada dos principais ambientes apresentada em [Endo et al. 2010]. Dentre estas solues destaca-se a plataforma XCP (Xen Cloud Platform) [Xen 2010]. A plataforma inclui o agrupamento e o isolamento de recursos de hardware e rede, provisionamento de sistemas, APIs para acessar os recursos virtuais e compatibilidade com um grande nmero de sistemas operacionais. XCP herda caractersticas dos ambientes de virtualizao para-virtualizados dos produtos Xen. O projeto Nimbus [Nimbus 2011] disponibiliza um toolkit de cdigo aberto para oferecer um ambiente de cluster como uma IaaS. Esse toolkit oferece interfaces WSDL para o servio Amazon EC2, Amazon EC2 Query API, e WSRF (Web Services Resource Framework) para aplicaes em grades. Tambm so oferecidas interfaces que seguem o padro arquitetural REST (Representational State Transfer) para o acesso base de dados de recursos e escalonamento de VMs por meio de uma interface de gerncia. A implementao da virtualizao baseada em Xen e KVM (Kernel Virtual Machine). O projeto OpenNebula [OpenNebula 2010] oferece um toolkit de cdigo aberto para a proviso de nuvens pblicas, privadas e hbridas. A infraestrutura do sistema oferece recursos sob demanda para usurios nais, e foi projetada para ser integrada com outras solues de armazenagem e rede. As VMs so utilizadas em um pool de recursos e toda a alocao de recursos baseada em polticas. O ambiente virtualizado acessvel por meio de interfaces OCCI (Open Cloud Computing Interface), denidas pelo Open Grid Forum. Alm disso, OpenNebula oferece interfaces para a EC2 Query API da Amazon, atravs da interface Web OpenNebula Sunstone e um subconjunto de chamadas da vCloud API da VMware. A infraestrutura tem suporte para Xen, KVM/Linux e VMware. Eucalyptus [Murari 2010] uma plataforma de software de cdigo aberto para a criao e gerncia de nuvens pblicas e privadas, que possui APIs interoperveis com as APIs da plataforma Amazon EC2/S3. A empresa Canonical, mantenedora da distribuio Ubuntu, adotou inicialmente o Eucalyptus, juntamente com outros softwares de cdigo aberto, como soluo de nuvem para o Ubuntu Server Edition. Essa soluo cou conhecida como Ubuntu Enterprise Cloud (UEC). Eucalyptus suporta o uso de Xen, KVM e VMware. A verso UEC, porm, suporta apenas o uso do KVM. Recentemente, a Canonical demonstrou interesse no uso de outra soluo para nuvem, conhecida como OpenStack [Rackspace 2010].

 interessante notar que nenhuma dessas solues contempla funcionalidades necessrias para gerenciar identidades de usurios pertencentes a mltiplas nuvens. Geralmente as iniciativas adotadas para a criao de federaes contemplam o uso de outras infraestruturas especcas para essa tarefa, ou seja, infraestruturas para gerncia de identidades federadas so agregadas como servios adicionais ao ambiente de computao em nuvem.

1.3. Gerncia de Identidades: Conceitos e Tcnicas

O conceito de identidade, segundo [Cao and Yang 2010], difcil de precisar, uma vez que a denio de identidade est relacionada ao ambiente onde empregada, a contextos semnticos e a casos de uso. Como uma denio mais geral, pode-se dizer que uma identidade uma representao de uma entidade ou sujeito que seja suciente para identicar esta entidade em um contexto particular [El Maliki and Seigneur 2007]. Uma entidade, por sua vez, qualquer coisa existente no mundo real. Como exemplos de entidades temos uma pessoa, um host ou uma aplicao. Em geral, a relao de cardinalidade de uma entidade que ela pode ter mltiplas identidades. De acordo com a norma ITU-T Y.2720 [ITU-T 2009], uma identidade pode consistir de: Identicador: conjunto de dgitos, caracteres e smbolos ou qualquer outra forma de dados usada para identicar unicamente uma identidade. Podem ser delimitados pelo tempo e/ou espao. Por exemplo, uma URL (Uniform Resource Locator) nica ao longo do tempo. Como exemplo de identicadores temos CPF, RG, nmero de matrcula e nmero de passaporte. Credenciais: uma credencial um atestado de qualicao, competncia ou autoridade, expedida por terceiros com autoridade relevante ou competncia para tal ato e que atesta a veracidade da identidade. Na computao, exemplos de credenciais incluem certicados digitais X.509 assinados por uma autoridade certicadora (CA - Certicate Authority), senha, asseres SAML (Security Assertions Markup Language), dentre outros. Atributos: um conjunto de dados que descreve as caractersticas fundamentais de uma identidade. Como exemplo temos: nome completo, domiclio, data de nascimento e papis (roles). A Fig. 1.3 ilustra a relao entre os componentes de uma identidade na notao UML (Unied Modeling Language).

Fig. 1.3. Relao entre os Componentes da Identidade.

1.3.1. Ciclo de Vida da Identidade

Criao

Utilizao

Revogao

Atualizao

Fig. 1.4. Ciclo de Vida da Identidade.

A Fig. 1.4 ilustra a ciclo de vida de uma identidade e a relao entre as suas fases. De acordo com esta gura o ciclo de vida de uma identidade pode ser categorizado em [Bertino and Takahashi 2011]: Criao: a criao de uma identidade est relacionada com a proviso da infraestrutura de tecnologia da informao e comunicao (TIC). necessrio um mecanismo para automatizar a sua criao mediante informao de dados de um usurio e para armazenar estas em um repositrio (por exemplo, banco de dados). Esta fase possui trs subfases: Vericao dos atributos. Um atributo vericado por uma autoridade convel por parte dos destinatrios destes atributos. Por exemplo, em situaes onde o cadastro em um site requer atributos obrigatrios, tais como RG e CPF. H casos tambm onde este passo no ocorre. Por exemplo, em cadastros de blogs, onde os atributos requisitados no requerem nenhuma vericao. Emisso da credencial. Aps a vericao dos atributos, as credenciais so emitidas. Elas podem ser emitidas por alguma autoridade, pelo prprio sujeito ou pela entidade onde ocorreu o cadastro. As credenciais podem ser de vrias formas (certicados digitais, passwords, entre outros). importante ressaltar que cada tipo de credencial implica em um nvel de conana sobre a mesma. Formao da identidade. A identidade formada pelos atributos vericados, as credenciais emitidas e identicadores que so atribudos por terceiros ou pelo prprio sujeito. Utilizao: uma vez que a identidade foi criada, ela pode ser utilizada por vrios sistemas e servios. Neste caso mecanismos para autenticar e autorizar so aes geralmente executadas. Pode tambm incluir outras aes, tais como bilhetagem. O uso da identidade implica na utilizao de forma segura e privativa, principalmente em ambientes federados onde os pares comunicantes devem ser capazes de descobrir, distinguir e autenticar identidades de forma convel. Atualizao: a fase de atualizao envolve a alterao de valores de atributos j existentes (por exemplo, um novo endereo) ou a insero de novos atributos para

reetir novas polticas ou regras de negcio. Com a alterao da identidade necessrio tambm que os sistemas de IdM permitam que estes novos parmetros sejam propagados para domnios federados. Outra questo interessante deixar alguns servios mais procurados disposio do usurio. Um exemplo o servio de password reset, que pode ser oferecido ao usurio que esqueceu ou teve a sua senha bloqueada. Revogao: identidades e credenciais devem ser canceladas se estas carem obsoletas (por exemplo, expirou a data de validade) ou invlidas. Essa fase importante para manter o sistema de IdM atualizado. 1.3.2. Autenticao e Controle de Acesso (Autorizao) O processo de vericar a existncia de uma identidade chamado de autenticao [Stallings 2011]. Para que tal processo se inicie necessrio que o usurio fornea uma credencial vlida para o mtodo de autenticao utilizado pela entidade autenticadora. De posse da credencial vlida, a entidade autenticadora poder vericar em sua base de identidades se h alguma identidade cuja credencial seja a fornecida pelo usurio. Caso a entidade autenticadora encontre alguma entrada referente credencial, o usurio autenticado. Com isso entende-se que o usurio provou ser quem ele informou [Stallings 2011]. Uma vez realizada a autenticao do usurio, a entidade autenticadora poder vericar qual ou quais so as permisses de acesso ao recurso originalmente requisitado. Este processo de vericar as permisses de acesso a um determinado recurso denomina-se autorizao [Stallings 2011]. 1.3.3. Modelos para Gerncia de Identidades Os modelos para IdM so classicados de acordo com a sua arquitetura. O modelo mais simples conhecido como modelo isolado ou tradicional. Neste modelo no h diviso de responsabilidade e um nico servidor responsvel pelo tratamento de todo o ciclo de vida da identidade e da autenticao e autorizao. Uma desvantagem deste modelo que o usurio precisa se lembrar da identidade que possui em cada servio que este usurio acessa. Isto torna a experincia do usurio tediosa. Para o provedor de servios isto representa um custo maior para gerenciar sua infraestrutura de IdM [Wangham et al. 2010]. Para amenizar os problemas existentes no modelo isolado, surge o modelo centralizado. Neste modelo cliente-servidor, h o conceito de provedor de identidades (IdP - Identity Provider) e provedores de servio (SPs - Service Providers). Os provedores de servio no armazenam as identidades dos usurios em seus sistemas e tambm delegam a etapa da autenticao para um provedor de identidades. Neste modelo todos os SPs utilizam os servios de identidade oferecidos por um nico IdP. Assim, possvel para um usurio que possua uma identidade em um site na Web e que utiliza este modelo, realizar SSO. Com o mecanismo de SSO, o usurio apresenta seu identicador e credenciais apenas uma vez no IdP parceiro do site. O SP, por utilizar o mesmo IdP, pode conar na autenticao prvia do usario e assumir que o usurio esteja autenticado sem necessitar de outro processo de vericao das credenciais.

Sistemas tais como Kerberos, PKI (Public Key Infraestructure), CAS (Central Authentication Service) e Microsoft Passport Network so comunente utilizados em modelos centralizados [Cao and Yang 2010]. Apesar deste modelo oferecer uma separao de responsabilidades, permitindo o SSO, ainda assim oferece desvantagens do ponto de vista da escalabilidade (o IdP um ponto de falha), da privacidade (o IdP pode ter controle total sobre a identidade) e do fato que os SPs e IdP necessitam estar no mesmo domnio administrativo. O modelo federado uma evoluo do modelo centralizado. Neste modelo, os SPs e o IdP podem estar em domnios administrativos diferentes. O SSO, no caso federado, tambm pode ser realizado entre domnios administrativos diferentes (denominado Cross Domain SSO). No modelo federado possvel tambm existir vrios IdPs, com uma relao MxN entre IdPs e SPs. Uma federao representa um conjunto de organizaes que cooperam entre si de acordo com regras de conana pr-estabelecidas para a autenticao de usurios e compartilhamento de recursos [Switch 2011]. Para tal, estas unem-se atravs de crculos de conana (CoT - Circles of Trust). Uma soluo de federao considerada desejvel quando organizaes crescem com a aquisio de novos sites, para a manuteno distribuda de repositrios e para simplicar a autenticao e autorizao de usurios a recursos e aplicaes entre domnios parceiros [Ping Identity 2010a]. As entidades a seguir so normalmente encontradas em uma federao: Provedor de servio: a entidade mais prxima ao recurso do domnio em questo. responsvel por vericar as permisses de acesso aos recursos por usurios autenticados. Como exemplo, o SP poderia ser um provedor, que oferece servios de nuvem para seus clientes. Provedor de identidades: um provedor de servios de identidades. Sua responsabilidade manter a base de dados de usurios do domnio e validar as credenciais de usurios. Como exemplo, pode ser uma empresa que gerencia contas para um grande nmero de usurios que precisam de acesso seguro a transaes bancrias. Por meio dessa entidade os usurios fornecem as suas credenciais para acessarem os recursos federados. IdP proxy: a entidade responsvel por interrogar o usurio a respeito de seu domnio de origem. O domnio de origem o local onde o usurio possui uma identidade em um IdP. Geralmente, o IdP proxy apresenta uma lista de IdPs para o usurio selecionar o mais apropriado. As duas primeiras entidades so geralmente encontradas em federaes onde os participantes esto localizados em um mesmo domnio administrativo. Neste caso dizemos que a federao do tipo intra-domnio e ocorre entre as diferentes aplicaes do domnio. Em federaes cujos elementos esto dispostos em domnios administrativos distintos, dizemos que a federao do tipo inter-domnios. Neste caso, e dependendo da arquitetura adotada, o elemento IdP proxy atua como uma ponte entre esses domnios. Por m, o modelo centrado no usurio, uma evoluo do modelo federado, tem como objetivo resolver uma das principais crticas em relao aos modelos anteriores,

que diz respeito identidade do usurio, ou seja, esta ca armazenada nos provedores de identidades. Estes podem ter total controle sobre estas informaes. O modelo centrado no usurio visa ento oferecer mecanismos para que um usurio possa escolher que tipo de informaes deseja liberar para um determinado provedor de identidades. Exemplos de solues que utilizam o modelo centrado no usurio so: OpenID [OpenID Foundation 2011], Microsoft CardSpace [Microsoft 2011] e o Projeto Higgins [Eclipse Foundation 2011]. A Fig. 1.5 apresenta os modelos para a IdM.

Fig. 1.5. Modelos para a IdM. Baseado em [Wangham et al. 2010]

1.3.4. Mecanismos para Localizao de Provedores de Identidades Em arquiteturas cujo modelo federado ou centrado no usurio h a problemtica da localizao de provedores de identidades para a autenticao do usurio. Nestas arquiteturas, h a possibilidade de haver diversos provedores de identidades, e estes, por sua vez, podem estar espalhados em domnios administrativos diferentes. H duas tcnicas empregadas pelos padres em gerncia de identidades federadas: Localizao baseada em um servio: nesta tcnica utiliza-se um provedor de servio de localizao de identidades. Este servio conhece todos os possveis provedores de identidade alcanveis a partir do provedor. No processo de autenticao de um usurio, este servio ser invocado para apresentar uma lista com os possveis provedores de identidades conhecidos e conveis. O usurio ento escolhe um provedor de identidades (onde ele possui uma identidade) e ento redirecionado para este provedor. Caso o usurio no tenha nenhuma identidade em nenhum provedor conhecido, este usurio dever criar uma identidade. Esta abordagem utilizada pelo padro SAML, no perl IdP Discovery.

 Localizao baseada em atributos da identidade: esta abordagem utiliza um atributo existente na prpria identidade para descobrir onde est o provedor de identidades que autentica esta identidade. O padro OpenID utiliza como identicador da identidade o formato URL. 1.3.5. Opes para Implantao de SSO A implantao de sistemas para IdM geralmente envolve a instalao de um middleware que car responsvel pelos servios de identidade (autenticao, autorizao, entre outros). Uma questo importante no processo de implantao de sistemas para IdM diz respeito ao SSO. Principalmente se o SSO envolver diferentes domnios, questes relacionadas infraestrutura desses domnios, que desejam ingressar na federao, devem ser levadas em considerao. As seguintes opes para a implantao de SSO devem ser avaliadas [Bertino and Takahashi 2011]: Baseada em Broker Nesta abordagem, h um servidor central responsvel por autenticar os usurios (sujeitos) e emitir uma credencial em forma de ticket. Atravs destes tickets possvel ao usurio obter acesso aos recursos protegidos. O Kerberos um exemplo de implantao de SSO que utiliza a abordagem baseada em broker. Esta abordagem est relacionada com o modelo centralizado de IdM. A Fig. 1.6 ilustra esta abordagem.

Fig. 1.6. Processo de SSO que Utiliza Abordagem Baseada em Broker.

Baseada em Agentes Esta abordagem utiliza um ltro instalado em um servidor de aplicao Web. Este ltro intercepta todas as requisies que passam neste servidor (passo 1) e, com base em regras pr-estabelecidas, redireciona a requisio para um servidor de autenticao (provedor de identidades, passo 2). Aps a autenticao bem sucedida (passo 3), o agente verica se h alguma credencial vlida e, se houver, libera o acesso ao recurso solicitado (passo 4). A Fig. 1.7 ilustra esta abordagem.

Fig. 1.7. Processo de SSO que Utiliza Abordagem Baseada em Agente.

Baseada em Proxy Reverso Esta abordagem utiliza um proxy localizado na borda da rede ou em uma zona desmilitarizada (DMZ). Atravs deste proxy, requisies de acesso a recursos (por exemplo, aplicaes) so ltradas (com o uso de um agente, passo 1) e o usurio redirecionado para um servidor de autenticao (provedor de identidades, passo 2). Aps a autenticao bem sucedida, o usurio redirecionado de volta para o proxy (passo 3), que por sua vez estar apto a liberar o acesso redirecionando o usurio para o recurso protegido (passo 4). Nesta abordagem, possvel atravs do proxy, o redirecionamento para qualquer domnio ao qual este tenha alcance. Um problema com esta abordagem que h uma perda de ecincia uma vez que todas as requisies passam pelo mesmo proxy. Uma vantagem que no necessrio instalar componentes adicionais nos servidores de aplicao para proteg-los. A Fig. 1.8 mostra esta abordagem.

Fig. 1.8. Processo de SSO que Utiliza Abordagem Baseada em Proxy Reverso.

Baseada em API Nesta abordagem h a incluso de uma API relacionada com o middleware para IdM nas aplicaes a serem protegidas. Este mecanismo o mais intrusivo de todos, uma vez que cada aplicao necessita chamar as primitivas oferecidas pela API. Um fator positivo que nesta abordagem possvel obter um nvel de controle de acesso mais sosticado se comparado com as demais abordagens. No passo 1, a requisio para acessar a aplicao Web interceptada pela API que est na prpria aplicao. No passo 2, a API redireciona

o browser para o provedor de servio de identidades. No passo 3, aps a autenticao bem sucedida, este provedor redireciona o browser do usurio para a API. No passo 4, a API informa aplicao que o usurio est autenticado e a aplicao segue o seu uxo de execuo. A Fig. 1.9 ilustra esta abordagem.

Fig. 1.9. Processo de SSO que Utiliza Abordagem Baseada em API.

Baseada em Servios Esta abordagem parecida com a abordagem baseada em API. A diferena que neste caso as chamadas so realizadas remotamente (passos 2 e 3), pois so oferecidas diretamente pelo provedor de servio de identidades. A Fig. 1.10 mostra esta abordagem.

Fig. 1.10. Processo de SSO que Utiliza Abordagem Baseada em Servios.

1.3.6. Auditoria O propsito da auditoria para a IdM auxiliar a resoluo de questes relacionadas com o inventrio de identidades. A auditoria deve ser realizada periodicamente, por exemplo uma vez ao ano. No processo de auditoria, o inventrio atualizado visando oferecer informaes para a avaliao de riscos referente s polticas de segurana, privacidade, entre outras [Windley 2005]. Um desao importante para que a auditoria funcione em um ambiente de computao em nuvem diz respeito ao problema da falta de visibilidade no acesso de

aplicaes oferecidas como SaaS. Este fato uma consequncia dos usurios estarem acessando as aplicaes atravs de uma rede pblica (por exemplo, a Internet) ao invs de estarem conectados em uma rede privada (por exemplo, a rede de uma universidade ou empresa). Isto prejudica o uso de ferramentas de monitoramento de rede, uma importante aliada da auditoria [Olden 2011]. 1.3.7. Privacidade O termo privacidade denido como o direito de uma entidade (sujeito) em determinar o grau de interao que suas informaes pessoais (atributos de sua identidade) devem ter perante o contexto onde a identidade est inserida. Este contexto inclui o grau de comprometimento na divulgao destas informaes a terceiros [Jnior et al. 2010]. No mbito da IdM, tendo em vista que as identidades esto logicamente interrelacionadas entre os diferentes domnios de segurana, a privacidade pode ser vista como a possibilidade de um sujeito determinar quais informaes (atributos) de sua identidade sero divulgadas no processo de federao de forma a manter o anonimato entre as diferentes identidades na federao. Uma tcnica para a preservao da privacidade em IdM utilizar pseudnimos. Pseudnimos so identicadores que no permitem inferncias em relao identidade real (e seus atributos) do usurio [Wangham et al. 2010]. Os pseudnimos podem ter signicado local (dependente do contexto entre o usurio e um SP especco) ou global, e podem ter validade temporria (durante o tempo de uma sesso) ou permanente.

1.4. Gerncia de Identidades Federadas em Nuvens

No setor acadmico, ambientes de computao em nuvem geralmente pertencem a domnios privados mantidos por centros de pesquisa e universidades. Muitas vezes, nestes domnios, esto recursos cujo acesso pode ser realizado via Internet. Neste caso, essencial que existam mecanismos para prover a autenticao e a autorizao de usurios no acesso aos recursos, tanto para usurios vindos do prprio domnio, quanto de outros domnios parceiros. Estes mecanismos possibilitam a interoperabilidade de recursos localizados em domnios distintos, habilitando ento a cooperao entre centros de pesquisa parceiros. Para que a cooperao seja realizada com xito, as entidades parceiras devem denir polticas para o compartilhamento de recursos junto aos domnios federados [Gomes and Kowalczyk 2011]. Esse processo envolve mecanismos de SSO para que, uma vez que o usurio esteja autenticado em seu domnio de origem, ele possa acessar recursos em quaisquer outros domnios federados, desde que esse usurio esteja inserido no contexto de autorizao do domnio em questo. Em domnios no-federados, o mesmo usurio precisaria ter credenciais em ambos os domnios para ter permisses de acesso aos recursos distribudos [Cao and Yang 2010]. O uso de padres abertos assegura a interoperabilidade em ambientes de computao em nuvens hbridas. No entanto, os servios oferecidos em nuvens ainda esto em processo de desenvolvimento e ainda existem muitos desaos para a proviso de segurana na integrao de aplicaes de domnios distintos. Outro fato que nem todas as aplicaes de uma empresa podem ser disponibilizadas na nuvem. Ao

mesmo tempo em que alguns servios podem ser contratados de terceiros (tais como espao de armazenagem, aplicaes Web para e-mail, publicao on-line de documentos e hospedagem de pginas Web), outros servios so exclusivos do uso interno da empresa e no devem ser disponibilizados publicamente (folha de pagamentos, relatrios empresariais e aplicativos internos de controle de produo, dentre outros). Uma rea da computao em nuvem onde a IdM tem papel importante no cenrio de mash-ups. Um mash-up pode ser caracterizado por uma pgina Web ou aplicao que compartilha, utiliza ou integra dados, apresentao e funcionalidade de uma ou mais fontes criando um novo servio [Crupi and Warner 2008]. Um exemplo seria um mashup entre um blog e um servio de armazenamento de fotos, oferecendo aos usurios a possibilidade de postar mensagens com foto, sendo que estas fotos podem estar em diferentes sites. Neste cenrio, o controle de acesso aos recursos compartilhados (fotos) deve ser baseado em polticas bem denidas e deve avaliar o pedido de acesso ao recurso com base na autenticao prvia do usurio feito pelo blog. Provedores tais como Oracle, Google, Salesforce, IBM, Amazon e Microsoft so exemplos de empresas que comearam a estabelecer novos datacenters para a proviso de servios de nuvem. A infraestrutura desses provedores deve comportar a habilidade de expandir/reduzir a capacidade de suas aplicaes sob demanda para o fornecimento de contedo para redes sociais, aplicaes comerciais, multimdia, jogos, entre muitos outros. O modelo de acesso a aplicaes em plataformas de computao em nuvem segue o modelo multi-tenant (multi-locatrio), em que uma mesma aplicao passa a ser utilizada por mltiplos locatrios (tenants), que so desde usurios convencionais a empresas. Esse modelo interessante para aplicaes em nuvem porque mltiplos usurios podem compartilhar os recursos fsicos utilizados para prover um aplicativo, ao mesmo tempo em que as operaes realizadas por um usurio no so vistas por outro. Provedores de servios tais como a Amazon, Salesforce.com e Aol, entre outros, possuem os seus prprios sistemas de gerncia de identidades, mas no realizam processos de SSO. Infraestruturas para gerncia de nuvens tais como Abiquo, OpenStack, Eucalyptus, Proxmox e OpenNebula no possuem um mecanismo para gerncia de identidades federadas padronizado. Os sistemas Web existentes ainda so limitados quanto distribuio automatizada de recursos entre nuvens, respeitando quesitos de QoS. Ambientes de computao federados devem ser capazes de adotar medidas para a proviso escalvel de servios, respeitando quesitos de QoS, condies de rede e variao de carga entre os diversos servidores associados. A gerncia de identidades federadas pode ser implantada de diversas maneiras. Segundo [Bertino and Takahashi 2011], a primeira delas o chamado in-house. Nesta congurao, as identidades so expedidas e gerenciadas pelo prprio domnio (organizao). A outra maneira oferecer como um servio tercerizado. Este cenrio chamado de identidade como um servio (IDaaS - Identity as a Service). Nesta congurao, as identidades so expedidas e gerenciadas por provedores IDaaS. Em um cenrio de hospedagem gerenciada, a organizao contratante exporta toda a sua base de usurios ao provedor IDaaS terceirizado. Em outro cenrio, o provedor IDaaS mantm somente pseudnimos das identidades dos usurios da organizao, que por sua vez so

mapeadas para identidades de seus usurios reais. 1.4.1. Desaos da Gerncia de Identidades Federadas em Nuvens O desao da gerncia de identidades federadas est relacionado com a problemtica de diferentes provedores de servios utilizarem diferentes mecanismos de mapeamento de usurios em contextos de autenticao [El Maliki and Seigneur 2007]. A gerncia de identidades federadas tem o objetivo de unicar a validao de contexto de usurios nos diferentes domnios parceiros. Isso signica que preciso manter as devidas restries e controle de acesso de acordo com o contexto em que o usurio est inserido no momento. As identidades de usurios fornecidas para aplicaes podem ser do tipo usurio/senha, certicados digitais, tokens, biometria, cartes, entre outros [Cao and Yang 2010]. Dentre os principais desaos da gerncia de identidades federadas est o acesso seguro a dados de outros domnios, sem que seja necessrio a replicao dos servios administrativos. Por isso necessrio que os mesmos protocolos sejam utilizados pelos domnios parceiros, ou que esses protocolos sejam interoperveis. Como exemplo, a interface OCCI [Open Grid Forum 2009] relativamente recente (incio do projeto em 2009) e um dos esforos da comunidade do Open Grid Forum (OGF) para denir como provedores de servios podem oferecer seus recursos de computao, dados e rede atravs de interfaces padronizadas. O objetivo do projeto promover interoperabilidade entre provedores de nuvem, sem a necessidade de traduo de padres de formatao de dados para a criao, gerncia e representao de recursos de um domnio para outro. Infraestruturas de nuvem como OpenNebula e Eucalyptus tm suporte para a interface OCCI, alm de oferecerem interfaces para a EC2 Query API da Amazon, bem como APIs prprias de interconexo com outros provedores de nuvem. Nesse novo modelo, um conjunto de aplicativos, infraestrutura e mesmo plataformas so oferecidos como servios que no precisam estar sicamente mantidos nos domnios de uma mesma organizao. Os servios so distribudos em uma nuvem de recursos armazenados em diversas organizaes. Em virtude desse modelo, muitos desaos se tornam inerentes para a proviso de segurana no acesso a servios de mltiplos parceiros. A seguir so apresentados alguns deles [Buyya et al. 2010]: Single Sign-On: o acesso a servios de domnios externos deve ser protegido por meio de servios de autenticao. O desao nesse caso est em garantir que uma nica credencial seja fornecida e validada entre mltiplos domnios, sem a necessidade do usurio manter uma conta por domnio. Segurana para o acesso a recursos distribudos: o uso de servios de datacenters remotos deve contemplar mudanas nas polticas de proviso de recursos, uma vez que esses recursos podero ser utilizados por qualquer um dos domnios parceiros. Em nuvens desejvel que tanto os usurios quanto as aplicaes da nuvem sejam capazes de acessar mltiplos recursos, e que os usurios de um domnio sejam reconhecidos em outro, sem a replicao das bases de dados de usurios. Ainda que cada domnio possa manter suas prprias polticas de acesso aos servios por ele oferecidos, outras polticas de controle de acesso podem estar distribudas em muitas localizaes da rede, e um mesmo usurio pode requerer

mltiplas regras para acessar os recursos de um mesmo servio. Alm disso, um mesmo usurio pode ter diferentes identidades, uma por domnio, e o ambiente da nuvem deve ser capaz de mape-las para um mesmo usurio. Por outro lado, as declaraes (entitlements), que denem o conjunto de polticas de acesso, devem ser interoperveis quanto ao formato de representao, ainda que cada domnio tenha a liberdade de especicar as suas prprias polticas de controle de acesso aos seus recursos locais. Dinamicidade: o modelo da computao em nuvem representa o cenrio atual do comrcio eletrnico, onde os relacionamentos entre os recursos ofertados/produzidos mudam rapidamente. A IdM em nuvens deve considerar a natureza dinmica da proviso de recursos virtuais e fsicos, seja por meio da alterao dinmica de servidores para ns de balanceamento de carga durante uma migrao, ou da proviso sob demanda (aplicaes elsticas) de mais recursos para os usurios/aplicaes. comum que nesses ambientes servidores e mquinas virtuais sejam iniciados e nalizados dinamicamente, sendo que a IdM deveria ser informada que o acesso futuro foi permitido ou revogado [Gopalakrishnan 2009]. Alm disso, o acesso deve ser monitorado e todos os provedores de servios devem cumprir os acordos de SLA entre mltiplos domnios. Atrasos na (des)proviso de servios poderia levar a srios riscos de segurana [Gopalakrishnan 2009]. Para esses casos, a linguagem SPML (Service Provisioning Markup Language) [OASIS 2011] fornece uma descrio em estruturas XML para representar a (des)proviso de requisies para a IdM. Apesar de no ser obrigatrio, a SPML utiliza o protocolo SAML. Escalabilidade: ambientes de computao em nuvem devem ser capazes de atender a um nmero relativamente grande de conexes, identidades e transaes em um curto espao de tempo. Dessa forma, o tempo de resposta para realizar as autenticaes/autorizaes deveria considerar os momentos de pico de consumo de recurso na rede. Interoperabilidade: atualmente existe uma corrida em torno de padres para IdM. Dentre as vrias alternativas podem ser citadas as solues de conectividade da Microsoft e os padres abertos OAuth, OpenID e SAMLv2, entre outros. Outro desao a oportunidade dos provedores escolherem os domnios mais apropriados para atenderem s suas necessidades atuais. Dessa forma, um tpico servio de rede social, por exemplo, pode utilizar servios de muitos outros provedores de nuvem, desde a simples armazenagem de dados at o processamento de grande quantidade de informaes. Ainda assim, essa oferta deve ser dinmica, ou seja, os mecanismos de interao com outros domnios devem facilitar tanto a requisio quanto a liberao de recursos adicionais, quando estes no forem mais necessrios. Outro desao ligado oferta de aplicaes elsticas em ambientes federados o fato de que os provedores podem estar localizados em diferentes regies geogrcas. Os clientes devem ser capazes de indicar em qual localidade preferem que seus dados sejam armazenados, alm de indicar suas preferncias sobre aumentar ou no a proviso de seus

recursos de acordo com a demanda. Por outro lado, um provedor pode terceirizar a sua prpria oferta de servios para atender aos quesitos de QoS de seus clientes. De acordo com [Buyya et al. 2010], uma vez que invivel o estabelecimento fsico de servidores em cada uma das regies onde os servios so acessados, os seguintes requisitos devem ser atendidos por ambientes de computao em nuvem federados: Oferta dinmica de armazenagem e recursos computacionais de outros provedores de nuvem. Negociao de acordos quanto ao nvel de servio ofertado/consumido (SLA) entre os domnios federados. Garantias quanto oferta de servios para garantir padres de QoS e minimizar os custos para o cliente nal, de forma semelhante s tarifas de gua, luz ou gs natural. De acordo com o consumo de seus clientes a infraestrutura de nuvem deve ser capaz de prever comportamentos para manter-se em plena operao a maior parte do tempo utilizando, por exemplo, algoritmos de aprendizagem, anlise estatstica do uso da rede e consumo de processamento e/ou armazenagem. Em infraestruturas do tipo SaaS a IdM se preocupa em gerenciar o controle de acesso s aplicaes. Por outro lado, infraestruturas do tipo PaaS requerem o controle de acesso plataforma e s aplicaes desenvolvidas na plataforma. Os requisitos para IdM em IaaS so similares s de PaaS, com a preocupao de controlar o acesso infraestrutura de armazenagem, processamento e demais recursos de hardware disponibilizados na nuvem [Gopalakrishnan 2009]. A principal limitao da IdM em todos esses modelos a perda de interoperabilidade caso os servios de uma nuvem sejam migrados para outra. O controle de acesso tradicional, centrado na aplicao, onde cada aplicao mantm e gerencia uma base de dados de usurios ou compartilha esta base de dados entre diversas aplicaes no so adequados para ambientes de computao em nuvem federada. Isso porque em tais ambientes h o compartilhamento de informaes entre mltiplos provedores de servios. A replicao de identidades para servir cada aplicao (one user-to-one app) no adequado devido ao crescimento exponencial [Olden 2011]. Alm disso, este modelo exige que os usurios memorizem mltiplas identidades para cada novo servio oferecido pela nuvem. O compartilhamento de bases entre aplicaes de um mesmo domnio pode ser uma alternativa, porm entre domnios federados no adequado, pois implica em questes de segurana no acesso base. Olden argumenta que para limitar a replicao de identidades em uma nuvem, o modelo de uma identidade para muitas aplicaes (one user-to-many apps) o mais adequado, ou seja, a identidade do usurio deve estar federada com estas aplicaes. Outro desao para a IdM em nuvens que atualmente cada soluo para gerncia de recursos da nuvem utiliza uma soluo prpria para gerir as identidades e o acesso a estes recursos. Dado o contexto de federao/cooperao ao qual os provedores de nuvem esto situados, a demanda por uma soluo padronizada, que contemple todas as nuances, ainda esperada. Por exemplo, para a realizao de SSO entre provedores

de nuvem, a Cloud Security Alliance recomenda que os provedores de servios devem ser exveis e que aceitem os formatos utilizados pelos provedores de identidades [Cloud Security Alliance 2009]. A entidade tambm faz ressalvas no uso de protocolos proprietrios. O IDaaS deve ser capaz de suportar diferentes mecanismos de autenticao (LDAP, RADIUS, Certicados X.509, etc.), autorizao (XACML, OAuth, dentre outros), federao (SAML, OpenID, InfoCard, etc.), diversas bases de dados (LDAP, MySQL, OpenDS, etc.), ser fracamente acoplado e no invasivo nas aplicaes SaaS [Gopalakrishnan 2009] [Olden 2011]. Olden argumenta tambm que as organizaes no devem integrar diretamente as aplicaes oferecidas em nuvem para realizar SSO e acesso a recursos. Ao invs disto, devem federar com o IDaaS, que por sua vez est pr-integrado s diversas aplicaes. 1.4.2. Desaos da Privacidade em Nuvens Os desaos da privacidade em nuvens esto nos modelos de controle de acesso empregados. Os modelos centrados no usurio so mais adequados para ambientes de computao em nuvem: as requisies aos SPs so tratadas de acordo com a identidade do usurio e suas credenciais. O controle de acesso centrado no usurio precisa conter informaes que denam unicamente um usurio no domnio. Isso implica em manter um contexto de informao por usurio, ao invs de procurar a melhor forma de reagir, em determinada situao, a determinada requisio. O modelo deve suportar pseudnimos e mltiplas e discretas identidades na proteo da privacidade do usurio [Gopalakrishnan 2009]. O modelo centrado no usurio no coloca apenas o usurio no controle de sua identidade, mas tambm adiciona mais transparncia em relao a quais dados esto sendo compartilhados e com quem. Os usurios cam mais conantes dado que esto dando permisses apropriadas a cada servio utilizado.

1.5. Padres e Solues para Implantao de Gerncia de Identidades Federadas

Esta seo apresenta alguns dos principais padres e solues utilizadas para a implantao de gerncia de identidades federadas. Dividimos as subsees a seguir em padres para autenticao e para autorizao. 1.5.1. Padres para Autenticao SAML (Security Assertions Markup Language) SAML um padro aberto baseado em XML para a troca de informaes de autenticao e autorizao em domnios que participam de um mesmo CoT [OASIS 2008]. A especicao SAML dene uma linguagem e um protocolo para a troca segura de informaes, com a nalidade de prover o SSO e identidades federadas entre os domnios do CoT, independente da arquitetura que utiliza o SAML. O protocolo SAML interopervel com outros protocolos, tais como WS-Trust, WS-Federation, e desacopla o provedor de identidades (ou seja, o IdP atua como provedor de asseres SAML) e o provedor de servios (ou seja, o SP atua como um consumidor

de asseres SAML). Uma assero SAML um documento em formato XML que gerado por um IdP e contm declaraes (statements) utilizadas pelo SP para tomar as devidas decises sobre o controle de acesso aos recursos do domnio protegido. As seguintes declaraes so denidas em uma assero SAML: a) Declaraes de autenticao: descrio que indica se o usurio foi autenticado pelo IdP em alguma interao anterior; b) Declaraes de atributos: descrio de atributos (um par do tipo nome/valor) que utilizado pelo CoT para tomar decises sobre o controle de acesso, com base nesses atribuitos; c) Declarao de deciso de autorizao: descrio que indica se o usurio/aplicao, de acordo com uma determinada restrio, pode ou no acessar o recurso. O protocolo no especica como os servios do IdP devem ser implementados, mas espera que o IdP fornea os servios de autenticao para o domnio local. Ao receber as asseres SAML do IdP, o SP decide quais sero as polticas quanto ao controle de acesso. Mais detalhes sero apresentados nas sees 1.5.3 e 1.6.4. OpenID OpenID um protocolo aberto para a proviso de identidades federadas que permite o SSO para os usurios cadastrados em sites conveis do mesmo CoT. Com o OpenID, a credencial do usurio fornecida para apenas um provedor de identidades, o qual identica o acesso desse usurio aos outros sites que ele acessa [OpenID Foundation 2011]. Portanto, no necessrio que o usurio crie uma nova conta para acessar recursos de outros sites do mesmo CoT, mas necessrio que o usurio seja autenticado em pelo menos um deles. Grandes provedores de identidades como Google, Facebook, Yahoo, Microsoft, Aol, MySpace e PayPal, entre muitos outros, fornecem suporte para o OpenID. O SSO realizado sem a necessidade de relacionamento de conana pr-existente entre os IdPs e os RPs (relaying parties), o que facilita a sua adoo [Ping Identity 2010b]. OpenID um protocolo que utiliza redirecionamentos HTTP entre o usurio/aplicao e o provedor de identidades. As requisies para acessar o servio de autenticao so baseadas no uso do protocolo HTTP. Primeiramente, o usurio deve se registrar em um provedor de identidades com suporte ao OpenID. O provedor de identidades, por sua vez, utiliza o nome da conta do usurio para gerar uma URL especca por usurio. Essa URL utilizada pelo aplicativo cliente do usurio como argumento de localizao do servio remoto de autenticao do usurio, ou seja, a autenticao vista como um servio fornecido por um dos provedores de identidade do CoT. A partir dessa URL, o aplicativo cliente capaz de identicar qual o provedor de identidades remoto no qual o usurio possui uma conta. A seguir, caso o usurio ainda no tenha se autenticado, ele deve fornecer as suas credenciais no servio de autenticao do provedor de identidades especicado na URL. OpenID tambm confere mecanismos de delegao de regras entre os provedores do mesmo crculo de conana. A Fig. 1.11 ilustra o mecanismo bsico de autenticao federada com o OpenID. No passo 1, o usurio com uma identidade registrada em um provedor OpenID (usurio com conta de e-mail no Google, por exemplo), deseja acessar recursos de um Web

site no qual ele no est cadastrado. No entanto, esse Web site possui um servio de autenticao OpenID. Para proceder com o acesso aos recursos protegidos do site, no passo 2 o usurio fornece a URL para acesso federado que recebeu de seu provedor de identidades. No passo 3, o servio OpenID do Web site redireciona o browser do usurio para o servio de autenticao do provedor de identidades, informado na URL fornecida anteriormente. No passo 4, duas opes so possveis. Caso o usurio j esteja autenticado no provedor, o browser redirecionado para o servio de vericao do endereo de origem que solicitou a autenticao com o OpenID. Caso o usurio no esteja autenticado, o provedor de identidades solicita primeiro o nome de usurio e senha, para depois proceder com o redirecionamento. No passo 5, o Web site do provedor de identidades utiliza um servio de vericao, para validar o endereo do servio que solicitou a autenticao com o OpenID. Uma razo que grande parte dos sites solicitam informaes adicionais dos novos usurios, como o nome do usurio, e-mail e telefone, dentre outros. Essas informaes podem ser fornecidas nesse passo, sem a necessidade de solicit-las novamente aps a autenticao. Caso o usurio permita que essas informaes sejam fornecidas, no passo 6 o provedor de identidades redireciona o usurio para o Web site inicial.

Fig. 1.11. Mecanismo Bsico de Autenticao Federada com o OpenID.

1.5.2. Padres para Autorizao XACML (Extensible Access Control Markup Language) XACML 2.0 [OASIS 2005] um padro que dene uma linguagem declarativa, utilizada para a descrio de polticas de controle de acesso, e uma linguagem para formular consultas (e obter respostas) utilizada para vericar se uma determinada ao ou no permitida. Como resposta consulta, um dos seguintes valores pode ser retornado: Permit, Deny, Indeterminate (um erro ocorreu, ou algum valor no foi especicado, impedindo o prosseguimento da consulta), ou Not Applicable (quando a resposta no puder ser retornada pelo servio solicitado).

O padro dene tambm uma arquitetura para a aplicao de polticas baseada no modelo abstrato denido por [IETF 2000] e [ISO/IEC 1996]. Nesta arquitetura esto presentes os seguintes componentes: Policy Enforcement Point (PEP): componente da arquitetura responsvel por interceptar requisies a recursos/servios e aplicar a deciso vinda do PDP. Context Handler: entidade responsvel por traduzir as requisies a recursos de um formato nativo ao sistema para o formato XACML e vice-versa. Policy Decision Point (PDP): componente responsvel por avaliar as polticas aplicveis e devolver ao PEP uma deciso de autorizao. Policy Administration Point (PAP): responsvel pela criao das polticas. Policy Information Point (PIP): componente responsvel por obter informaes/atributos adicionais e encaminh-los ao PDP mediante solicitao. A Fig. 1.12 apresenta uma viso geral, com os componentes centrais, PEP e PDP, atuando em uma requisio a um recurso protegido.

Fig. 1.12. Viso Geral da Arquitetura do XACML. Adaptado de [Anderson 2005]

Uma tpica requisio solicita um recurso protegido por um servidor Web, o qual atua como um PEP (passo 1). O PEP forma uma requisio com os atributos da requisio original, que so as informaes sobre o(s) recurso(s) que o usurio/aplicativo deseja interagir, a ao para a interao e outras informaes especcas da requisio. Essa requisio enviada para o PDP (passo 2), que verica se existe uma poltica que se aplica a essa requisio (passo 3), verica atributos adicionais para a tomada de deciso (passo 4) e retorna uma resposta para o PEP, contendo a deciso de autorizao (passo 5). O PEP, por sua vez, ir aplicar a deciso do PDP de permitir ou negar o acesso ao recurso (passo 6). Os documentos desta linguagem utilizam o formato XML estruturado em trs nveis (policy language model): a) PolicySet: descrio de um conjunto de polticas ou outros PolicySets; b) Policy: descrio de uma poltica especca. Polticas so denidas como um conjunto de regras; c) Rule: descrio de uma regra. Regras denem se

um recurso pode ou no ser acessado, a partir dos atributos fornecidos e das restries denidas em cada regra. Um documento XACML tambm especica um Target. Caso todas as condies para o Target forem satisfeitas, ento PolicySet, Policy e Rule relativas a esse Target so aplicadas requisio. As condies para um Target so satisfeitas por meio de comparaes dos valores da requisio com os denidos para o Target. Os atributos de uma requisio so caractersticas do usurio/aplicao (sujeito), tais como o nome, perl de acesso, recurso que o usurio quer acessar, perodo (data e hora) em que se quer acessar o recurso, entre outros. Os atributos tambm so caractersticas denidas para o recurso a ser acessado, para a ao a ser tomada e para o ambiente (localizao do sujeito). Portanto, o PDP lida com comparaes lgicas sobre esses valores (por exemplo, por meio de consultas XPath), de forma a responder requisio do PEP para o acesso ao recurso protegido. O Quadro 1.1 ilustra um exemplo de documento XACML para descrever uma poltica de controle de acesso que permite a todos os usurios do domnio realcloud.dca.fee.unicamp.br acessarem recursos protegidos.
<? xml v e r s i o n = " 1 . 0 " e n c o d i n g = "UTF8" ? > < P o l i c y P o l i c y I d =" i d e n t i f i e r : e x a m p l e : S i m p l e P o l i c y 1 " RuleCombiningAlgId= " i d e n t i f i e r : r u l e c o m b i n i n g a l g o r i t h m : d e n y o v e r r i d e s " > <Target> < S u b j e c t s >< A n y S u b j e c t / >< / S u b j e c t s > < R e s o u r c e s >< AnyResource / >< / R e s o u r c e s > < A c t i o n s >< AnyAction / >< / A c t i o n s > </ Target> <Rule RuleId =" i d e n t i f i e r : e x a m p l e : S i m p l e R u l e 1 ? E f f e c t =" P e r m i t "> <Target > <Subjects > <Subject > < S u b j e c t M a t c h M a t c h I d = " f u n c t i o n : r f c 8 2 2 n a m e e q u a l " > < S u b j e c t A t t r i b u t e D e s i g n a t o r A t t r i b u t e I d = " i d e n t i f i e r : s u b j e c t : s u b j e c t i d " DataType = " i d e n t i f i e r : d a t a t y p e : r f c 8 2 2 n a m e " / > < A t t r i b u t e V a l u e DataType = " i d e n t i f i e r : d a t a t y p e : r f c 8 2 2 n a m e " > @ r e a l c l o u d . d c a . f e e . unicamp . br < / A t t r i b u t e V a l u e > </ S u b j e c t M a t c h > </ S u b j e c t > </ S u b j e c t s > < R e s o u r c e s >< AnyResource / > < / R e s o u r c e s > < A c t i o n s >< AnyAction / > < / A c t i o n s > </ T a r g e t > </ Rule > </ P o l i c y >

Quadro 1.1. Exemplo de Documento XACML para Descrever uma Poltica. Baseado em [Stoller 2011].

Dentre as vantagens da linguagem XACML para a denio de polticas est o fato dela ser descrita em XML. Com isso XACML pode ser estendida e reutilizada entre diversas aplicaes/organizaes. No h a necessidade de reescrever uma poltica em diversas linguagens diferentes para cada cenrio. Outro fator que ela pode ser utilizada nos mais diversos cenrios, uma vez que ela de propsito geral [Stoller 2011]. OAuth O protocolo OAuth um padro aberto de autenticao que fornece um mecanismo para que um usurio/aplicao possa compartilhar recursos na Web com terceiros sem ter que compartilhar a sua senha [OAuth Community 2011]. Esse protocolo tambm fornece uma alternativa para autorizar o acesso a esses recursos por um determinado tempo. Dessa forma, um usurio proprietrio de um recurso (um lbum de fotos, por exemplo) pode oferecer acesso temporrio a esse recurso sem compartilhar a sua

identidade (nome de usurio e senha). Usurios que desejam ter acesso a esse recurso o fazem por meio de um servio de delegao. No modelo OAuth existem trs elementos principais no processo de autorizao: o dono do recurso, o cliente e o servidor. Para o cliente acessar um recurso ele deve primeiramente obter uma autorizao do dono do recurso, ou seja, o cliente recebe do dono do recurso uma permisso para acessar temporariamente o recurso, na forma de um token e uma chave secreta compartilhada. OAuth tambm verica a autorizao do dono do recurso e a identidade do cliente que faz a requisio a esse recurso [OAuth Community 2010]. O cenrio descrito acima semelhante ao utilizado pelo OAuth para autorizar o acesso a recursos Web a partir de provedores como o Twitter [Twitter 2011]. A Fig. 1.13 ilustra um cenrio onde um usurio publica as suas fotos no site ServidorRecurso.net e deseja utilizar outro site para imprimi-las (Cliente.net). No entanto, o usurio dono do recurso no quer compartilhar a sua identidade (nome de usurio e senha) com o site de impresso. No passo 1, ocorre o registro da aplicao cliente do site Cliente.net que deseja acessar o site ServidorRecurso.net. Um modelo similar aos de chave pblica e privada utilizado. Para cada aplicao registrada ser fornecida uma OAuth consumer key (chave pblica) e uma OAuth consumer secret (chave privada). Essas chaves so utilizadas para autenticar o usurio/aplicao (por exemplo, via Twitter API), garantindo que o trfego seja do usurio portador dessas chaves. Por padro, a Twitter API envia requisies no cabealho das mensagens HTTP (HTTP Authorization header). No passo 2, as aplicaes Web registradas devem fornecer uma URL de callback que o servidor do recurso ir utilizar para redirecionar o browser do usurio aps a autenticao. O conjunto de endpoints que ser utilizado nas interaes tambm deve ser congurado: a) Temporary Credential Request - endereo para iniciar a solicitao de acesso ao recurso; b) Resource Owner Authorization - endereo para solicitar o servio de autorizao de acesso ao recurso; c) Token Request URI - endereo para solicitar tokens de acesso. Antes do cliente ser autorizado a acessar os recursos, no passo 3 ele deve solicitar credenciais temporrias, a partir do endereo informado em Temporary Credential Request. O ServidorRecurso.net valida a solicitao porque Cliente.net possui uma oath_consumer_key (chave pblica) vlida. No passo 3.1, aps validar a requisio, o servidor ServidorRecurso.net retorna uma mensagem HTTP contendo a oauth_token e oauth_token_secret. No passo 4, a aplicao cliente em Cliente.net redireciona o browser do usurio para o endereo do Resource Owner Authorization, com a nalidade de obter a autorizao do dono do recurso para acessar as suas fotos. No passo 5, ServidorRecurso.net/authorize solicita o acesso do dono do usurio ao recurso, usando o nome de usurio e senha do dono do recurso. Note que esse processo de autenticao ocorre no ServidorRecurso.net, ou seja, o dono do recurso se autentica em seu prprio domnio para delegar o acesso ao site Cliente.net. Quando conrmada a autenticao, o ServidorRecurso.net solicita a autorizao do dono do recurso para que Cliente.net acesse o recurso. Caso o dono do recurso aprove, o browser redirecionado para a URL de callback informada no registro da aplicao.

At aqui, Cliente.net completou o seu processo de autorizao. No passo 6, ele solicita o acesso a um token utilizando as credenciais temporrias que j obteve at ento, ou seja, oauth_consumer_key, oauth_token e oauth_verier. No passo 6.1, o servidor valida a requisio (como o fez no passo 3.1), porque a requisio possui uma oauth_consumer_key vlida. O servidor tambm valida a requisio de acesso ao token porque recebeu oauth_token e oauth_verier vlidos. Aps essa validao, o ServidorRecurso.net retorna no corpo da mensagem HTTP um conjunto de credenciais temporrias, ou seja, um novo oauth_token e um oauth_token_secret. Note que o oauth_consumer_key no muda durante a interao porque est relacionado com a autenticao do usurio dono do recurso. No passo 7, o Cliente.net possui um conjunto de credenciais temporrias que lhe autorizam a acessar o recurso. Nesse passo, Cliente.net solicita um recurso de ServidorRecurso.net enviando oauth_consumer_key e o novo oauth_token. O ServidorRecurso.net ir validar o acesso porque recebeu um oauth_consumer_key e oauth_token vlidos. O acesso de Cliente.net permitido enquanto durar o tempo de vida do token, ou enquanto o dono do recurso autorizar o acesso.

Fig. 1.13. Diagrama de Sequncia Simplicado do OAuth.

1.5.3. Solues Shibboleth Shibboleth [Internet2 2011] um middleware gratuito e de cdigo aberto desenvolvido pela comunidade Internet2 que prov uma soluo de SSO, baseado em padres abertos (principalmente XML e SAML) para autenticao e autorizao na Web. Shibboleth um sistema para a criao de federaes que oferece funcionalidades para a troca segura de dados para acessar recursos entre domnios. Utilizado inicialmente para integrar instituies acadmicas, hoje ele usado por uma variedade de sites em todo o mundo. Os principais elementos do Shibboleth so o SP e o IdP. O processo para

determinar o IdP do usurio pode fazer uso de um servio de descoberta conhecido como IdP Discovery que exibe uma lista dos IdP conveis cadastrados no crculo de conana. Na arquitetura do Shibboleth, o acesso do usurio a recursos realizado por meio de asseres SAML recebidas de um IdP convel. Nessa arquitetura, os seguintes componentes so denidos para o SP: Recurso Alvo: os recursos Web so protegidos no SP por meio de servios de Controle de Acesso, o que impede usurios no autenticados/autorizados de acessarem esses recursos. Servio Consumidor de Asseres: responsvel por processar a assero de autenticao do Servio de SSO, que foi retornada pelo IdP. Alm disso, esse componente redireciona o browser do usurio para o recurso desejado. Requisitante de Atributos: uma vez que um contexto de segurana tenha sido estabelecido por meio da validao m-a-m das asseres SAML trocadas entre IdP e SP, atributos podem ser trocados diretamente entre o SP (com o uso do componente Requisitante de Atributos) e o IdP (com o uso do componente Autoridade de Atributos). O IdP Discovery tratado na arquitetura como um servio de proxy para realizar o redirecionamento do usurio para o domnio que possui o servio de autenticao. O IdP Discovery tambm lista o conjunto de IdPs disponveis para que o usurio escolha o domnio de autenticao mais adequado. Para o IdP so denidos os seguintes componentes: Autoridade de Autenticao: lida com questes relacionadas autenticao para outros componentes e responsvel por gerar a assero de autenticao no IdP. Servio de SSO: responsvel por iniciar o processo de autenticao no IdP e vericar a existncia e validade dos cookies de sesso, e interagir com o componente Autoridade de Autenticao para gerar a assero de autenticao no IdP. Servio de Resoluo: quando o SP dene um perl que utiliza a troca de asseres por referncia, esse servio responsvel por tratar essas requisies. Um artefato uma referncia para uma assero de autenticao. Ou seja, ao invs de enviar a assero de resposta de autenticao via o browser do usurio, enviada uma referncia a assero expedida. Esta forma do SP obter a assero denominada artifact binding, conforme o padro SAMLv2. Autoridade de Atributos: responsvel por autorizar e autenticar requisies que lidam com atributos de usurios. Como ilustrado na Fig. 1.14, uma requisio de autenticao com o Shibboleth uma mensagem enviada pelo SP e que contm uma URL enviada para o Servio de SSO do IdP [Scavo and Cantor 2005]. No passo 1, essa requisio feita para acessar um recurso protegido pelo SP. Caso j exista um contexto de segurana vlido, segue-se para

Fig. 1.14. Fluxo de Mensagens na Arquitetura do Shibboleth.

o passo 8. No passo 2, o browser do usurio redirecionado para o IdP Discovery. No passo 3, o IdP Discovery verica se existe um cookie de sesso e sua validade, e processa uma requisio de autenticao do usurio. Caso o usurio tenha um cookie vlido, os passos 4 e 5 no so realizados. Caso contrrio, um formulrio HTML com uma lista de IdPs fornecida. No passo 4, o IdP Discovery fornece uma lista de IdP disponveis para que o usurio escolha onde deseja ser autenticado. No passo 5, o usurio seleciona o IdP desejado e uma requisio HTTP/GET enviada novamente para o IdP Discovery. No passo 6, o IdP Discovery atualiza o cookie de sesso com as informaes do IdP escolhido pelo usurio e redireciona o browser do usurio para o Servio de SSO do IdP escolhido no passo anterior. No passo 7, o Servio de SSO requisitado no IdP e este servio adquire uma declarao de autenticao (uma assero SAML) da Autoridade de Autenticao. No passo 8, a assero SAML retornada para o browser do usurio, aps o usurio fornecer as suas credenciais por meio de uma mensagem HTTP/POST. No passo 9, o Servio Consumidor de Asseres do SP consulta a assero SAML do IdP. No passo 10, o Servio Consumidor de Asseres processa a resposta da autenticao (alm de outras vericaes, a assero ser vlida caso o usurio tenha fornecido credenciais vlidas no passo 8). Caso o usurio tenha fornecido credenciais vlidas, um contexto de segurana criado no SP, com o posterior redirecionamento do browser do usurio para o recurso protegido. No passo 11, o browser requisita novamente o acesso ao recurso protegido. No passo 12, com um contexto de segurana vlido, o browser redirecionado para a URL do recurso solicitado. O processo de congurao de federaes com Shibboleth no trivial, uma vez que envolve a adaptao dos servios do SP, das regras de controle de acesso do domnio, do IdP Discovery e da descrio dos atributos necessrios para acessar o recurso [Hmmerle 2011]. A congurao de um sistema Shibboleth tambm envolve a manuteno de um intricado conjunto de arquivos. A federao CAFe [RNP 2011] um exemplo brasileiro de instituies acadmicas de ensino e de pesquisa que implementa uma federao com um conjunto de atributos prprios, com o esquema de dados conhecido como brEduPerson. Esses atributos denidos nas asseres SAML estabelecem quais recursos essas entidades podero requisitar umas das outras, de forma que os provedores de identidades saibam quais atributos devem ser oferecidos.

Projeto Higgins Higgins um projeto em desenvolvimento pela Eclipse Foundation [Eclipse Foundation 2011]. Seu objetivo integrar identidades, pers e informaes relacionadas a redes sociais entre diversos sites, aplicaes e dispositivos utilizando componentes extensveis. Mltiplos protocolos de identidades foram propostos ao longo do tempo, tais como LDAP, WS-Trust, SAML, XDI, OpenID, entre outros. Para os desenvolvedores de sistemas de gerncia de identidades federadas, h a necessidade de suportar estes diversos protocolos, o que resulta em complexidade no software bem como na gerncia de identidades federadas. Para os usurios, este fator pode causar confuso pois estes precisaro gerenciar para qual entidade foi compartilhada qual informao. Por exemplo, o nmero do carto de crdito no interessante de compartilhar em uma rede social, ao passo que em uma loja de vendas on-line sim. Para tratar estas questes, o projeto Higgins apresenta um framework que prov as seguintes tecnologias [Eclipse Foundation 2011]: Um seletor de identidades multiplatforma (Mac OS X, Linux, Windows, etc.) e navegadores (Firefox, Safari, IE, Chrome, etc.) que podem ser utilizados para autenticao em sistemas e sites compatveis com o modelo centrado no usurio, denominado Information Card (i-card). Segundo o projeto, este modelo oferece ao usurio menos senhas, mais convenincia e melhor segurana onde todas as informaes do usurio cam armazenadas em um carto. Provedores de identidades, baseado em servios Web, que trabalham com os padres WS-Trust (STS - Security Token Service) e SAML 2.0, ambos expedem i-cards. Prov tambm o cdigo necessrio para que provedores de servio incorporem e aceitem estes i-cards. Implementa um modelo de dados chamado na verso 2.0 de Persona Data Model (PDM), estendendo o modelo da verso 1.x, denominado Higgins Data Model (HDM) 1.0. O Higgins oferece tambm um servio de atributos de identidade denominado Higgins Identity Attribute Service (IdAS). Com estas solues, os desenvolvedores possuem uma camada de abstrao para obter interoperabilidade e portabilidade entre diferentes silos de informao de identidade, diferentes fontes de dados, tais como diretrios, bancos de dados relacionais e redes sociais.

Fig. 1.15. Arquitetura do Higgins. Adaptado de [Eclipse Foundation 2011]

A Fig. 1.15 apresenta a arquitetura em alto nvel do Higgins 2.0. Nesta gura, o componente Servio de Dados Pessoais responsvel por prover servios para o componente Cliente, localizado no browser do usurio. Dentre os servios prestados esto aqueles para gerncia de contas, alterao de passwords, etc. O componente Cliente uma interface em JavaScript desenvolvida para que o usurio possa ver e editar seus cartes. Este JavaScript carregado do Servio de Dados Pessoais para o browser do usurio via o componente Extenso do Browser. Este componente responsvel por estender as funcionalidades de um browser padro. Ele tambm prov uma API para que o script possa escrever e ler do componente Servio de Atributos. Isto permite, por exemplo, que o script armazene informaes vindas de uma pgina Web. O componente Servio de Atributos um repositrio do tipo RDF/OWL (Resource Description Framework/Web Ontology Language) contendo dados do usurio. Estes dados utilizam um vocabulrio denido pelo modelo Persona Data Model 2.0. O Servio de Atributos expe estes dados para o Portal e para o componente Extenso do Browser via uma interface baseada em mensagens HTTP e mtodos do tipo push. Ele tambm expe os dados via uma interface SPARQL (SPARQL Protocol and RDF Query Language - acrnimo recursivo) para integrao entre servidores [Eclipse Foundation 2011].

OpenAM O middleware OpenAM uma soluo de cdigo aberto responsvel por oferecer servios de autenticao e autorizao, federao, SSO, monitorao, logging e proviso de identidades. Com a aquisio da empresa Sun Microsystems pela Oracle, o produto originalmente conhecido como OpenSSO passou a ser mantido pelo grupo ForgeRock, porm com o nome de OpenAM. Os servios de autenticao, autorizao, vericao de validade de tokens, logging e proviso de identidades, oferecidos pelo OpenAM, podem ser acessados tanto via HTTP, quanto via servios Web, ou por meio de um agente. Este modelo pode ser visto como um IDaaS para controle de acesso e proviso de identidades federadas [ForgeRock 2010]. O OpenAM possui uma arquitetura de software cliente/servidor. Desenvolvido em Java e distribudo sob a forma de uma aplicao Web J2EE, ele trabalha com diversos padres abertos. A Fig. 1.16 ilustra a arquitetura simplicada do OpenAM. Basicamente, o OpenAM est subdividido em 3 camadas (Interface Cliente, Ncleo e Camada de Integrao). Uma descrio mais detalhada da arquitetura pode ser obtida em [Thangasamy 2011]. A primeira camada responsvel por prover interfaces de comunicao para que aplicaes possam utilizar os servios providos pela camada Ncleo. Esta camada pode ser acessada via servios Web, atravs de SOAP ou HTTP. A camada Ncleo onde esto os componentes fundamentais da arquitetura do OpenAM. Esta camada atua como um broker entre a Interface Cliente e os componentes servidores [ForgeRock 2010]. Os servios providos por componentes desta camada so: autenticao, autorizao, gerncia de sesso (SSO), logging, acesso a repositrios de identidades e federao. Os cinco primeiros servios so implementados como servlets e as requisies e respostas so baseadas em mensagens XML sobre HTTP. O componente de federao

Fig. 1.16. Arquitetura Simplicada do OpenAM.

trabalha com as seguintes especicaes: OASIS SAML (SAML1.1 e SAML 2.0), Liberty Alliance (ID-FF 1.2 e ID-WSF 1.1), WS-Security (WS-I BSP), WS-Trust e WS-Federation (WS-Federation 1.1). Cada servio da camada Ncleo oferece uma SPI (Service Provider Interface) para extenso. A Camada de Integrao prov as interfaces para extenso destes servios. Como requisito para sistemas de gerncia de identidades federadas, esta camada permite, por exemplo, a extenso para mltiplos mecanismos de autenticao e para mltiplos repositrios de identidades. O OpenAM suporta tambm agentes. Estes so parte da arquitetura do OpenAM e so implementados como ltros instalados em servidores de aplicao tais como Apache, Tomcat, WebLogic e Glasssh. Os agentes so utilizados para interceptar requisies a recursos Web e encaminhar estas requisies para o OpenAM. Os agentes tambm utilizam as interfaces clientes do OpenAM para interagir com o servio de autenticao, autorizao, federao, sesso e logging. A Fig. 1.17 ilustra uma implantao bsica do OpenAM e do agente protegendo recursos Web.

Fig. 1.17. Implantao bsica do OpenAM.

O agente instalado em servidores de aplicao onde os recursos a serem protegidos esto executando. Em geral estes servidores esto localizados atrs de um rewall externo, ou seja, em uma zona desmilitarizada. O OpenAM executa em outro servidor de aplicao, juntamente com um servidor de banco de dados, ambos atrs de um rewall interno. Uma requisio a uma pgina, por exemplo, feita por um usurio,

atravs de um browser, ser interceptada pelo agente instalado no servidor onde a pgina servida e far com que o agente verique se o usurio possui credenciais para acesso a este recurso. Em caso negativo, o browser do usurio ser redirecionado para o OpenAM. O OpenAM far o processo de autenticao deste usurio e ir redirecionar o mesmo de volta para a pgina, caso a autenticao seja bem sucedida. 1.5.4. Tabela Comparativa A Tab. 1.1 apresenta as solues de gerncia de identidades federadas e os padres estudados neste minicurso. Solues Shibboleth 2.x Higgins 2.0 OpenAM 9.5.x SAML 2.0 OpenID 2.0 Plugin XACML 2.0 Extenso OAuth 1.0 Plugin Paradigma Federado C.Usurio Federado

Tab. 1.1. Tabela Comparativa entre Solues Abertas em IdM.

Como podemos observar na Tab. 1.1, o padro para autenticao em gerncia de identidades federadas mais utilizado entre as solues abertas estudadas o SAML. O OpenID, por sua vez, no est presente no Shibboleth e nem no Higgins, mas pode ser integrado ao OpenAM mediante a instalao de um plugin. Com relao aos padres para autorizao, o XACML contemplado apenas pelo OpenAM. O Shibboleth requer uma extenso baseada em uma soluo de repositrio do Fedora. O OAuth no suportado nativamente por nenhuma das solues. Apenas o OpenAM oferece a possibilidade de instalao de um plugin. Nenhuma das solues apresentadas oferece suporte nativo a todos os padres de gerncia de identidades federadas estudados. Para ambientes de computao nuvem esta caracterstica importante, dado que o nmero de aplicaes oferecidas como servio so variadas. Apesar disso, o OpenAM uma soluo exvel que permite a possibilidade de extenso a partir da criao e instalao de plugins. Para um provedor IDaaS esta caracterstica interessante. A utilizao do OpenID e OAuth so mais adequados para ambientes de redes sociais (blogs, mash-ups), j que se propem a serem solues sem muita preocupao com a troca convel de mensagens. O padro SAML possui uma preocupao maior com a segurana, j que utiliza certicados digitais na troca de mensagens. Uma comparao mais detalhada entre o SAML e o OpenID pode ser encontrada em [Hodges 2009]. O XACML um padro que pode ser utilizado em conjunto com o SAML, podendo assim oferecer uma soluo de autenticao e autorizao em ambientes organizacionais. O Higgins a nica soluo estudada que adota o paradigma centrado no usurio, porm ainda um projeto que est em evoluo. Dentre as vantagens j citadas este paradigma possibilita maior autonomia ao usurio no compartilhamento de informaes de sua identidade. O OpenAM, por ter uma arquitetura exvel, pode operar segundo o paradigma centrado no usurio, desde que seja instalado um plugin que implemente um padro neste paradigma.

Observamos que as solues estudadas, apesar de no suportarem a maioria dos novos padres e paradigmas de gerncia de identidades federadas, esto no processo de evoluo para suport-los. Isto importante para provedores de nuvem, especialmente provedores IDaaS, que necessitam de uma infraestrutura exvel para atender demanda por servios federados.

1.6. Estudo de Caso: Plataforma REALcloud

Uma das motivaes para o desenvolvimento de uma arquitetura para computao em nuvem oferecer a plataforma REALabs como servio (PaaS). Esta plataforma foi desenvolvida pelos autores para a interao remota com recursos robticos [Guimares et al. 2011]. REALabs oferece uma infraestrutura de software para o acesso remoto a um laboratrio de robtica mvel. Nesta plataforma os experimentos robticos so executados no computador do usurio e operam os robs por meio de uma rede de comunicao (usualmente a Internet). Esta forma de operao, apesar de funcional, traz algumas limitaes. A principal delas com relao ao atraso imposto pela rede. Sem uma rede de alta velocidade o controle dos robs ca prejudicado devido ao atraso na comunicao com o rob. Alm disso, os usurios necessitam de CPU e memria considerveis para execuo dos experimentos. Um requisito tambm necessrio qualidade de servio que no garantida na Internet [Cardozo et al. 2010]. Outro ponto a ser considerado a questo da segurana. Os recursos robticos so caros e por isso necessitam de um controle de acesso aprimorado para permitir que apenas os usurios autenticados e autorizados possam acessar tais recursos. O acesso a estes recursos necessita de um modelo baseado em polticas compatvel com o modelo de utilizao dos recursos estabelecido pelo administrador do laboratrio. Com a difuso de laboratrios de acesso remoto na Internet (WebLabs) surge a oportunidade de operar estes WebLabs de forma federada. Este conceito reforou a necessidade de um controle de acesso aprimorado, que precisa contemplar acessos de usurios vindos de domnios parceiros. Com o advento da computao em nuvem e os conceitos agregados de virtualizao, computao orientada a servios, computao sob demanda, modelo de acesso ubquo, dentre outros, observou-se que a aplicao destes conceitos e tecnologias no contexto de WebLabs trazem ganhos signicativos. A execuo de experimentos em nuvem, tendo a mquina virtual do usurio na rede fsica dos recursos, permite um modelo mais adequado de experimentao. Neste modelo observa-se um ganho de desempenho na interao dos experimentos robticos com os recursos, dado que tais experimentos executam na mquina virtual do usurio localizada no mesmo enlace de rede dos recursos. Do ponto de vista da IdM, o desao oferecer uma infraestrutura que seja aderente realidade colaborativa. O oferecimento da identidade como um servio unicado de nuvem (IDaaS) essencial para que as aplicaes SaaS, PaaS e IaaS possam utilizar seus servios sem necessitar recorrer a mecanismos individualizados de controle de acesso, fato este que inviabilizaria a gerncia medida que o nmero de servios e colaboraes aumentam. Outra questo importante que este servio permite realizar SSO entre os diferentes domnios federados. Esta infraestrutura tambm permite a integrao de contas

de usurios provindas de diferentes domnios. Outra considerao que o servio IDaaS permite utilizao de diferentes padres de federao. 1.6.1. Viso Geral da Plataforma REALcloud Para tratar os problemas relacionados no tpico anterior, desenvolvemos a plataforma REALcloud [Feliciano et al. 2011] [Agostinho et al. 2011]. Nesta plataforma, h uma infraestrutura de nuvem privada para os estudantes utilizarem os servidores conectados aos robs atravs de uma rede local para realizarem os seus experimentos. Como o WebLab um ambiente colaborativo, so utilizados os conceitos denidos pela gerncia de identidades federadas para gerenciar o uso dos recursos distribudos entre os diferentes domnios parceiros e seus experimentadores. A Fig. 1.18 apresenta uma viso em alto nvel da plataforma REALcloud. A gura apresenta um conjunto de nuvens privadas e pblicas conectadas atravs da Internet e/ou uma rede privada de alta velocidade. A nuvem privada oferece recursos tais como CPU, unidades de armazenamento e conexes de rede para as aplicaes que executam os experimentos. Esta nuvem oferece tambm recursos de hardware especializados tais como GPUs (Graphics Processing Units) e FPGAs (Field-Programmable Gate Arrays) e tambm plataformas de software especcas, tais como Matlab.
Mquinas Virtuais Internet ou Rede de Nuvem Privada Plataforma de Gerncia Mquinas Virtuais

Alta
Velocidade

Nuvem Pblica Plataforma de Gerncia

Nuvem Privada Dispositivos Controlados

Dispositivos Controlados

Fig. 1.18. Arquitetura de Alto Nvel da Plataforma REALcloud.

A nuvem pblica oferece recursos computacionais para aplicaes e componentes que no necessitam de um tratamento de qualidade de servio e segurana aprimorados. Alguns destes recursos podem ser oferecidos como servios, por exemplo, servios de gerncia de WebLabs. A nuvem pblica pode atuar como um provedor de identidades, permitindo que os usurios possam se autenticar, por exemplo, com uma conta do Yahoo! e com isso utilizar recursos habilitados para este tipo de usurio. A nuvem pblica pode tambm servir para ampliar uma facilidade que alguma nuvem privada porventura necessite. 1.6.2. Arquitetura da Plataforma REALcloud A plataforma REALcloud possui as seguintes caractersticas: Gerncia de identidades federadas, para permitir o compartilhamento seguro de recursos e SSO entre os domnios federados.

 Controle de acesso para prevenir acessos no autorizados e manipulao acidental dos dispositivos fsicos controlados. Plataforma para gerncia de mquinas virtuais. Controle de QoS de rede, para que as aplicaes tenham baixo atraso e largura banda adequadas. Cada requisito acima atendido por um servio especializado. O Servio de Gerncia de Identidades Federadas responsvel pelo estabelecimento de federaes entre as nuvens pblicas e privadas e proteo para os servios restantes. Este servio prov tambm SSO e oferece uma API baseada em REST para utilizao da identidade como um servio (IDaaS). O Servio de Gerncia de Acesso aos Dispositivos permite ao administrador do domnio registrar os dispositivos fsicos disponveis e outros recursos, bem como estabelecer polticas para sua manipulao (por exemplo, uso mediante reserva). Este servio permite tambm o estabelecimento de sesses seguras de acesso aos dispositivos controlados. Virtualizao uma tecnologia chave para a computao em nuvem. Mquinas virtuais oferecem isolamento e recursos computacionais de acordo com a demanda do usurio. No nosso caso, a virtualizao tambm oferece a possibilidade das aplicaes estarem prximas dos dispositivos controlados, reduzindo o atraso inerente que degrada a operao dos dispositivos. O Servio de Gerncia de VMs permite aos administradores atribuir VMs aos usurios ou grupo de usurios, bem como permite aos usurios acessar (mediante credenciais) e controlar suas VMs. Para proteger os dispositivos controlados contra acessos no autorizados, o Servio de Gerncia de Acesso aos Dispositivos utiliza-se de mecanismos de rewall providos pelo Servio de Controle de Rede. Este servio realiza um controle de acesso no nvel de encaminhamento de pacotes que bloqueia o acesso no autorizado e estabelece privilgios no nvel de rede para as aplicaes que estabeleceram uma sesso de acesso. A Fig. 1.19 ilustra os servios de gerncia denidos para a plataforma REALcloud (Plataforma de Gerncia na Fig. 1.18). Cada pacote representa um servio e as linhas pontilhadas relacionam as dependncias entre estes servios.

Servio de Gerncia de Identidades Federadas

Servio de Controle de Rede

Servio de Gerncia de Acesso a Dispositivos

Servio de Gerncia de VMs

Fig. 1.19. Servios de Gerncia da Plataforma REALcloud e suas Dependncias.

1.6.3. Servios da Plataforma REALcloud A plataforma REALcloud especializa os servios identicados na arquitetura proposta (Fig. 1.19).

Gerncia de Identidades Federadas O servio de Gerncia de Identidades Federadas na plataforma REALcloud adota o OpenAM. Este middleware foi congurado para funcionar com os pers Web SSO e IdP Discovery, denidos pela especicao do SAMLv2. Na plataforma empregado um modelo para a gerncia de identidades federadas onde os componentes SP, IdP e IdP proxy esto dispostos em um modelo em camadas. A Fig. 1.20 mostra este modelo acrescido das funcionalidades dos componentes PIP, PAP, PEP e PDP, conforme empregados no padro XACML.
PIP
Camada de Controle de Acesso

PDP

PAP

SP

PEP

Camada de Federao

CDS

IdP proxy

Camada de Persistncia de Identidades

IdP

Fig. 1.20. Modelo em Camadas dos Componentes para IdM [Feliciano et al. 2011].

Quando um usurio necessita acessar algum recurso da plataforma, o SP, com o auxlio do componente PEP, intercepta a requisio e verica se a requisio possui as credenciais necessrias. Se nenhuma credencial for encontrada, o SP redireciona o usurio para o IdP proxy, que por sua vez apresenta uma listagem contendo os possveis IdPs. O usurio seleciona um IdP relacionado ao domnio, onde o mesmo possui uma identidade e redirecionado para autenticao. Uma vez autenticado, o IdP expede uma credencial (uma assero SAML) e redireciona o usurio para o componente CDS (Common Domain Service), que adiciona um cookie de domnio comum (cookie de federao). Na sequncia, o componente CDS redireciona o browser para o IdP proxy. Este, por sua vez, apenas verica qual foi o SP requisitante e, com isso, redireciona o usurio para este SP. O SP novamente verica a existncia de uma credencial de acesso e, desta vez, a presena da credencial permitir o acesso ao recurso originalmente solicitado. Como a autenticao foi realizada com SSO, o usurio tambm est apto a acessar recursos existentes nos domnios pertencentes ao crculo de conana, caso as polticas de autorizao permitam tal operao.

Gerncia de Acesso a Dispositivos A Gerncia de Acesso a Dispositivos realiza trs funes, implementadas como servio: 1. Registro de Recursos: este servio permite a criao de uma lista de recursos a serem protegidos. Esta lista armazena, para cada recurso, as suas propriedades (nome, dono do recurso, modelo, etc.), largura de banda requerida para a realizao do experimento e a URI (Uniform Resource Identier) que identica o recurso. Para a realizao de um experimento, os recursos podem ser agrupados. Por exemplo, um brao robtico e uma cmera podem ser agrupados para que a cmera mostre os movimentos do brao. Este agrupamento feito mediante reserva, provida por este servio. O servio permite que o administrador separe fatias de tempo para a utilizao de cada recurso ou grupo de recursos e a durao mxima da reserva no dia. 2. Reserva: um servio que permite aos usurios agendar reservas futuras para a utilizao dos recursos, respeitando as fatias de tempo disponveis e a durao mxima da reserva estipulada pelo administrador. 3. Controle de Sesso: usado para estabelecer a sesso de acesso aos dispositivos, usualmente durante o perodo da reserva. As sesses de acesso mantm o estado da utilizao dos recursos, por exemplo, a identidade do usurio, perodo de acesso e os recursos permitidos.

Gerncia de VMs O servio de Gerncia de VMs na plataforma REALcloud permite que os usurios iniciem e desliguem suas respectivas VMs mantidas nas nuvens pblicas e privadas. Os usurios podem acessar suas VMs a qualquer horrio, sem necessidade de reserva de horrio. Porm, este acesso no habilita o usurio acessar os recursos protegidos do laboratrio. O acesso aos recursos protegidos s liberado se o usurio possuir uma sesso de acesso obtida do servio de Gerncia de Acesso a Dispositivos. Assim que o usurio estabelece uma sesso, o servio de Gerncia de Acesso a Dispositivos interage com o servio de Controle de Rede para habilitar o acesso da VM que estabeleceu a sesso para o dispositivo fsico e armazenar as regras de encaminhamento de trfego de acordo com o dispositivo acessado. Esses privilgios de acesso so descartados quando a sesso de acesso terminar. Uma sesso pode terminar explicitamente pelo usurio ou pelo servio de Gerncia de Acesso a Dispositivos, quando o perodo da reserva terminar.

Virtualizador, Controle de Rede e Encaminhamento de Pacotes Virtualizador um servio para estabelecer a interao com diferentes solues de virtualizao, tais como libvirtd, KVM e VirtualBox. Utiliza-se estes pacotes para abstrair

a soluo de virtualizao, por exemplo, alteraes na tecnologia de virtualizao tem impacto reduzido em toda a arquitetura. O servio de Controle de Rede necessrio para interagir com o mecanismo de encaminhamento de pacotes, empregar polticas de rewall e para realizar diferenciao de trfego. O servio de Encaminhamento de Pacotes ltra o trfego direcionado aos dispositivos fsicos de/para a VM que possui uma sesso de acesso vlida. A priorizao de trfego permite estipular classes de servios (prioridades) de acordo com o dispositivo fsico sendo acessado. Por exemplo, imagens em tempo real utilizadas para controlar o rob mvel devem ter maior prioridade do que imagens geradas por uma cmera panormica, utilizada para visualizao dos experimentos. A classe de servio e a banda requerida so especicadas atravs do servio de Registro de Recursos. A atual verso da plataforma REALcloud no suporta SLAs. A Fig. 1.21 apresenta os servios oferecidos pela plataforma REAcloud e a sua inter-relao em notao UML. importante ressaltar que as linhas tracejadas modelam os uxos da interao.

Registro de Recurso

Gerncia de Acesso a Dispositivos

IdM Federadas

Reserva

Controle de Sesso

Gerncia de VMs

Encaminhamento de Pacotes

Controle de Rede

Virtualizador

Fig. 1.21. Servios de Gerncia da Plataforma REALcloud.

1.6.4. Implementao da Plataforma REALcloud O servio de Gerncia de VMs um servlet Java que expe uma interface Web para controlar o ciclo de vida das VMs, utilizando os servios do Virtualizador. Os demais servios oferecidos pela plataforma REALcloud esto descritos na sequncia. Servio de Gerncia de Identidades Federadas A implementao deste servio utiliza como base o OpenAM. Na plataforma REALcloud cada componente do OpenAM (SP, IdP proxy e IdP) est instalado em uma VM. A utilizao de componentes deste servio em VMs oferece plataforma o aumento no tempo de disponibilidade do servio e tambm uma diminuio do tempo de instalao deste servio em outras nuvens. O estabelecimento do CoT da federao se d atravs da congurao de um perl (SP, IdP ou IdP proxy) em cada instncia do OpenAM. Para tal, foi necessrio a criao

de um metadado no padro SAMLv2. Alm de conter informaes sobre o perl, este metadado possui um certicado X.509 gerado em cada entidade. A Fig. 1.22(a) ilustra a troca de metadados realizada entre os componentes de IdM da nuvem e entre as nuvens privadas (b), respectivamente. No passo 1, gera-se os metadados do IdP proxy com o perl SP e IdP. No passo 2, o SP importa a parte IdP do metadado do IdP proxy. No passo 3, o IdP importa a parte SP do metadado do IdP proxy. No passo 4, o IdP proxy importa o metadado do SP. Finalmente, no passo 5 o IdP proxy importa o metadado do IdP. O IdP proxy atuar, sob o ponto de vista do SP, como um IdP e do ponto de vista de um IdP, como um SP. Isto foi importante para permitir a agregao de mltiplos IdPs (de domnios diferentes) para fazer parte da federao. Na Fig. 1.22(b), a troca de metadados ocorre entre duas nuvens privadas. No passo 1, no IdP proxy do domnio 1 importado o metadado do IdP do domnio 2. No passo 2, importado no IdP do domnio 2, a parte SP do IdP proxy do domnio 1. O mesmo processo (passos 3 e 4) realizado entre os componentes IdP e IdP proxy dos domnios 1 e 2, respectivamente.

(a)

(b)

Fig. 1.22. Troca de Metadados: (a) Dentro da Nuvem Privada, (b) entre Nuvens Privadas.

Uma parte importante da infraestrutura de gerncia de identidades federadas o agente. O agente atua como um PEP e a ltragem ocorre na requisio de um recurso hospedado. Na nuvem privada, foi instalado um agente no servidor Apache para proteger pginas de gerncia do laboratrio (reserva de horrio, cadastro de usurios, cadastro de experimentos, proviso de experimentos, etc.). Neste servidor Apache tambm est instalado o mdulo mod_proxy. Com isso a plataforma utiliza um modelo de implantao de SSO misto, que combina o uso de proxy reverso e um agente instalado neste servidor para ltrar as requisies a todos os recursos protegidos da plataforma. Servio de Gerncia de Acesso a Dispositivos O servio de Gerncia de Acesso a Dispositivos providos pela plataforma REALcloud foi implementado com a tecnologia J2EE (Java 2 Enterprise Edition), como provido pelo servidor de aplicao Tomcat. Para a persistncia dos dados foi utilizado o servidor de banco de dados MySQL.

Servio de Controle de Rede O servio de Controle de Rede foi implementado como um servlet que executa um shell script para interagir com as regras de rewall padro do Linux, oferecido pelo servio de Encaminhamento de Pacotes. O servio de Controle de Rede no prov servios no nvel de usurio, tendo como cliente o servio de Gerncia de Acesso a Dispositivos. Os servios da plataforma esto distribudos de acordo com a Fig. 1.23.
Nuvem Pblica Nuvem Privada 1 Servios Pblicos Servios para IdM VM SP 1 VM VM VM SPn Servios para IdM Nuvem Privada n

protegido
VM

protegido

IdP proxy

1 N A T / D N A T N A T / D N A T

IdP proxy

IdP1

IdPn

Pool de Recursos Gerncia REALcloud VM ... VM REALabs

Internet

Pool de Recursos Gerncia REALcloud VM VM ... VM REALabs

(PaaS) Recurso Robtico

(PaaS) Recurso Robtico

Fig. 1.23. Plataforma REALcloud.

As nuvens privadas 1 e N na Fig. 1.23 representam dois domnios privados que possuem recursos a serem compartilhados. O servio de Gerncia de VM, o servio de Gerncia de Acesso a Dispositivos e o servio de Controle de Rede esto distribudos como componentes da plataforma (Gerncia REALcloud). Os componentes de gerncia da plataforma REALcloud e os recursos tais como robs, cmeras panormicas, mquinas virtuais, a plataforma REALabs, entre outros, localizados no pool de recursos, so protegidos pelo componente SP do servio de gerncia de identidades federadas. A nuvem pblica oferece apenas servios pblicos, tais como: hospedagem de pginas, armazenagem de dados e aplicaes especcas. Cada servio est inserido em uma VM ou em VMs que agregam servios co-relacionados. A nuvem pblica pode estabelecer federaes entre as nuvens privadas ou entre um provedor de nuvem pblica (por exemplo, Amazon). Nesse caso, o servio de gerncia de identidades federadas deve ser instalado na nuvem pblica. Finalmente, cada nuvem est interconectada Internet. Para se traduzir endereos IP privados para pblicos e vice-versa, foi utilizado a funo de rede NAT/DNAT. Assim cada requisio originada atravs da Internet para o par IP:porta pblica de cada nuvem privada mapeado para o par IP:porta privada, onde os recursos existentes no pool esto conectados.

1.7. Consideraes Finais

A gerncia de identidades acompanha as novas necessidades colaborativas de uma Internet que est em constante evoluo. A integrao de aplicaes na Web com ambientes federados tem o objetivo de suprir as expectativas de uma Web de servios independentes, porm interoperveis. Apesar das vantagens quanto elasticidade na oferta de servios em nuvem, existem alguns desaos que ainda precisam ser superados. Dentre estes esto as questes legais quanto garantia de restries sobre o tipo de contedo armazenado, alm de garantias quanto ao nvel de acesso do provedor de servios aos dados hospedados em seus datacenters. Por outro lado, o acesso aos recursos do domnio deve ser gerenciado, para que apenas os usurios com contas no domnio, ou em domnios parceiros, tenham acesso a esses recursos. Alm disso, o provedor de servios de nuvem deve comportar o aumento do nmero de usurios, sem que isso reduza o desempenho das conexes individuais. Tambm, aplicativos empresariais que envolvem sistemas de intranet, ambientes colaborativos, redes sociais, aplicativos para celular, dentre outros, tambm podem se beneciar do uso da nuvem como porta de acesso para uma ampla gama de servios federados, ou seja, no exclusivos de uma nica nuvem. Nesse sentido, a gerncia de identidades federadas contribui para assegurar mecanismos conveis para a proviso de gerncia de mltiplas identidades. Em nossa experincia na utilizao de solues para implantao de IdM em nuvens vericamos que estas no esto totalmente adaptadas para tratar os desaos da computao em nuvem. A congurao desses sistemas requer um conhecimento prvio dos padres e, principalmente, da teoria que lhes d suporte, visto que a terminologia utilizada nestes sistemas baseada nos conceitos destes padres. O Shibboleth por ser o sistema precursor, carece de suporte aos padres emergentes, tais como OpenID e OAuth. A instalao deste sistema dispendiosa, visto que parte de seus componentes esto em Java e em C/C++. Outra questo que a instalao baseada em arquivos XML, o que diculta o entendimento para um iniciante na rea. J o OpenAM oferece todo o seu pacote de software encapsulado de um nico arquivo (.war), o que facilita a instalao. A congurao, por sua vez, tambm demanda um conhecimento prvio dos padres, principalmente na congurao de federaes, que requer um considervel esforo. No caso do Higgins, por adotar o paradigma centrado no usurio e ser um projeto ainda em desenvolvimento, existe pouca informao quanto a sua utilizao. A plataforma REALcloud um exemplo de soluo de cdigo aberto para a realizao de experimentos em rede. Como caractersticas desta soluo, citamos a capacidade de agregar nuvens privadas distintas com compartilhamento de recursos utilizando relaes de conana da federao e tambm a capacidade de integrar nuvens pblicas com a nalidade de aumentar a oferta de recursos computacionais para as demais nuvens privadas.

Referncias
[Agostinho et al. 2011] Agostinho, L., Olivi, L., Feliciano, G., Paolieri, F., Rodrigues, D., Guimares, E., and Cardozo, E. (2011). A Cloud Computing Environment for Supporting Networked Robotics Applications. The 3rd International Workshop on

Workow Management in Service and Cloud Computing. [Amazon 2010] Amazon (2010). Amazon Elastic Compute Cloud (Amazon EC2). Disponvel em: http://aws.amazon.com. Acessado em 10 de Setembro de 2011. [Anderson 2005] Anderson, A. (2005). A Comparison of Two Privacy Policy Languages: EPAL and XACML. Technical report. Disponvel em: http://labs.oracle.com/techrep/2005/smli_tr-2005147/TRCompareEPALandXACML.html. [Bertino and Takahashi 2011] Bertino, E. and Takahashi, K. (2011). Management: Concepts, Technologies, and Systems. Artech House. Identity

[Breitman and Viterbo 2010] Breitman, K. and Viterbo, H. (2010). Computao na Nuvem - Uma Viso Geral. Congresso Internacional Software Livre e Governo Eletrnico - Consegi, pages 1745. [Buyya et al. 2010] Buyya, R., Ranjan, R., and Calheiros, R. N. (2010). InterCloud: Utility-Oriented Federation of Cloud Computing Environments for Scaling of Application Services. In Proceedings of the 10th ICA3PP, pages 2123. Springer. [Cao and Yang 2010] Cao, Y. and Yang, L. (2010). A Survey of Identity Management Technology. IEEE International Conference on Information Theory and Information Security (ICITIS). [Cardozo et al. 2010] Cardozo, E., Guimares, E. G., Rocha, L. A., Souza, R. S., Paolieri, F., and Pinho, F. (2010). A platform for networked robotics. IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS 2010), Taipei, Taiwan. [Carissimi 2008] Carissimi, A. (2008). Virtualizao: da teoria a solues. In Mini-curso - SBRC 2008 - Rio de Janeiro - RJ. [Cloud Security Alliance 2009] Cloud Security Alliance (2009). Security Guidance for Critical Areas of Focus in Cloud Computing V2.1. Technical report. [Crupi and Warner 2008] Crupi, J. and Warner, C. (2008). Enterprise Mashups Part I: Bringing SOA to the People . SOA Magazine, (18). [Dike 2006] Dike, J. (2006). User-Mode Linux. Prentice Hall. [Eclipse Foundation 2011] Eclipse Foundation (2011). Higgins - Open Source Identity Framework. Disponvel em: http://www.eclipse.org/higgins. Acessado em 20 de Agosto de 2011. [El Maliki and Seigneur 2007] El Maliki, T. and Seigneur, J.-M. (2007). A Survey of User-centric Identity Management Technologies. In Proceedings of the The International Conference on Emerging Security Information, Systems, and Technologies, Washington, DC, USA.

[Endo et al. 2010] Endo, P. T., Gonalves, G. E., Kelner, J., and Sadok, D. (2010). A survey on open-source cloud computing solutions. XXVIII Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - VIII Workshop em Clouds, Grids e Aplicaes - Gramado - RS. [Feliciano et al. 2011] Feliciano, G., Agostinho, L., Guimares, E., and Cardozo, E. (2011). Uma Arquitetura para Gerncia de Identidades em Nuvens Hbridas. IX Workshop em Clouds, Grids e Aplicaes (WCGA 2011) - XXIX Simpsio Brasileiro de Redes de Computadores (SBRC - 2011) - Campo Grande - MS. [FlexiScale 2010] FlexiScale (2010). FlexiScale Public Cloud. Disponvel em: http://www.exiant.com/products/exiscale. Acessado em 2 de Agosto de 2011. [ForgeRock 2010] ForgeRock (2010). OpenAM. Disponvel http://www.forgerock.com/openam.html. Acessado em 9 de Agosto de 2011. em:

[Gomes and Kowalczyk 2011] Gomes, E. R.and Vo, Q. B. and Kowalczyk, R. (2011). Pure exchange markets for resource sharing in federated clouds. In Proceedings of Concurrency and Computation: Practice and Experience. [Gonalves et al. 2011] Gonalves, G. E., Endo, P. T., Cordeiro, T. D., and et al. (2011). Resource Allocation in Clouds: Concepts, Tools and Research Challenges. XXIX SBRC - Gramado - RS. [Google 2010] Google (2010). Google Apps. Disponvel http://www.google.com/apps. Acessado em 2 de Setembro de 2011. [Gopalakrishnan 2009] Gopalakrishnan, A. (2009). Management. SETLabs Briengs, 7(7). em:

Cloud Computing Identity

[Guimares et al. 2011] Guimares, E. G., Cardozo, E., Moraes, D. H., and Coelho, P. R. (2011). Design and Implementation Issues for Modern Remote Laboratories. IEEE Transactions on Learning Technologies, 4(1). [Hodges 2009] Hodges, J. (2009). Technical Comparison: OpenID and SAML - Draft 07a. Technical report. Disponvel em: http://identitymeme.org/doc/draft-hodges-samlopenid-compare.html. Acessado em 2 de Agosto de 2011. [Hmmerle 2011] Hmmerle, L. (2011). Enabling Interfederation Support for a Shibboleth Service Provider (SP) in SWITCHaai. Disponvel em: https://www.switch.ch/aai/docs/interfederation/sp-deployment.html. Acessado em 15 de Setembro de 2011. [IBM 2011] IBM (2011). New to SOA and Web Services. Disponvel em: http://www128.ibm.com/developerworks/webservices/newto/websvc.html. Acessado em 4 de Agosto de 2011. [IETF 2000] IETF (2000). Framework for Policy-based Admission Control IETF RFC 2753. Technical report. Disponvel em: http://www.ietf.org/rfc/rfc2753.txt. Acessado em 25 de Agosto de 2011.

[Internet2 2011] Internet2 (2011). Shibboleth - A Project of the Internet2 Middleware Initiative. Disponvel em: http://shibboleth.internet2.edu. Acessado em 15 de Setembro de 2011. [ISO/IEC 1996] ISO/IEC (1996). Information technology Open Systems Interconnection Security frameworks for open systems: Access control framework ISO/IEC 10181-3:1966. Technical report. [ITU-T 2009] ITU-T (2009). NGN Identity Management Framework. Recommendation Y.2720. Technical report. Disponvel em: http://www.itu.int/itut/recommendations/rec.aspx?id=9574. Acessado em 20 de Agosto de 2011. [Johansson 2009] Johansson, L. (2009). Its the F-Word. IETF Journal, 6(1). [Jnior et al. 2010] Jnior, A. M., Laureano, M., Santin, A., and Maziero, C. (2010). Aspectos de segurana e privacidade em ambientes de Computao em Nuvem. In Mini-curso - SBSeg 2010 - Fortaleza - CE. [Ma 2005] Ma, K. J. (2005). Professional, 7(2):1421. Web Services: Whats Real and Whats Not? IT

[Mell and Grace 2010] Mell, P. and Grace, T. (2010). NIST Working Denition of Cloud Computing. Technical report. Disponvel em: http://groups.google.com/group/cloudforum/web/nist-working-denition-of-cloudcomputing. Acessado em 15 de Setembro de 2011. [Menasc 2005] Menasc, D. A. (2005). Virtualization: Concepts, applications, and performance modeling. [Microsoft 2011] Microsoft (2011). CardSpace. Disponvel em: http://msdn.microsoft.com/en-us/library/aa480189.aspx. Acessado em 2 de Setembro de 2011. [Murari 2010] Murari, K. e. a. (2010). Eucalyptus Beginners Guide - UEC Edition Ubuntu 10.04 - Lucid. CSS Corp. [Nimbus 2011] Nimbus (2011). Nimbus - University of Chicago. Disponvel em: http://www.nimbusproject.org/. Acessado em 2 de Setembro de 2011. [Ning 2010] Ning (2010). Ning Inc. Disponvel em: www.ning.com. Acessado em 23 de Agosto de 2011. [OASIS 2005] OASIS (2005). eXtensible Access Control Markup Language (XACML) Version 2.0. Technical report. Disponvel em: http://docs.oasis-open.org/xacml/2.0. Acessado em 9 de Setembro de 2011. [OASIS 2006] OASIS (2006). UDDI 101. Disponvel em: http://uddi.xml.org/uddi-101. Acessado em 5 de Setembro de 2011.

[OASIS 2008] OASIS (2008). Security Assertion Markup Language (SAML) V2.0 Technical Overview. Technical report. Disponvel em: http://docs.oasisopen.org/security/saml/v2.0. Acessado em 17 de Agosto de 2011. [OASIS 2011] OASIS (2011). SPML. Disponvel em: http://www.oasisopen.org/committees/provision. Acessado em 9 de Setembro de 2011. [OAuth Community 2010] OAuth Community (2010). The OAuth 1.0 Protocol. Technical report. Disponvel em: http://tools.ietf.org/html/rfc5849. Acessado em 18 de Agosto de 2011. [OAuth Community 2011] OAuth Community (2011). The OAuth 1.0 Guide. Disponvel em: http://hueniverse.com/oauth/guide/intro/. Acessado em 2 de Agosto de 2011. [Olden 2011] Olden, E. (2011). Architecting a Cloud-Scale Identity Fabric. volume 44, pages 5259. Journal Computer - IEEE Computer Society. [Open Grid Forum 2009] Open Grid Forum (2009). Occi - open cloud computing interfaces. Disponvel em: http://occi-wg.org/. Acessado em 10 de Agosto de 2011. [OpenID Foundation 2011] OpenID Foundation (2011). OpenID. Disponvel em: http://openid.net/get-an-openid/what-is-openid/. Acessado em 2 de Setembro de 2011. [OpenNebula 2010] OpenNebula (2010). OpenNebula. http://opennebula.org. Acessado em 10 de Setembro de 2011. Disponvel em:

[OpenVZ 2010] OpenVZ (2010). OpenVZ Wiki. Disponvel em: http://wiki.openvz.org. Acessado em 10 de Agosto de 2011. [Oracle 2010] Oracle (2010). Virtualbox. Disponvel em: http://www.virtualbox.org. Acessado em 10 de Agosto de 2011. [Ping Identity 2010a] Ping Identity (2010a). About Identity Federation and SSO. Disponvel em: http://pingidentity.com. Acessado em 20 de Setembro de 2011. [Ping Identity 2010b] Ping Identity (2010b). OpenID Tutorial. Disponvel em: https://www.pingidentity.com/resource-center/openid.cfm. Acessado em 20 de Setembro de 2011. [Rackspace 2010] Rackspace (2010). Openstack cloud software. www.openstack.org. Acessado em 10 de Setembro de 2011. Disponvel em:

[RNP 2011] RNP (2011). CAFe - Comunidade Acadmica Federada. Disponvel em: http://www.rnp.br/servicos/cafe.html. Acessado em 15 de Setembro de 2011. [Salesforce 2010] Salesforce (2010). Disponvel em: http://salesforce.com. Acessado em 2 de Setembro de 2011. [Scavo and Cantor 2005] Scavo, T. and Cantor, S. (2005). Technical report. Disponvel em: http://shibboleth.internet2.edu/docs/draft-mace-shibboleth-tech-overviewlatest.pdf. Acessado em 13 de Agosto de 2011.

[Shelly and Frydenberg 2010] Shelly, G. B. and Frydenberg, M. (2010). Concepts and Applications. Course Technology.

Web 2.0:

[Stallings 2011] Stallings, W. (2011). Cryptography and Network Security: Principles and Practice. Pearson Education. [Stoller 2011] Stoller, S. D. (2011). XACML. Disponvel em: http://www.cs.sunysb.edu/ stoller/cse608/6-XACML.pdf. Acessado em 14 de Agosto de 2011. [Suess and Morooney 2009] Suess, J. and Morooney, K. (2009). Identity Management and Trust Services: Foundations for Cloud Computing. Technical report. Disponvel em: http://www.educause.edu/node/178404. Acessado em 10 de Setembro de 2011. [Switch 2011] Switch (2011). SWITCH - Serving Swiss Universities. Disponvel em: http://www.switch.ch. Acessado em 2 de Setembro de 2011. [Thangasamy 2011] Thangasamy, I. (2011). OpenAM. Packt Publishing. [Twitter 2011] Twitter (2011). Using OAuth 1.0a. Disponvel https://dev.twitter.com/docs/auth/oauth. Acessado em 20 de Setembro de 2011. em:

[Veras 2009] Veras, M. (2009). Datacenter:Componente Central da Infraestrutura de TI. [Verdi et al. 2010] Verdi, F., Rothenberg, C. E., Pasquini, R., and Magalhes, M. F. (2010). Novas Arquiteturas de Data Center para Cloud Computing. XXVIII Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - Gramado - RS. [VMware Inc. 2011] VMware Inc. (2011). VMware. http://www.vmware.com. Acessado em 22 de Agosto de 2011. Disponvel em:

[Wangham et al. 2010] Wangham, M. S., de Mello, E. R., da Silva Bger, D., Gueiros, M., and da Silva Fraga, J. (2010). Gerenciamento de Identidades Federadas. In Minicurso - SBSeg 2010 - Fortaleza - CE. [Warnke and Ritzau 2010] Warnke, R. and Ritzau, T. (2010). qemu-kvm & libvirt. Books on Demand GmbH. [Windley 2005] Windley, P. (2005). Digital Identity. OReilly. [Windows Azure 2010] Windows Azure (2010). Windows Azure Platform. Disponvel em: http://www.microsoft.com/windowsazure. Acessado em 2 de Setembro de 2011. [Xen 2010] Xen (2010). Xenserver. Disponvel em: http://www.citrix.com. Acessado em 10 de Setembro de 2011. [Zappert 2010] Zappert, F. e. a. (2010). Cloud Computing Use Cases White Paper Version 4.0. Technical report.