Uma infraestrutura para laboratórios de acesso remoto federados com suporte à virtualização

(1)

Guilherme de Oliveira Feliciano

Uma Infraestrutura para Laborat´

orios de Acesso

Remoto Federados com Suporte `

a Virtualiza¸c˜

ao

Campinas 2013

(2)

(3)

Universidade Estadual de Campinas

Faculdade de Engenharia El´

etrica e de Computa¸

c˜

ao

Guilherme de Oliveira Feliciano

Uma Infraestrutura para Laboratórios de Acesso Remoto Federados com Suporte à Virtualiza¸cão

Disserta¸cão de Mestrado apresentada ao Programa de Pós-Gradua¸cão em Engenharia Elétrica da Facul-dade de Engenharia Elétrica e de Computa¸cão da Universidade Estadual de Campinas para obten¸cão do t´ıtulo de Mestre em Engenharia Elétrica. Área de concentra¸cão: Engenharia de Computa¸cão.

Orientador: Prof. Dr. Eleri Cardozo

Este exemplar corresponde à versão final da disserta¸cão defendida pelo aluno Guilherme de Oliveira Feliciano, e orientada pelo Prof. Dr. Eleri Cardozo.

Campinas 2013

(4)

Biblioteca da Área de Engenharia e Arquitetura Rose Meire da Silva - CRB 8/5974

Feliciano, Guilherme de Oliveira,

F334i FelUma infraestrutura para laboratórios de acesso remoto federados com suporte à virtualização / Guilherme de Oliveira Feliciano. – Campinas, SP : [s.n.], 2013.

FelOrientador: Eleri Cardozo.

FelDissertação (mestrado) – Universidade Estadual de Campinas, Faculdade de Engenharia Elétrica e de Computação.

Fel1. Redes de computadores. 2. Sistemas de segurança. 3. Virtualização. 4. Ensino a distância. 5. Robótica. I. Cardozo, Eleri,1954-. II. Universidade Estadual de Campinas. Faculdade de Engenharia Elétrica e de Computação. III. Título.

Informações para Biblioteca Digital

Título em outro idioma: An infraestructure for federated remote access laboratories with virtualization support Palavras-chave em inglês: Computer networks Security systems Virtualization Distance education Robotics

Área de concentração: Engenharia de Computação Titulação: Mestre em Engenharia Elétrica

Banca examinadora: Eleri Cardozo [Orientador] Fábio Luciano Verdi

Marco Aurélio Amaral Henriques Data de defesa: 12-08-2013

Programa de Pós-Graduação: Engenharia Elétrica

(5)

(6)

(7)

Dedico este trabalho à minha avó Rosária e in momemorian de Júlio Feliciano e Silvio de Oliveira. Pessoas que sempre levaram alegria ao próximo.

(8)

(9)

Agradecimentos

Meus sinceros agradecimentos,

`a Deus, por me dar for¸cas nos momentos mais dif´ıceis.

ao meu orientador, Prof. Dr. Eleri Cardozo, sou grato pela oportunidade de realizar este mes-trado, pela confian¸ca, pela s´abia orienta¸c˜ao e aprendizado.

à Dra. Eliane Gomes Guimarães, pelas contribui¸cões dadas aos artigos e minicursos publicados. à toda minha fam´ılia pelo apoio durante esta jornada.

`a Michelle Gardini, pelo seu amor e carinho.

aos amigos do grupo de Robótica: Eric Rohmer, Fernando Pinho, Ricardo Souza, Diego Ro-drigues, Fábio Teixeira e Luisa Uribe, pelas valiosas sugestões a este trabalho e momentos de descontra¸cão. Agrade¸co também ao Leonardo Olivi, Lucio Rocha e Fernando Paolieri, por con-tribui¸cões nos resultados deste trabalho. Todos vocês contribu´ıram, e muito, para este trabalho. ao Moisés Danziger, pelas conversas sobre seguran¸ca.

à todos amigos do LCA, obrigado por toda sugestão, cr´ıticas, elogios e pelos momentos de des-contra¸cão.

aos professores da PUC-Campinas e Colégio Policursos por transmitir seus conhecimentos em computa¸cão. Em especial, agrade¸co ao Prof. Eduardo Nicola F. Zagari pelas orienta¸cões. à CAPES, pelo apoio financeiro.

(10)

(11)

“A maravilhosa disposi¸c˜ao e harmonia do universo s´o pode ter tido origem segundo o plano de um Ser que tudo sabe e tudo pode. Isto fica sendo a minha ´

ultima e mais elevada descoberta.”

(Isaac Newton)

(12)

(13)

Resumo

A Internet é hoje um importante ambiente de colabora¸cão e aprendizado. Os la-boratórios de acesso remoto (ou WebLabs) são um exemplo de tecnologia voltada para esta realidade. Com os WebLabs é poss´ıvel oferecer o acesso a um dispositivo real através de uma rede, usualmente a Internet, e permitir que este seja acessado e controlado remotamente. Este modelo de experimenta¸cão, porém, inviabiliza a execu¸cão remota de certos tipos de experimentos, por exemplo, aqueles sens´ıveis a atrasos de comunica¸cão. Este trabalho apresenta uma proposta de infraestrutura para WebLabs federados capazes de suportar experimentos com requisitos estritos de rede tais como alta taxa de comunica¸cão, baixo atraso e jitter. A proposta faz uso de padrões e tecnologias abertos nos diversos componentes do sistema, tais como autentica¸cão federada e autoriza¸cão baseada em pol´ıticas. A proposta também uti-liza virtuauti-liza¸cão para que os experimentos com requisitos estritos de rede sejam executados com seguran¸ca em servidores mantidos pelo WebLab e conectados na mesma sub-rede dos recursos. Como contribui¸cão, foi desenvolvida uma interface de programa¸cão (API) que integra e abstrai as particularidades das tecnologias ado-tadas e oferece métodos para a cria¸cão de pol´ıticas, realiza¸cão de experimentos e controle de VMs. Para a valida¸cão da proposta, utiliza-se um experimento na área de robótica móvel e compara-se o seu desempenho quando executado em diversos cenários de rede, incluindo o cenário de virtualiza¸cão oferecido pela infraestrutura proposta.

Palavras-chave: WebLabs, Virtualiza¸cão, Gerência de Identidades Federadas, Pol´ı-ticas de Autoriza¸cão, Experimenta¸cões em Robótica.

(14)

(15)

Abstract

The Internet is nowadays an important environment for collaboration and learning. The remote access laboratories (or WebLabs) are an example of such technology for this reality. WebLabs can provide access to real devices through a network, usually the Internet, and allow the devices to be accessed and controlled remotely. This experimentation model, however, preclude the remote execution of certain types of experiments, for example, those sensitive to communication delays. This work pre-sents a proposal for an infrastructure for federated WebLabs capable of supporting experiments with stringent network requirements such as high communication rate and low delay and jitter. The proposed infrastructure uses open standards and tech-nologies in different system components, such as federated authentication and policy based authorization. The infrastructure also employs virtualization to run experi-ments with strict network requireexperi-ments safely on servers maintained by WebLab and connected to the same subnet connecting the resources. As a contribution, we developed an application programming interface (API) that integrates and abstracts the particularities of adopted technologies and provides methods for policy creation, experiments execution, and control of virtual machines. To validate the proposal, we evaluate an experiment in the mobile robotics area and compare its performance when executed in several network scenarios, including the virtualization scenario offered by the proposed infrastructure.

Key-words: WebLabs, Virtualization, Federated Identity Management, Authoriza-tion Policies, Robotic Experiments.

(16)

(17)

Lista de Figuras

1 Modelo de Experimenta¸c˜ao Remota que Utiliza a Internet. . . 2

1.1 Arquitetura B´asica de um WebLab. . . 7

1.2 Arquitetura do iLabs para Experimentos Interativos. Baseado em (HARWARD et al., 2008). . . 9

1.3 Vis˜ao Geral do Mecanismo de Controle de Acesso Intradom´ınio do iLab. Baseado em (NORTHRIDGE et al., 2010). . . 10

1.4 Vis˜ao Geral do Mecanismo de Controle de Acesso Interdom´ınio do iLab. Adap-tado de (MAO, 2007) . . . 12

1.5 Vis˜ao Geral da Arquitetura do WebLab-Deusto 4.0.1. Baseado em (ORDU ˜NA et al., 2011). . . 14

1.6 Vis˜ao Geral da Arquitetura do REALabs (GUIMAR ˜AES et al., 2011). . . 17

2.1 Virtualiza¸c˜ao Completa. Baseado em (JONES, 2006). . . 23

2.2 Paravirtualiza¸c˜ao. Baseado em (JONES, 2006). . . 23

2.3 Virtualiza¸c˜ao no N´ıvel do SO. Baseado em (JONES, 2006). . . 24

2.4 Suporte de Hardware para Virtualiza¸c˜ao. Baseado em (CARISSIMI, 2008). . . . 25

2.5 Virtualiza¸c˜ao com o KVM. Baseado em (JONES, 2006). . . 25

2.6 Rela¸c˜ao entre os Componentes da Identidade (FELICIANO et al., 2011b). . . . 27

2.7 Ciclo de Vida da Identidade (FELICIANO et al., 2011b). . . 28

2.8 Modelos para a IdM. Baseado em (WANGHAM et al., 2010) . . . 31

2.9 Processo de SSO que Utiliza Abordagem Baseada em Broker (FELICIANO et al., 2011b). . . 32

2.10 Processo de SSO que Utiliza Abordagem Baseada em Agente (FELICIANO et al., 2011b). . . 33

2.11 Processo de SSO que Utiliza Abordagem Baseada em Proxy Reverso (FELICI-ANO et al., 2011b). . . 33

2.12 Processo de SSO que Utiliza Abordagem Baseada em API (FELICIANO et al., 2011b). . . 34

2.13 Processo de SSO que Utiliza Abordagem Baseada em Servi¸cos (FELICIANO et al., 2011b). . . 34

2.14 Estrutura do SAML. Baseado em (BERTINO; TAKAHASHI, 2011). . . 35 xvii

(18)

TOR, 2005) . . . 40

2.17 Arquitetura Simplificada do OpenAM (FELICIANO et al., 2011b). . . 42

2.18 Implanta¸c˜ao b´asica do OpenAM (FELICIANO et al., 2011b). . . 42

3.1 Vis˜ao Geral dos Casos de Uso do Sistema. . . 46

3.2 Modelo de Referˆencia para WebLabs Federados (GUIMAR ˜AES et al., 2011). . . 49

3.3 Extens˜ao do Modelo de Referˆencia para WebLabs Federados. . . 51

3.4 Vis˜ao Geral do Fluxo de Informa¸c˜ao no Caso de Uso Realizar Experimento. . . . 52

3.5 Servi¸cos de Gerˆencia Oferecidos pela Infraestrutura. . . 53

4.1 Troca de Metadados: (a) Dentro do Dom´ınio, (b) entre Dom´ınios. . . 63

4.2 Padr˜ao de Projeto Facade Aplicado no Desenvolvimento do Servi¸co de Pol´ıticas da Infraestrutura. . . 66

4.3 Vis˜ao Geral da Distribui¸c˜ao dos Componentes da Infraestrutura. . . 68

5.1 Robˆo, Mapa e a Trajet´oria a ser Percorrida. . . 76

5.2 Cen´ario de Rede Local e a Execu¸c˜ao do Experimento. . . 77

5.3 Cen´ario de Internet e de Rede de Campus e a Execu¸c˜ao do Experimento. . . 77

5.4 Cen´ario Utilizando uma VM e a Execu¸c˜ao do Experimento. . . 78

(19)

Lista de Quadros

2.1 Exemplo de Documento XACML para Descrever uma Pol´ıtica. Baseado em (STOL-LER, 2011). . . 38 4.1 Regra Utilizada no Iptables para Liberar Acesso ao Robˆo . . . 65 4.2 Regra Utilizada no Iptables para Formatar o NAT e FORWARD . . . 65

(20)

(21)

Lista de Tabelas

1.1 Resumo dos Trabalhos Correlatos Avaliados. . . 19 5.1 Desempenho e Erro Médio do FastSLAM no Cenário de Rede Local. . . 79 5.2 Desempenho e Erro Médio do FastSLAM no Cenário de Internet. . . 79 5.3 Desempenho e Erro Médio do FastSLAM no Cenário de Rede do Campus. . . . 80 5.4 Desempenho e Erro Médio do FastSLAM no Cenário de VM com 1 Núcleo, 2 Gb

de RAM e Interface RTL8139. . . 81 5.5 Desempenho e Erro Médio do FastSLAM no Cenário de VM com 4 Núcleos, 6

Gb de RAM e Interface Virtio. . . 82 5.6 Ranking do Desempenho (M´edia de It./s). . . 82 5.7 Ranking do Erro M´edio. . . 83

(22)

(23)

Lista de Acrˆ

onimos e Nota¸c˜

ao

AJAX Asynchronous JavaScript and XML API Application Programming Interface

ARIA Advanced Robot Interface for Applications BPEL Business Process Execution Language CA Certificate Authority

CAFe Comunidade Acadˆemica Federada CAS Central Authentication Service CLI Command Line Interface

CORBA Common Object Request Broker Architecture CoT Circles of Trust

CPLD Complex Programmable Logic Device CTI Centro de Tecnologia da Informa¸c˜ao DAUI Distributed Authentication User Interface DMA Direct Memory Access

DMZ DeMilitarized Zone DoS Denial of Service

DRDB Distributed Replicated Block Device E/S Entrada e Sa´ıda

ESS Experiment Storage Service FCFS First-Come, First-Served

(24)

HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol IdM Identity Management

IdP Identity Provider

IEC International Electrotechnical Commission IETF Internet Engineering Task Force

IP Internet Protocol

IPA Internet Privatstiftung Austria ISA iLab Shared Architecture ISB Interactive Service Broker

ISO International Organization for Standardization ITU-T International Telecommunication Union J2EE Java2 Platform Enterprise Edition JSP Java Server Pages

KVM Kernel-based Virtual Machine LC Lab Client

LDAP Lightweight Directory Access Protocol LMS Learning Management System

LS Lab Server

LSS Lab-Side Schedulling Service LVM Logical Volume Manager

MIT Massachusetts Institute of Technology MMU Memory Management Unit

NTP Network Time Protocol PC Personal Computer PDP Policy Decision Point

(25)

PEP Policy Enforcement Point PKI Public Key Infraestructure QEMU Quick EMUlator

QoS Quality of Service

RDP Remote Desktop Protocol REAL Remote Accessible Laboratory REST REpresentational State Transfer ROS Robot Operation System

RPC Remote Procedure Call SaaS Software as a Service

SAML Security Assertions Markup Language SAN Storage Area Network

SLA Service Level Agreement

SLAM Simultaneous Localization and Mapping SO Sistema Operacional

SOA Service Oriented Architecture SOAP Simple Object Access Protocol SP Service Provider

SPI Service Provider Interface SS Schedulling Service

SSH Secure SHell

SSL Secure Sockets Layer SSO Single Sign-On

TIC Tecnologia da Informa¸c˜ao e Comunica¸c˜ao UML Unified Modeling Language

UML User Mode Linux

URL Uniform Resource Locator

(26)

VM Virtual Machine

VMM Virtual Machine Monitor VNC Virtual Network Computing VPN Virtual Private Network

XACML eXtensible Access Control Markup Language XML eXtensible Markup Language

(27)

Trabalhos Publicados Pelo Autor

1. FELICIANO, G. O.; ROCHA, L. A.; OLIVI, L. R.; GUIMAR ÃES, E. G.; CARDOZO, E. “Uma Arquitetura para Gerência de Identidades em Nuvens H´ıbridas”. IX Workshop em Clouds, Grids e Aplica¸cões (WCGA 2011) - XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribu´ıdos - Campo Grande - MS, 2011. p. 15-28.

2. ROCHA, L. A.; OLIVI, L.; PAOLIERI F.; FELICIANO, G. O.; SOUZA, R. S.; PINHO, F.; TEIXEIRA F.; RODRIGUES D.; GUIMAR ˜AES, E.; CARDOZO, E. “Computer Com-munications and Networks - Advances in Educational Robotics in Cloud with Qualitative Scheduling in WorkFlows”, London: Springer, 2011. cap. 7, p. 135-157.

3. FELICIANO, G. O.; ROCHA, L. A.; GUIMAR ÃES, E. G.; CARDOZO, E. Gerência de Identidades Federadas em Nuvens: Enfoque na Utiliza¸cão de Solu¸cões Abertas. In: Minicursos do XI Simpósio Brasileiro de Seguran¸ca da Informa¸cão e de Sistemas Compu-tacionais (SBSeg 2011), Bras´ılia - DF. Porto Alegre: Sociedade Brasileira de Computa¸cão - SBC, 2011. cap. 5, p. 187-236.

4. ROCHA, L. A.; FELICIANO, G. O.; OLIVI, L. R.; CARDOZO, E. “A Bio-inspired Appro-ach to Provisioning of Virtual Resources in Federated Clouds”. IEEE Ninth International Conference on Dependable, Autonomic and Secure Computing (DASC 2011), Sydney -NSW, Austr´alia, 2011. p. 598-604.

5. ROCHA, L. A.; OLIVI, L. R.; FELICIANO, G. O.; PAOLIERI F.; RODRIGUES D.; CARDOZO, E. “A Cloud Computing Environment for Supporting Networked Robotics Applications”. IEEE Ninth International Conference on Dependable, Autonomic and Se-cure Computing (DASC 2011), Sydney - NSW, Austr´alia, 2011. p. 1110-1116.

(28)

(29)

Sum´

ario

Introdu¸cão 1 Motiva¸cões . . . 1 Objetivos e Justificativa . . . 3 Contribui¸cões . . . 4 Estrutura da Disserta¸cão . . . 5 1 Trabalhos Correlatos 7 1.1 Introdu¸cão . . . 7 1.1.1 iLab 4.0.1 . . . 8 1.1.2 WebLab-Deusto 4.0 . . . 13 1.1.3 REALabs . . . 16 1.2 Considera¸cões Finais . . . 19

2 Conceitos e Tecnologias Relevantes 21

2.1 Visão Geral sobre Virtualiza¸cão . . . 21 2.1.1 Técnicas de Virtualiza¸cão . . . 22 2.1.2 Tecnologias Adotadas . . . 24 2.2 Conceitos e Técnicas sobre IdM . . . 26 2.2.1 Identidade . . . 27 2.2.2 Autentica¸cão e Autoriza¸cão . . . 29 2.2.3 Modelos para IdM . . . 29 2.2.4 Op¸cões para Implanta¸cão de SSO . . . 31 2.3 Padrões e Solu¸cões em IdM Pesquisados . . . 34 2.3.1 SAML . . . 35 2.3.2 XACML . . . 37 2.3.3 Shibboleth . . . 39 2.3.4 OpenAM . . . 41 2.4 Considera¸cões Finais . . . 43 3 Projeto da Infraestrutura 45

3.1 Requisitos para um WebLab Federado . . . 45 xxix

(30)

3.1.3 Requisitos Não Funcionais . . . 47 3.2 Modelo de Dom´ınio para um WebLab Federado . . . 49 3.3 Visão Geral da Arquitetura . . . 53 3.3.1 Usuários e Grupos . . . 53 3.3.2 Recursos e Experimentos . . . 53 3.3.3 Sessão de Acesso . . . 54 3.3.4 Federa¸cão . . . 54 3.3.5 Pol´ıticas . . . 54 3.3.6 Sessão de Intera¸cão . . . 56 3.4 Considera¸cões Finais . . . 57 4 Implementa¸cão da Infraestrutura 59 4.1 Servi¸cos de Gerência . . . 59 4.1.1 Usuários e Grupos . . . 60 4.1.2 Recursos e Experimentos . . . 60 4.1.3 Sessão de Acesso . . . 61 4.1.4 Federa¸cão . . . 61 4.1.5 Pol´ıticas . . . 63 4.1.6 Sessão de Intera¸cão . . . 65 4.2 Visão Geral da API . . . 66 4.3 Distribui¸cão da Infraestrutura . . . 67 4.4 Considera¸cões sobre Seguran¸ca - Amea¸cas e Contramedidas . . . 69 4.4.1 Uso do SAML . . . 69 4.4.2 Uso do OpenAM . . . 72 4.5 Considera¸cões Finais . . . 74 5 Estudo de Caso 75 5.1 Introdu¸cão . . . 75 5.2 Avalia¸cão . . . 76 5.3 Resultados e Discussão . . . 78 5.4 Considera¸cões Finais . . . 82 6 Conclusão 85 6.1 Considera¸cões Finais . . . 85 6.2 Trabalhos Futuros . . . 86

Referˆencias Bibliogr´aficas 90

(31)

Introdu¸c˜

ao

Este cap´ıtulo apresenta e discute os principais problemas associados à realiza¸cão de ex-perimentos em laboratórios de acesso remoto. Uma instância do problema é apresentado no âmbito da robótica móvel. Neste cap´ıtulo apresenta-se também os objetivos do trabalho, as contribui¸cões, os trabalhos correlatos e, por fim, a organiza¸cão do texto.

Motiva¸c˜

oes

A Internet é hoje um importante ambiente de colabora¸cão e aprendizado. Diversas tecno-logias baseadas na Internet são desenvolvidas para esta finalidade. Os laboratórios de acesso remoto (ou WebLabs) são um exemplo de tecnologia voltada para esta realidade. Ao longo de anos esta tecnologia desempenha papel importante no ensino de ciências exatas, mais es-pecificamente nas áreas de engenharia. Com os WebLabs é poss´ıvel oferecer o acesso a um dispositivo real através de uma rede, usualmente a Internet, e permitir que este seja controlado remotamente.

Este modelo de experimenta¸cão remota complementa o modelo de experimenta¸cão tradicio-nal (presencial), pois permite um melhor compartilhamento do uso de equipamentos, simplifica a log´ıstica e os requisitos envolvidos na opera¸cão de um laboratório convencional (tais como espa¸co, pessoal e seguran¸ca), principalmente quando a experimenta¸cão envolve equipamentos de alto custo de aquisi¸cão. Do ponto de vista dos usuários (alunos), um WebLab oferece a comodidade de realizar um experimento a qualquer hora do dia e a partir de qualquer lugar.

No modelo de experimenta¸cão remota, a Internet é utilizada por diversas implementa¸cões de WebLabs como meio de acesso para prover o servi¸co, pois ela é uma rede pública, de longo alcance e de baixo custo. A Fig. 1 apresenta este modelo, onde uma aplica¸cão, executando na máquina cliente, possui uma lógica para enviar comandos a um recurso f´ısico, que por sua vez possui um servidor HTTP (Hypertext Transfer Protocol ) embarcado para receber os comandos e traduz´ı-los em comandos nativos ao recurso. Um servidor proxy HTTP intermedia a comunica¸cão para proteger o recurso f´ısico. Este modelo de experimenta¸cão, porém, está sujeito às deficiências caracter´ısticas da Internet (atraso e varia¸cão do atraso - jitter ), devido à sua pol´ıtica de roteamento de melhor esfor¸co e não garantia de QoS (Quality of Service). Estas caracter´ısticas inviabilizam a execu¸cão de certos tipos de experimentos e por isso limitam o escopo de experimentos poss´ıveis de serem realizados.

(32)

Fig. 1: Modelo de Experimenta¸c˜ao Remota que Utiliza a Internet.

A opera¸cão de alguns equipamentos cient´ıficos, tais como robôs, telescópios e plantas piloto, possuem requisitos estritos de comunica¸cão e processamento. Na área de robótica móvel, por exemplo, o controle e opera¸cão de um robô móvel envolve a transferência de grandes quantidades de dados, devido ao emprego de câmeras e lasers, necessitando então que o operador esteja conectado a uma rede de alta velocidade e com um computador com grande capacidade de processamento. Assim, estes requisitos não podem ser atendidos satisfatoriamente através de um modelo de experimenta¸cão remota baseado na Internet (CARDOZO et al., 2010).

Outra limita¸cão imposta pela Internet é com rela¸cão ao uso do protocolo HTTP. Como nor-malmente este é capaz de atravessar firewalls, as arquiteturas de WebLabs comumente utilizam este protocolo. Como exemplo, pode-se citar solu¸cões de WebLabs baseadas em arquitetura SOA (Service Oriented Architecture) (GUIMAR ÃES et al., 2011) e servi¸cos Web (HARWARD et al., 2008). Desta forma, softwares para controle de recursos f´ısicos que utilizam protocolos diferentes do HTTP tem seu emprego limitado nos WebLabs. Do ponto de vista educacional seria interessante para o usuário ter contato também com estes softwares para realiza¸cão de experimentos, uma vez que estes geralmente permitem explorar todas as facilidades existentes em um recurso f´ısico.

Com o advento da computa¸cão em nuvem (MELL; GRANCE, 2010) (ZAPPERT, F. et al., 2010) e o surgimento de diversas tecnologias para virtualiza¸cão de computadores com arquitetura PC (Personal Computer ), observa-se que a aplica¸cão de conceitos e tecnologias de virtualiza¸cão no contexto de WebLabs trazem vantagens significativas. Tradicionalmente, com a virtualiza¸cão é poss´ıvel oferecer um ambiente isolado entre máquinas virtuais, sendo que cada uma pode executar diferentes sistemas operacionais (SOs), com seus próprios processos (softwares). Cada máquina virtual, também, possui uma quantidade de recursos dedicados da máquina f´ısica e, à medida que são necessários mais ou menos recursos, é poss´ıvel alocá-los de maneira elástica, ou seja, sob-demanda (MENASCÉ, 2005).

No contexto de WebLabs, a primeira vantagem é que a execu¸cão de um experimento pode ser realizada em uma máquina virtual ou VM (Virtual Machine), localizada na mesma rede local do recurso controlado, permitindo assim um modelo de experimenta¸cão mais adequado, pois agora utiliza-se uma rede controlada, sem as deficiências da Internet (FELICIANO et al.,

(33)

Introdu¸c˜ao 3

2011a) (FELICIANO et al., 2011b). Isto é um fator importante, pois agrega pontos positivos oferecidos por uma rede local e mantém a caracter´ıstica de acesso universal oferecido pela Internet. Assim, do ponto de vista do laboratório, o usuário está na mesma rede local do recurso e do ponto de vista do usuário ele ainda acessa o recurso a partir da Internet, como nas outras abordagens de WebLabs.

A segunda vantagem é a possibilidade de alocar recursos do servidor f´ısico (por exemplo, processador e memória) para a VM do usuário, dependendo dos requisitos de processamento e memória requeridos em cada experimento. Isto retira do lado do usuário (lado cliente) a necessidade de possuir um computador com grande poder de processamento e com isso amplia os tipos de experimentos poss´ıveis de serem realizados. É importante ressaltar que esta abordagem é diferente da utilizada por outros WebLabs, que deixam para o lado cliente a responsabilidade de dimensionar a máquina para executar o experimento.

Na robótica em geral, é comum o fabricante de um determinado equipamento, por exemplo um robô móvel, oferecer pacotes de software para o controle e opera¸cão deste robô. Estes softwares apresentam vantagens, pois permitem explorar todas as facilidades existentes no robô em questão. Um exemplo é o ARIA (Advanced Robot Interface for Applications) (Mobile Robots Inc., 2005), uma API (Application Programming Interface) em C++ para o controle de toda a linha de robôs da empresa Mobile Robots. No mundo de software livre, há também softwares para o controle de recursos robóticos. Como exemplo tem-se o Player (The Player Project, 2001), uma plataforma cliente-servidor para o controle do hardware de um robô e o ROS (Robot Operation System) (Willow Garage Inc., 2007), um framework com funcionalidades ao estilo de um sistema operacional ou SO (abstra¸cão de hardware, drivers de dispositivos, interface de linha de comandos, etc.) para o controle e opera¸cão de recursos robóticos. Estes pacotes, porém, não empregam o HTTP na comunica¸cão com os recursos. Esta é a terceira vantagem no uso da virtualiza¸cão em ambientes de WebLabs, pois com o seu uso é poss´ıvel oferecer um acesso remoto a uma VM e, a partir desta, aos robôs, utilizando pacotes de software que empregam outros protocolos de camada de aplica¸cão na comunica¸cão.

Ressalta-se que o uso de uma máquina f´ısica para prover acesso e realiza¸cão de experimentos em um primeiro momento pode parecer fact´ıvel. Porém, em muitas situa¸cões, o usuário deve ter privilégio de super-usuário para executar determinadas aplica¸cões (por exemplo, aplica¸cões que utilizam threads ou processos com prioridade estática). Com tal privilégio, usuários podem executar a¸cões indesejáveis como instala¸cão e configura¸cão de sistemas de software, atualiza-¸cão do sistema operacional e acesso a arquivos de outros usuários, ou ainda a¸cões maliciosas, intencionais ou não. A administra¸cão de contas de usuários, por demandar suporte de pessoal especializado, é outro fator que dificulta a utiliza¸cão de máquinas f´ısicas em WebLabs.

Objetivos e Justificativa

Este trabalho possui três objetivos. O primeiro objetivo é oferecer uma infraestrutura para WebLabs federados, que permitam a realiza¸cão de experimentos através da Internet e que de-mandam como requisitos de rede o baixo atraso e o baixo jitter. Para tal, a infraestrutura oferece ao usuário uma VM conectada na mesma rede do recurso para minimizar o atraso e o

(34)

jitter, parâmetros que prejudicam uma experimenta¸cão realizada diretamente sobre a Internet. Com esta abordagem, a minimiza¸cão do atraso e jitter ocorre pela elimina¸cão da comunica¸cão via Internet no controle dos recursos. Ao invés disso, o controle é executado a partir de uma rede local próxima do recurso. O tráfego pela Internet ocorre apenas na intera¸cão com a VM, cuja tela é exibida remotamente na máquina do usuário. Com esta infraestrutura, também será poss´ıvel oferecer suporte a aplica¸cões que não utilizam o protocolo HTTP e, assim, ampliar a gama de experimentos poss´ıveis de serem realizados.

O desenvolvimento desta infraestrutura apresenta um desafio adicional relacionado à segu-ran¸ca deste ambiente, mais especificamente no controle de acesso (autentica¸cão e autoriza¸cão). A autentica¸cão nestes ambientes deve ser federada, uma vez que há a demanda por compar-tilhamento de recursos existentes em laboratórios localizados em dom´ınios distintos. Através do estabelecimento de uma federa¸cão é poss´ıvel aos laboratórios utilizarem um mecanismo de confian¸ca para acesso compartilhado a estes recursos e o SSO (Single Sign-On) é uma opera¸cão importante, pois permite a um usuário realizar apenas um processo de autentica¸cão e, com isso, ser identificado em qualquer dom´ınio da federa¸cão. Assim, o segundo objetivo é desenvol-ver um modelo de seguran¸ca que realize a gerência das identidades federadas ou IdM (Identity Management) federadas no acesso aos recursos destes laboratórios parceiros.

Com rela¸cão à autoriza¸cão, em WebLabs, a utiliza¸cão de um determinado recurso geralmente envolve uma etapa de pré-agendamento, onde é informado o dia, a hora e a dura¸cão pretendida de uso. Com base nestas informa¸cões, o sistema de autoriza¸cão verificará, em uma tentativa de acesso, se o usuário possui uma reserva para o recurso. O problema nesta abordagem, e utilizado em alguns WebLabs, refere-se ao modelo ser baseado apenas no uso mediante reserva. Este modelo não é flex´ıvel pois existem recursos que podem ser compartilhados sem a necessidade de reservas. Neste caso, uma pol´ıtica do tipo uso mediante disponibilidade seria mais adequada. Assim, o terceiro objetivo refere-se ao desenvolvimento de um mecanismo de autoriza¸cão que suporte diferentes pol´ıticas de uso dos recursos.

Contribui¸c˜

oes

A principal contribui¸cão do trabalho é uma infraestrutura que trata os problemas discutidos nas se¸cões e . Sendo assim, a infraestrutura contempla:

Uso da virtualiza¸cão para minimizar a influência do atraso e do jitter na intera¸cão com os recursos;

Um modelo fracamente acoplado para controle de acesso de WebLabs federados, baseado em solu¸c˜oes abertas;

Uso de pol´ıticas de autoriza¸c˜ao para flexibilizar o modelo de uso de recursos; Uma API para abstrair e simplificar o uso da infraestrutura.

A infraestrutura desenvolvida baseada em virtualiza¸cão agrega ao modelo de intera¸cão com os recursos do laboratório a possibilidade do usuário realizar o experimento na mesma rede

(35)

Introdu¸c˜ao 5

do recurso, mesmo o usuário estando em uma outra rede, como por exemplo a Internet. Este modelo também minimiza os problemas existentes nos demais trabalhos com rela¸cão à influência de atrasos, jitter e restri¸cão ao HTTP. Outra vantagem relacionada é que o usuário não precisa de uma máquina com alto poder de processamento e memória para executar um experimento, visto que sua VM está executando em um servidor com alto poder de processamento e memória. O modelo fracamente acoplado separa as responsabilidades do controle de acesso federado em provedor de servi¸co ou SP (Service Provider ) e provedor de identidade ou IdP (Identity Provider ). O modelo também separa as responsabilidades de autoriza¸cão em ponto de aplica¸cão de pol´ıtica ou PEP (Policy Enforcement Point) e ponto de decisão de pol´ıtica ou PDP (Policy Decision Point). Por fim, utiliza pol´ıticas de autoriza¸cão, que permite maior adapta¸cão do sistema ao modelo de uso de recursos de um laboratório.

Uma API foi desenvolvida com o objetivo de facilitar a utiliza¸cão da infraestrutura na execu¸cão de experimentos, cria¸cão de pol´ıticas e controle de VMs. A API abstrai muitas parti-cularidades das tecnologias adotadas e simplifica o uso destas.

Estrutura da Disserta¸c˜

ao

O texto da disserta¸cão está dividido em sete cap´ıtulos, incluindo este. O Cap. 1 apresenta os trabalhos correlatos. O Cap. 2 apresenta os conceitos gerais relacionados à virtualiza¸cão e descreve os principais conceitos e padrões relacionados à IdM federadas. O Cap. 3 apresenta o projeto da solu¸cão e o Cap. 4 apresenta a implementa¸cão da solu¸cão. Um estudo de caso é apresentado no Cap. 5 com o objetivo de validar o trabalho. Por fim, o Cap. 6 apresenta as conclusões e trabalhos futuros.

(36)

(37)

Cap´ıtulo

1

Trabalhos Correlatos

Este cap´ıtulo apresenta os trabalhos relacionados a esta disserta¸cão. Inicialmente, apresenta-se uma arquitetura geral de WebLabs e alguns dos principais trabalhos na área de WebLabs. A seguir, compara-se cada trabalho sob a ótica de arquitetura geral, mecanismo de controle de acesso e modelo de pol´ıticas de uso dos recursos.

1.1 Introdu¸c˜

ao

Na área de WebLabs ainda não há um consenso ou padrão de projeto que permita a com-para¸cão direta entre as diversas propostas. Um WebLab possui, basicamente, elementos para realizar a intermedia¸cão entre os recursos existentes e os usuários, um componente para realizar a gerência do ciclo de vida dos recursos (dispon´ıvel, reservado, em uso, etc.), um componente para autenticar os usuários que requerem acesso aos recursos e um componente para verifi-car a autoriza¸cão de acesso aos recursos. A Fig. 1.1 apresenta um modelo conceitual de uma arquitetura básica de um WebLab.

Fig. 1.1: Arquitetura B´asica de um WebLab.

O componente Intera¸cão é o principal componente da arquitetura e é responsável por in-termediar o envio de comandos ao recurso controlado e receber as respostas destes comandos. Por isso, este componente depende de um Recurso para realizar o controle e opera¸cão; de um componente responsável por realizar a Autentica¸cão; e de um componente para realizar a

(38)

riza¸cão do usuário que deseja operar o recurso. O componente Gerente de Recurso é responsável pelo ciclo de vida dos recursos.

Uma compara¸cão poss´ıvel de ser feita é com rela¸cão às tecnologias empregadas, complexi-dade dos recursos controlados e padrões arquiteturais de software e de rede empregados nos componentes da arquitetura básica apresentada. Em geral as abordagens mais simples são aquelas que utilizam arquitetura cliente-servidor para o controle de recursos através da Inter-net. Muitos laboratórios utilizam a tecnologia LabView (National Instruments Corp., 1986) ou MATLAB (The MathWorks Inc., 1984) para desenvolver o software que realiza a comunica¸cão entre o equipamento e o usuário conectado à Internet. Na literatura, há diversas propostas e versam sobre o controle dos mais variados equipamentos, desde placas de circuito impresso a robôs (GRAVIER et al., 2008). Algumas destas propostas têm o objetivo de oferecer o acesso remoto a um recurso espec´ıfico apenas, outras, assim como a proposta deste trabalho, tem como objetivo ser uma infraestrutura para o controle dos mais variados tipos de equipamentos e poder compartilhar estes recursos de forma segura com diversos dom´ınios parceiros através de uma ´

unica opera¸c˜ao de autentica¸c˜ao de identidades federadas.

Procurou-s nesta revisão avaliar os WebLabs que permitem a integra¸cão de diversos recursos de maneira federada, isto é, permitindo que estes recursos estejam espalhados por dom´ınios administrativos distintos e que ofere¸cam um mecanismo de autentica¸cão única (SSO) para os usuários destes dom´ınios. Nesta avalia¸cão, verificou-se a arquitetura geral, mecanismo de con-trole de acesso e pol´ıtica de uso dos recursos. Dentre os trabalhos na linha de plataformas de WebLabs e relevantes para a compara¸cão cita-se o iLab (HARWARD et al., 2008), o WebLab-Deusto (ORDU ÑA et al., 2011) e o REALabs (GUIMAR ÃES et al., 2011).

1.1.1 iLab 4.0.1

O iLab é um projeto iniciado no MIT (Massachusetts Institute of Technology) no ano de 1998. Surgiu como uma solu¸cão para o problema de viabilidade na manipula¸cão de um equipamento analisador de parâmetros em semicondutores, o único equipamento existente e cujo custo não viabilizava a aquisi¸cão para cada aluno e tão pouco a lota¸cão de todos os alunos no laboratório em torno deste único equipamento. A solu¸cão inicial foi apresentada por um aluno que desenvolveu uma interface em Java applet, que permitia aos alunos enviar pela Internet descri¸cões que caracterizam semicondutores a um servidor conectado diretamente ao analisador. O projeto evoluiu no final de 1999 com o nome de iCampus e com o objetivo de desenvolver diversos WebLabs para o controle de diversos tipos de equipamentos. No ano de 2001, inicia-se uma fase do projeto cujo objetivo era a integra¸cão dos diversos WebLabs através de uma infraestrutura comum. Esta infraestrutura utiliza a tecnologia de servi¸cos Web e apresenta um middleware denominado ISA (iLab Shared Architecture).

Arquitetura Geral

Na perspectiva do iLab, os experimentos estão classificados em três categorias ou modos de opera¸cão. Um modo batch, onde os parâmetros do experimento são definidos antes do in´ıcio da execu¸cão do mesmo. Um modo sensor, onde o experimento transcorre sem a intera¸cão do

(39)

1.1. Introdu¸c˜ao 9

usuário (aluno), que apenas monitora os dados apresentados em tempo real. E um último modo, denominado interativo, onde o usuário opera um dispositivo em tempo real. Para efeito de compara¸cão foca-se no modo de opera¸cão interativo, que é o modo utilizado neste trabalho. A Fig. 1.2 apresenta a arquitetura do iLabs para a execu¸cão de experimentos interativos.

Fig. 1.2: Arquitetura do iLabs para Experimentos Interativos. Baseado em (HARWARD et al., 2008).

A arquitetura do iLab possui três componentes distintos. O servidor do laboratório ou LS (Lab Server ), que se conecta ao recurso e tem como objetivo servir de meio para manipula¸cão do mesmo. O cliente do laboratório ou LC (Lab Client) é instalado no computador do usuário e é a interface para efetuar a opera¸cão remota. O componente ISB (Interactive Service Broker ) é responsável por mediar as trocas de informa¸cões pela Internet entre o servidor do laboratório e o cliente antes da realiza¸cão de um experimento. Este componente também oferece servi¸cos administrativos comuns, tais como autentica¸cão, autoriza¸cão e log da execu¸cão do experimento.

´

E importante ressaltar que o controle de um experimento ocorre sem a intermedia¸cão do ISB. Além dos três componentes já mencionados, há um componente denominado servidor de armazenamento ou ESS (Experiment Storage Service), responsável pela armazenagem de dados decorrentes da realiza¸cão de um experimento e outro componente denominado servidor de re-serva ou SS (Schedulling Service), responsável pela rere-serva dos experimentos. Na arquitetura do iLab este componente está separado em um lado cliente ou USS (User-Side Schedulling Service) e um lado servidor ou LSS (Lab-Side Schedulling Service). O lado servidor é responsável por coordenar as reservas realizadas por múltiplos dom´ınios e também por inicializar o LS para re-alizar tarefas pré-execu¸cão de um determinado experimento. O lado cliente oferece aos usuários a possibilidade de agendar os experimentos e comunicar-se com o lado servidor dos diversos dom´ınios.

(40)

Controle de Acesso

Para um usuário iniciar um experimento é necessário antes se autenticar no ISB. O me-canismo de controle de acesso não segue um padrão aberto e possui o nome de general ticke-ting (NORTHRIDGE et al., 2010). Neste esquema há 3 partes bem definidas. O chamado detentor do ticket (ticket holder ), que é o processo que está fazendo uma chamada a um servi¸co Web ou tentando acessar uma página. O processo para onde o detentor do ticket envia uma re-quisi¸cão para valida¸cão do mesmo é chamado de redentor do ticket (ticket redeemer ). O servidor que expede uma credencial é chamado de expedidor de ticket (ticket issuer ). Como detentor do ticket pode-se ter aplica¸cões Web, o USS ou a aplica¸cão cliente do laboratório. Como redentor do ticket pode-se ter o LS, atuando no caso da tentativa de execu¸cão de um experimento ou o USS, no caso de uma opera¸cão de confirma¸cão de uma reserva por parte de um usuário para executar um experimento. O expedidor do ticket sempre é o ISB.

O expedidor do ticket mantém cópias de todos os tickets expedidos para que todos os re-dentores do ticket tenham uma rela¸cão de confian¸ca. Ele também deve fornecer aos detentores de ticket o chamado ticket coupon para que estes obtenham autoriza¸cão de acesso aos recursos. Quando um SP (LS ou USS) recebe uma chamada via servi¸co Web de um cliente, o mesmo necessita apresentar o coupon ID, provido pelo ISB, para este redentor. O redentor usará este coupon ID para obter o ticket do ISB. Se o ticket for obtido do ISB significa que a a¸cão foi autenticada pelo ISB. Como o ISB é o gerente de todos os SPs de um dado dom´ınio local, e é o elemento central do mecanismo de tickets, o redentor confiará em todos os tickets expedidos por este ISB. O ticket é uma estrutura de dados em XML (eXtensible Markup Language) e é encapsulado no cabe¸calho de uma mensagem SOAP (Simple Object Access Protocol ), utilizando estratégia semelhante ao WS-Security (OASIS, 2006). Para criar um canal confiável para o trá-fego destas mensagens utiliza-se o protocolo SSL (Secure Sockets Layer ). A Fig. 1.3 apresenta uma visão geral do mecanismo de controle de acesso intradom´ınio empregado no iLab.

Fig. 1.3: Vis˜ao Geral do Mecanismo de Controle de Acesso Intradom´ınio do iLab. Baseado em (NORTHRIDGE et al., 2010).

No passo 1 da Fig. 1.3 o usu´ario se autentica no ISB e indica que quer confirmar uma reserva feita anteriormente e com isso iniciar um experimento. O ISB redireciona o LC para o USS com

(41)

a autoriza¸cão de ler e confirmar a reserva. No passo 2, o USS permite ao usuário resgatar a reserva feita anteriormente e também autoriza a cria¸cão de um ticket no ISB, que representa a permissão de realiza¸cão do experimento durante o per´ıodo de validade da reserva. Neste passo, o usuário é redirecionado de volta ao ISB. No passo 3, o LC requisita o in´ıcio do experimento. O ISB cria o coupon e adiciona um ticket autorizando armazenagem de dados do experimento no ESS e outro para in´ıcio do experimento. O ISB inicia o LC e passa o coupon. No passo 4, o LC realiza uma chamada via servi¸cos Web ao LS passando o coupon.

O LS utilizará este coupon para obter o ticket de execu¸cão, que especifica a reserva do usuário e o n´ıvel de acesso. Se o usuário tiver autoriza¸cão neste LS, este abrirá um canal de comunica¸cão direta com o LC (sem passar pelo ISB). No passo 5 o LS comunicará o servidor ESS para armazenar os dados do experimento em nome do usuário. É importante ressaltar que cada requisi¸cão de armazenamento é acompanhado do mesmo coupon que o cliente originalmente apresentou para o LS. No passo 6, o ESS usa o coupon para obter o ticket de armazenamento criado pelo ISB para a realiza¸cão desta sessão de experimenta¸cão. Este ticket é armazenado em memória cache para uso futuro.

No controle de acesso interdom´ınio, os ISBs de ambos os dom´ınios são os elementos de confian¸ca entre o LC de um dom´ınio e os SPs de outro. Para que haja uma confian¸ca mútua entre os ISBs há uma chamada via servi¸co Web denominada InstallDomainCredentials, onde há a passagem de um passkey, que atua no estabelecimento da confian¸ca. A Fig. 1.4 apresenta como exemplo o caso de um usuário de um dom´ınio A confirmar uma reserva para executar um experimento em um dom´ınio B. O USS do dom´ınio A necessita chamar um método Web denominado Confirm reservation no LSS do dom´ınio B. Com isso, o ISB do dom´ınio A (ISB A) criará um ticket denominado REQUEST RESERVATION TICKET após autenticar esta chamada (passos 1 e 2). O coupon ID, identificando os tickets, é então acrescentado nesta requisi¸cão (passo 3). Quando o LSS receber esta chamada do USS, verificará o ticket através da obten¸cão do ISB do dom´ınio B (ISB B), conforme passo 4. No passo 5, o ISB B, então, consultará o ISB A para obter o ticket e, assim, encaminhará para o LSS, conforme passo 6, que enviará os horários dispon´ıveis para o USS.

O USS retornará estes horários ao usuário (LC), que por sua vez alterará ou confirmará a reserva no USS. O USS contactará o LSS para confirmar a a¸cão na reserva. É importante ressaltar que este processo de obten¸cão de tickets por parte dos ISBs de ambos os dom´ınios também ocorre no in´ıcio de um experimento.

Pol´ıtica de Uso

A pol´ıtica de uso adotada é de uso mediante reserva. O servi¸co de reservas do iLab oferece a usuários e professores distintas funcionalidades. Para os usuários, o iLab possibilita reservar, cancelar e receber notifica¸cões. Para os professores, possibilita definir parâmetros a respeito da execu¸cão de um experimento. Aos administradores do laboratório oferece a possibilidade de coordenar as reservas no caso de uso compartilhado entre diversos dom´ınios. Estes requisitos refletem na arquitetura do iLab no uso dos componentes USS e LSS. No iLab há o conceito de divisão de tempo em blocos, per´ıodos e reincidência. Bloco de tempo possui as propriedades de in´ıcio, fim e dura¸cão. Um per´ıodo de tempo estende as propriedades do bloco de tempo

(42)

Fig. 1.4: Vis˜ao Geral do Mecanismo de Controle de Acesso Interdom´ınio do iLab. Adaptado de (MAO, 2007)

com a adi¸cão de um quantum, que é um tempo limite para a divisão do per´ıodo de tempo em blocos de tempo. O quantum é utilizado para determinar o tempo dispon´ıvel e para minimizar a fragmenta¸cão do tempo dispon´ıvel. A reincidência especifica uma cole¸cão de blocos de tempo não sobrepostos que abrangem uma série de datas relacionadas a um evento de experimenta¸cão. As reincidências podem ser diárias, semanal, mensal, etc.

No USS, é permitida a defini¸cão de tempo m´ınimo e tempo máximo de uma reserva. Já no lado do LSS, a pol´ıtica de uso padrão é do tipo FCFS (First-Come, First-Served ) e permite também determinar permissões para grupos executarem um experimento no tempo requisitado.

An´alise do iLab 4.0.1

Em uma análise geral do iLab, observa-se que sua infraestrutura é constitu´ıda em grande parte por tecnologias proprietárias (como por exemplo .NET) e requer instala¸cão de parte desta infraestrutura no lado cliente. Isto limita a possibilidade de ado¸cão da solu¸cão. Na questão do controle de acesso, também é utilizado uma solu¸cão própria (general ticketing), com elementos do WS-Security (na comunica¸cão entre o USS e o LSS). Esta solu¸cão dificulta a integra¸cão com outras infraestruturas de WebLabs, pois não há a utiliza¸cão de um padrão aberto para IdM federadas, como por exemplo o SAML (Security Assertions Markup Language). O mecanismo de federa¸cão está todo concentrado no ISB, que apesar de ser uma solu¸cão simples e funcional, é uma arquitetura centralizada e, portanto, um ponto de falha.

Por fim, a questão da latência da rede Internet não é tratada. Este fator pode prejudicar uma sessão de experimenta¸cão e limitar o escopo de experimentos. Apesar da comunica¸cão entre o lado cliente e o lado servidor ocorrer sem a intera¸cão do ISB, ainda assim o tráfego está sujeito a atrasos decorrentes da própria natureza da Internet e da intermedia¸cão do LS. Com rela¸cão às pol´ıticas de uso, não há um mecanismo para permitir a defini¸cão de diferentes modelos de uso.

(43)

1.1.2 WebLab-Deusto 4.0

O WebLab-Deusto é uma plataforma de WebLab desenvolvido pela Universidade de Deusto, na Espanha. Esta plataforma é utilizada desde 2005 e atualmente controla experimentos vari-ados. Assim como o iLab, a plataforma vem se atualizando continuamente. Em sua primeira versão a plataforma era dependente de dom´ınio e o lado cliente era baseada em Java. Já em sua segunda versão, houve a mudan¸ca no lado cliente para o uso de AJAX (Asynchronous JavaS-cript and XML) e servi¸cos Web. A terceira versão apresentou atualiza¸cões na arquitetura para facilitar a integra¸cão de novos experimentos por parte dos desenvolvedores. A quarta e última versão apresenta adapta¸cões para o uso em dispositivos móveis e navegadores comuns (como por exemplo, o Firefox). Nesta última versão também há o suporte a múltiplos esquemas de au-tentica¸cão, tais como banco de dados, LDAP (Lightweight Directory Access Protocol ), OpenID e Facebook (através do OAuth 2.0) (GARCÍA-ZUBIA et al., 2012).

Arquitetura Geral

O WebLab-Deusto apresenta duas abordagens no que diz respeito ao desenvolvimento de um experimento. Uma abordagem denominada gerenciada, onde um experimento é executado uti-lizando todas as facilidades oferecidas pela arquitetura do WebLab. O WebLab-Deusto oferece um conjunto de bibliotecas tanto para o lado cliente quanto para o lado servidor, afim de tratar a comunica¸cão entre ambos. Também oferece um componente intermediário (um servidor) para tratar da seguran¸ca na comunica¸cão entre os lados cliente e servidor. A comunica¸cão entre ambos os lados é realizada com o uso do SSL. Outra abordagem é a denominada não gerenci-ada, onde o desenvolvedor do experimento não utiliza a infraestrutura oferecida pelo ambiente para a comunica¸cão entre o cliente e o servidor. Neste caso, o desenvolvedor fica responsável por desenvolver tanto o lado cliente quanto o lado servidor e o método de comunica¸cão entre ambos. Se desejar, pode integrar em seu experimento os componentes de autentica¸cão, auto-riza¸cão e reserva oferecidos pela plataforma. Para este caso, o WebLab-Deusto oferece uma VM ao desenvolvedor do experimento. A Fig. 1.5 apresenta uma visão geral da arquitetura do WebLab-Deusto.

Nesta arquitetura os clientes conectam-se aos servidores (WebLab-Deusto Servers). Utiliza-se uma arquitetura multicamadas, Utiliza-sendo que a camada de apreUtiliza-senta¸cão está localizado no lado cliente. As camadas de lógica de negócio e de persistência de dados estão localizados nestes servidores. Entre os servidores há um denominado servidor de autentica¸cão, responsável por oferecer o servi¸co através de diversos métodos de autentica¸cão. O servidor do laboratório (La-boratory Server ) é responsável por controlar os diversos recursos existentes e, com isso, oferecer os chamados experimentos gerenciados (Managed Experiments). No caso dos experimentos não gerenciados (Unmanaged Experiments), o acesso a VM não passa pela infraestrutura do We-bLab (a menos que o desenvolvedor implemente em seu experimento chamadas aos servi¸cos de autentica¸cão, autoriza¸cão e reserva da plataforma) e pode ser feito através de RDP (Remote Desktop Protocol ), SSH (Secure SHell ) ou VNC (Virtual Network Computing). Quando um usuário realizar este experimento, o WebLab-Deusto instanciará uma VM do VirtualBox (ini-ciando a partir de um snapshot), gerará uma senha aleatória e configurará esta senha na VM. Esta mesma senha será enviada ao lado cliente e a VM passará a aceitar conexões contendo esta

(44)

Fig. 1.5: Vis˜ao Geral da Arquitetura do WebLab-Deusto 4.0.1. Baseado em (ORDU ˜NA et al., 2011).

senha. No momento s˜ao suportadas as tecnologias SSH e VNC, em VMs Linux e VNC e RDP, em VMs Windows.

Controle de Acesso

O WebLab-Deusto oferece diversos mecanismos de autentica¸cão. Por exemplo, é poss´ıvel utilizar mecanismos de autentica¸cão baseados em base de dados, em um IP (Internet Protocol ) espec´ıfico, LDAP ou padrões de autentica¸cão federada. O mecanismo de autentica¸cão através de base de dados utiliza um hash da senha armazenada em uma tabela do MySQL. O mecanismo baseado em um IP permite que, por exemplo, um sistema do tipo LMS (Learning Management System), pertencente a um dom´ınio parceiro (e possuindo o IP esperado), acesse o dom´ınio local, estabelecendo uma rela¸cão de confian¸ca entre este dom´ınio remoto e o dom´ınio local. Já o mecanismo LDAP utiliza os métodos de um servidor LDAP para autenticar um usuário. O mecanismo de autentica¸cão federada utiliza o OpenID ou Facebook para permitir que contas vindas destes dom´ınios utilizem o laboratório. Este último mecanismo pode ser estendido pelo desenvolvedor, desde que este implemente os métodos abstratos do padrão de projetos Facade, desenvolvido em Python.

Dado os diferentes mecanismos de autentica¸cão, é poss´ıvel, ainda, combiná-los de maneira semelhante ao conceito de cadeias e autentica¸cão (authentication chain), que torna poss´ıvel configurar, para cada usuário, uma sequência de mecanismos de autentica¸cão. No caso do WebLab-Deusto, esta configura¸cão fica armazenada em banco de dados. Com isso, cada meca-nismo avaliará as credenciais do usuário de acordo com a sua lógica. Como exemplo, cita-se o caso de configura¸cão de dois mecanismos de autentica¸cão para um dado usuário “usuário1”, um através de senha armazenada em banco de dados e outro através de um servidor LDAP. Assim, o servi¸co primeiro avaliará as credenciais com o primeiro mecanismo. Caso este falhe, o segundo

(45)

mecanismo avaliará as credenciais segundo sua lógica. Caso este último falhe, o usuário é consi-derado inválido. Caso algum mecanismo ateste a validade do usuário, o servi¸co de autentica¸cão entenderá que é um usuário válido.

Pol´ıtica de Uso

A pol´ıtica de uso é baseado em filas de prioridades com balanceamento. Apesar de sua arquitetura servir para o controle de experimentos variados, historicamente, o WebLab-Deusto é utilizado para a realiza¸cão de experimentos na área de engenharia eletrônica. Neste caso, para um dado experimento, existem diversos recursos idênticos para serem alocados entre os estudantes. Cada recurso possui uma fila e o conjunto de filas do experimento é balanceado para atender a demanda de usuários. Por exemplo, se houver dispon´ıveis cinco recursos diferentes e seis usuários querendo utilizar estes recursos, os cinco primeiros usuários serão atendidos e o sexto usuário será enfileirado, ou seja, será criada uma reserva. A utiliza¸cão dos recursos por parte dos cinco usuários ocorrerá por um certo limite de tempo e, após expira¸cão deste tempo, ou se houver libera¸cão espontânea, o sexto usuário será atendido.

O WebLab-Deusto traz algumas melhorias na pol´ıtica de uso em rela¸cão a versões anteriores. No caso da possibilidade de executar o experimento em mais de um tipo de dispositivo, há uma lógica para reservar o experimento em todas as filas poss´ıveis. Por exemplo, se em uma universidade existem diferentes experimentos, um utilizando FPGA (Field-Programmable Gate Array) e outro utilizando CPLD (Complex Programmable Logic Device), haverá uma fila para os recursos do tipo CPLD e outra fila para os recursos do tipo FPGA. Quando um usuário for reservar um experimento, a reserva será enfileirada em todas as poss´ıveis filas válidas. Na ocasião do usuário requisitar a quantidade de reservas do experimento, neste caso o servi¸co informará sempre o resulado mais otimista. Por exemplo, se houver vinte reservas para FPGA e somente dez para CPLD, o sistema reportará que existem dez reservas.

An´alise do WebLab-Deusto 4.0

O WebLab-Deusto oferece uma VM para o desenvolvedor implementar um experimento não gerenciado. Isto é interessante do ponto de vista do desenvolvedor, que possui uma forma de criar um novo experimento e com isso ampliar a oferta de experimentos da plataforma, porém este será um experimento não gerenciado pela plataforma (a menos que implemente). Ainda com rela¸cão ao uso de experimentos não gerenciados, a rastreabilidade das a¸cões dos usuários é dif´ıcil de ser realizada, uma vez que a comunica¸cão com o recurso é feita fora da plataforma, diferentemente dos experimentos gerenciados.

Do ponto de vista do usuário, que acessará o experimento via aplica¸cão de terminal remoto, como por exemplo o RDP, há uma questão relacionada ao uso de firewall, pois estas aplica¸cões utilizam portas muitas vezes bloqueadas em ambientes institucionais (5900 para o VNC, 22 para SSH e 3389 para o RDP). Também não é poss´ıvel realizar estes experimentos a partir de institui¸cões que utilizam um proxy HTTP como sa´ıda para uma rede pública (por exemplo, Internet), uma vez que estas comunica¸cões provavelmente serão bloqueadas pelo proxy.

O esquema de controle de acesso é extens´ıvel para permitir que diferentes mecanismos co-existam. Isto é interessante pois, do ponto de vista da área de IdM federadas, ainda não há

(46)

um padrão consolidado. Apesar disso, o esquema baseado em um IP espec´ıfico não é confiável, uma vez que o IP pode facilmente ser forjado por um atacante. O uso deste esquema abre uma falha de seguran¸ca no ambiente. Outra questão é que, para integrar aplica¸cões de terceiros, há a necessidade de se utilizar uma API para gerenciar as identidades, fato este que pode dificultar a integra¸cão.

O modelo de pol´ıticas de uso adotado pelo laboratório, especialmente para experimentos do tipo batch (em lote), combina um modelo de filas com a possibilidade de reserva do recurso no caso de fila cheia ou o recurso ocupado. Contudo, o modelo não é flex´ıvel para facilitar a cria¸cão de novos modelos de uso (concorrente, oportunista, entre outros). Por fim, o uso de um conjunto de servidores no ambiente de WebLabs pode tornar mais trabalhosa a sua gerência. A latência da Internet pode ser tratada apenas nos experimentos do tipo não gerenciado.

1.1.3 REALabs

A plataforma REALabs, desde a sua origem até sua atual versão, recebeu diversas aborda-gens, implementa¸cões e tecnologias. O in´ıcio das pesquisas em WebLabs, no Brasil, data do ano de 1996, por meio do projeto REAL (Robotics Research Internet-Accessible Laboratory). Esta primeira versão adota a arquitetura clássica cliente-servidor, onde o experimentador opera uma interface desenvolvida em Java applet. A partir de então o projeto evolui continuamente.

A segunda versão data do ano de 1997, a partir de um acordo de coopera¸cão entre o CTI (Centro de Tecnologia da Informa¸cão) Renato Archer e a FEEC (Faculdade de Engenharia Elétrica e de Computa¸cão) da Unicamp, com o objetivo de construir plataformas baseadas em padrões abertos para o desenvolvimento de WebLabs. Denominado WebLab REAL, esta ver-são adotou uma arquitetura de objetos distribu´ıdos CORBA (Common Object Request Broker Architecture) (OBJECT MANAGEMENT GROUP, 2002). No ano de 2000 tem in´ıcio o desen-volvimento da terceira versão do REAL WebLab. Esta versão utiliza uma arquitetura baseada em um modelo de componentes CM-tel e a plataforma CCM-tel. A quarta versão, desenvolvida em 2003, do REAL WebLab utiliza o modelo de componentes CM-tel e a plataforma MECM-tel para dispositivos móveis. Nesta versão utilizou-se uma metodologia de desenvolvimento de software baseado em componentes para dispositivos móveis com baixo poder computacional.

A quinta versão desenvolveu uma arquitetura elegante, baseada em SOA, porém ao longo do tempo a implementa¸cão desta arquitetura apresentou problemas no processamento das men-sagens SOAP no lado cliente, dificuldades em operar em tempo real com o protocolo SOAP e dificuldades para compor servi¸cos utilizando BPEL (Business Process Execution Language) (MI-CROSOFT et al., 2003). Assim, a sexta versão, datada de 2007 adicionou à versão anterior apri-moramentos com o objetivo de simplificar e ganhar maior eficiência no uso da plataforma em ambos os lados cliente e servidor. A nova arquitetura substituiu SOAP por REST (REpresen-tational State Transfer ) e no lado cliente priorizou-se tecnologias baseadas em XML, tais como AJAX. Foi introduzido o conceito de SSO como mecanismo de autentica¸cão entre os dom´ınios federados e o uso do protocolo SAML 1.0.

(47)

Arquitetura Geral

O REALabs é uma plataforma genérica para a realiza¸cão de experimentos. Sua concep¸cão está baseada na arquitetura SOA. Sua implementa¸cão utiliza a tecnologia J2EE (Java2 Platform Enterprise Edition), através de servlets e JSP (Java Server Pages). A plataforma possui um conjunto de servi¸cos para gerência de usuários, gerência de recursos, gerência de SLA (Service Level Agreement), pol´ıticas de QoS (sobre a Internet) e gerência de acesso. Estes servi¸cos seguem o padrão REST de intera¸cão, que são invocados via opera¸cões do HTTP (GET ou POST). Algumas destas opera¸cões possuem documentos XML em seu payload. A Fig. 1.6 apresenta uma visão geral da arquitetura da plataforma REALabs.

Management User Resource HTTP Single Sign Application Service Session Management Service Service Management Microserver Tomcat Server Resource (Authentication) On Service Reservation Service Client Computer Components Web Programming Interfaces Apache Server Filter Proxy HTTP Agent Controller Traffic HTTP (Authorization)

Fig. 1.6: Vis˜ao Geral da Arquitetura do REALabs (GUIMAR ˜AES et al., 2011).

O servi¸co de gerência de acesso compreende os componentes de reserva (Reservation Service), de autentica¸cão federada (Single Sign-On Service) e de sessão (Session Management Service). Estes componentes estão instalados em um servidor Apache Tomcat. Neste mesmo servidor es-tão os componentes de gerência de usuário (User Management Service) e de gerência de recursos (Resource Management Service). O componente de autentica¸cão federada possui intera¸cão com o componente Web (Web Components), localizado na máquina do cliente. Na máquina do cliente há também uma API responsável por oferecer uma interface de programa¸cão para o controle do robô. Esta interface atualmente está desenvolvida nas linguagens Java, MATLAB, Python e C/C++.

A comunica¸cão entre a máquina do cliente e o recurso é realizada através do componente de interface de programa¸cão de aplica¸cão (Application Programming Interfaces) e passa por um

(48)

servidor Apache configurado para atuar como um proxy (HTTP Proxy Agent). Neste servidor Apache há um componente para filtragem das requisi¸cões e para realizar a autoriza¸cão (HTTP filter ), e um componente para controle de tráfego (Traffic Controller ). Este componente de controle de tráfego realiza prioriza¸cão do tráfego e limita¸cão de banda. No lado do recurso há um micro servidor HTTP (HTTP Microserver ), responsável por traduzir as requisi¸cões em comandos nativos ao recurso.

Controle de Acesso

A autentica¸cão no REALabs é realizada através do componente Single Sign-On Service. Este componente realiza a autentica¸cão de forma federada e utiliza a biblioteca OpenSAML para criar, assinar e validar as asser¸cões SAML 1.0. A autoriza¸cão utiliza o componente de gerência de sessão para iniciar e manter sessões de intera¸cão. Este servi¸co de sessão instala um cookie no navegador do usuário para ser utilizado em todas as intera¸cões HTTP subsequentes. O cookie será checado na autoriza¸cão, onde um filtro HTTP verificará a existência deste elemento a fim de determinar se o usuário possui uma sessão de intera¸cão válida.

O filtro HTTP atua como um PEP e é um código extra incorporado ao servidor Apache. Este filtro permite extrair parâmetros do cookie e realizar uma a¸cão de autoriza¸cão com base em uma decisão vinda de uma terceira entidade. Esta terceira entidade atua como um PDP. Esta receberá os parâmetros obtidos pelo filtro e verificará se a requisi¸cão está autorizada ou não a continuar. A decisão será então aplicada pelo filtro, que bloqueará ou permitirá a continua¸cão da requisi¸cão. Se a requisi¸cão continuar, significará que o usuário está autorizado e, caso contrário, será enviada uma mensagem HTTP relacionada com a proibi¸cão do acesso.

Pol´ıtica de Uso

A pol´ıtica de uso adotada no REALabs é de uso mediante reserva. O servi¸co de reserva permite que os usuários reservem um per´ıodo de tempo para realizar um experimento. A reserva só é permitida durante o per´ıodo que o experimento está aberto para reservas. Também só é permitida a realiza¸cão da reserva por pessoas autenticadas e autorizadas. Uma vez realizada a reserva, o usuário pode acessar o recurso no horário determinado, mas antes deve apresentar suas credenciais e, se for autorizado pelo ambiente, estará apto a iniciar o experimento.

An´alise do REALabs

O REALabs é um exemplo de uma plataforma genérica para experimenta¸cão que vem evo-luindo ao longo de uma década. Possui arquitetura baseada em SOA, que está em linha com os demais trabalhos estudados. Possui controle de acesso federado baseado em SAML 1.0, que é um protocolo com maiores preocupa¸cões com a seguran¸ca em rela¸cão aos protocolos utilizados nos demais trabalhos estudados, porém é um protocolo mais complexo de se utilizar.

Uma questão em aberto é com rela¸cão ao atraso inerente nas comunica¸cões realizadas via Internet. Como o principal uso da plataforma é para ensino de robótica móvel, neste caso, os atrasos podem interferir no controle do robô. Além de degradar a experiência do usuário,

(49)

1.2. Considera¸c˜oes Finais 19

obrigando o robô a operar em baixa velocidade, acabará por introduzir erros no experimento. Este fato, também, pode simplesmente inviabilizar a realiza¸cão de determinados experimentos. Outra questão em aberto diz respeito a pol´ıtica de uso. A plataforma não contempla um mecanismo que permita a defini¸cão de diferentes pol´ıticas para acesso aos recursos. É interes-sante ter esta flexibilidade para definir pol´ıticas de uso sem necessitar altera¸cões de código no componente que realiza a autoriza¸cão. Este fator facilitaria a provisão de novos experimentos.

1.2 Considera¸c˜

oes Finais

Neste cap´ıtulo foram apresentados os trabalhos relacionados a esta disserta¸cão. Dado a diversidade de trabalhos existentes na literatura, adotou-se os seguintes critérios para a escolha: compartilhamento de experimentos através de federa¸cão, possibilidade de realizar experimentos independentes de dom´ınio, uso de padrões e tecnologias abertas e relevância histórica para a área. Segundo Guimarães et al. (2011), estes critérios são importantes para serem considerados por institui¸cões que utilizam esta tecnologia no aux´ılio à atividades de ensino e pesquisa. Com base nestes critérios, estudou-se o iLabs, o WebLab-Deusto e o REALabs.

Nos trabalhos escolhidos, focou-se na avalia¸cão da arquitetura geral, no mecanismo utilizado para controle de acesso federado, na pol´ıtica de uso dos recursos e no tratamento do atraso e jitter. O objetivo desta avalia¸cão foi de estudar como cada trabalho trata estas questões a fim de se obter informa¸cões e pontos de melhoria para o desenvolvimento de nossa proposta. Em especial, verificou-se que a questão da pol´ıtica de uso em ambos os trabalhos não é flex´ıvel, a ponto de permitir a defini¸cão de diversos modelos. Outra questão é com rela¸cão ao tratamento do atraso e do jitter, que não é tratado tanto no caso do iLabs quanto no REALabs. No caso do WebLab-Deusto, esta questão não é tratada diretamente. Em Garc´ıa-Zubia et al. (2012), os autores citam experimentos não gerenciados, onde o laboratório oferece uma VM para o desenvolvedor criar um experimento. Este, porém, não estará automaticamente integrado à infraestrutura do laboratório. A Tab. 1.1 apresenta um resumo destas informa¸cões.

Proposta Arq. Geral Controle de Acesso Pol´ıtica de Uso Atraso e jitter

iLabs Broker Prop. + WS-Security Reserva N˜ao

REALabs Servi¸cos SAML 1.0 Reserva N˜ao

Deusto 3-tier Multipadr˜oes Fila com reserva N˜ao

Tab. 1.1: Resumo dos Trabalhos Correlatos Avaliados.

Por fim, ressalta-se que esta disserta¸cão não estende a plataforma REALabs. Ao invés disso, propõe-se uma nova infraestrutura, baseada nos trabalhos correlatos deste cap´ıtulo. A influência do REALabs neste trabalho é relevante, uma vez que a experiência do grupo está baseada nos estudos, evolu¸cões e implementa¸cões desta plataforma. No próximo cap´ıtulo apresentam-se os conceitos e tecnologias relevantes que serviram de base para entendimento e escolha das tecnologias.

(50)

(51)

Cap´ıtulo

2

Conceitos e Tecnologias Relevantes

Este cap´ıtulo apresenta os principais conceitos e tecnologias relevantes para este trabalho. O cap´ıtulo é composto de três se¸cões. A primeira apresenta uma contextualiza¸cão sobre o conceito de virtualiza¸cão, seus tipos e uma descri¸cão sobre as tecnologias adotadas. A segunda parte apresenta os conceitos e técnicas relacionadas ao tema de IdM. A terceira apresenta os padrões e solu¸cões (middlewares) relacionados ao trabalho.

2.1 Vis˜

ao Geral sobre Virtualiza¸c˜

ao

Em essência, a virtualiza¸cão consiste em imitar um comportamento, seja por extensão ou substitui¸cão de um recurso por outro (CARISSIMI, 2008). A virtualiza¸cão também é definida como um sistema ou um método de dividir os recursos computacionais em múltiplos ambientes isolados (OpenVZ, 2010). O conceito de virtualiza¸cão remonta à virtualiza¸cão de recursos em SOs. Solu¸cões de alto n´ıvel como interfaces gráficas, bibliotecas e APIs são exemplos de recursos de software que tornam transparente para o usuário o acesso aos recursos de hardware, em especial, o acesso aos periféricos de entrada e sa´ıda. Ou seja, cria-se a ilusão no SO de que se tem a intera¸cão direta com os recursos de hardware. Diz-se também que a virtualiza¸cão é uma metodologia para dividir os recursos de um computador em múltiplos ambientes de execu¸cão conhecidos como máquinas virtuais ou VMs, aplicando conceitos de particionamento, time-sharing, simula¸cão completa ou parcial de máquina, emula¸cão, QoS, entre outros (CARISSIMI, 2008).

Portanto, a virtualiza¸cão é uma técnica para ocultar caracter´ısticas f´ısicas de recursos com-putacionais, de forma que os sistemas, aplica¸cões e usuários interajam com esses recursos. Nesta técnica, um único recurso f´ısico, como um servidor, dispositivo de armazenagem ou SO, passa a ser visto como múltiplos recursos lógicos.

A virtualiza¸cão remonta às décadas de 60 e 70. Com o uso de VMs era poss´ıvel executar e migrar aplica¸cões legadas entre plataformas distintas, desde que houvesse uma versão da VM para a plataforma alvo. A principal motiva¸cão era ampliar e melhorar a utiliza¸cão e o compartilhamento de recursos nos mainframes (CARISSIMI, 2008).

Com a redu¸c˜ao do custo de hardware em meados da d´ecada de 80, ocorreu uma mudan¸ca de foco de processamento centralizado em mainframes para o processamento distribu´ıdo em