Autenticação e Autorização para Acesso a aplicações em
um Barramento de Serviços para a Web das Coisas
Tito Gardel, Nailton Andrade, Felix Farias, Cássio Prazeres
Departamento de Ciência da Computação – Universidade Federal da Bahia (UFBA) Av. Adhemar de Barros, Ondina, Salvador-BA, Brasil
{tito.gardel, nailtonjr, prazeres, felix072}@dcc.ufba.br Resumo. Um novo paradigma da Web, com foco em serviços e aplicações para
serem consumidas também por outras aplicações, em contrapartida à Web feita apenas para e por pessoas, está se delineando como o próximo passo de evolução da Web. Essa evolução deve permitir o surgimento de uma gama de oportunidades e possibilidades de novas e poderosas aplicações para a Web. Uma dessas aplicações é a possibilidade de aliar as coisas do mundo físico às coisas do mundo virtual da Web, que está sendo chamada de “Web das Coisas”. Nesse contexto, questões como segurança, confiança e privacidade são essenciais. Este artigo apresenta uma infraestrutura para disponibilização de dispositivos físicos na Web por meio de barramento de serviços. Para controlar e prover segurança no acesso a esses dispositivos é proposta deste artigo a utilização de mecanismos de autenticação e de autorização.
Abstract. One of the next steps of evolution of the Web is a new paradigm that
has focus in services and applications to be consumed by others applications. This evolution should allow the emergence of a range of opportunities and possibilities for new powerful applications for the Web. One of these applications is the ability to combine things from the physical world to the virtual world of things on the Web: the Web of Things. In this context, issues such as security, privacy and trust are essential. This paper presents an infrastructure for the provision of physical devices on the Web by means of Enterprise Service Bus. To provide security and control access to these devices is proposed in this paper the utilization of authentication and authorization mechanisms.
1. Introdução
Dispositivos eletrônicos estão cada vez mais comuns nas tarefas do dia-a-dia: pequenos computadores com grande poder de processamento, smartphones e outros dispositivos móveis, sensores e atuadores, dentre outros. Diante disso, surge a oportunidade de criar novas e interativas aplicações a partir da combinação de dispositivos heterogêneos. Entretanto, integrar dispositivos com diferentes capacidades, funcionalidades, aplicações, middlewares e protocolos de rede, para criar aplicações de forma ad-hoc é um grande desafio. Nesse intuito, é necessária uma infraestrutura que seja: simples, leve, de baixo acoplamento, escalável, flexível e, o mais importante, que seja um padrão universal. A Web reúne todas essas características e ainda conta com a vantagem de que muitos desses dispositivos possuem tecnologias de conectividade com a Internet.
A Web das Coisas será um ambiente em que objetos físicos (eletrônicos ou não) do dia-a-dia, como edifícios, automóveis, mercadorias, matérias-primas, eletrodomésticos, dentre outros, se tornarão legíveis, identificáveis, endereçáveis e, ainda, controláveis utilizando serviços através da Web [9]. Isso permite a evolução de aplicações para a Web com uma vasta gama de novas oportunidades de negócio, tais como suporte para a vida independente dos idosos, gestão eficiente de energia [5], gestão de ambientes inteligentes [7], gestão inteligente do tráfego, gestão de segurança pública e privada, gerenciamento eficiente de cadeias de suprimento e o monitoramento do meio ambiente [6].
Em ambientes inteligentes, por exemplo, uma “smarthome” (casa inteligente), sensores e atuadores, que captam e controlam, dentre outras coisas, a temperatura ambiente, a luminosidade dos cômodos e o consumo de energia, podem ter suas funcionalidades (temperatura, luminosidade e energia) expostas e acessíveis por meio de serviços na Web.
A grande variedade de coisas, dispositivos do dia a dia, que podem ser acessadas utilizando a Web das Coisas, demanda por infraestruturas capazes de gerenciar a publicação, descoberta, composição, utilização e compartilhamento desses dispositivos na Web. Neste trabalho, é utilizado um barramento de serviços como infraestrutura de publicação e descoberta para a Web das Coisas.
Os serviços publicados no barramento poderão ser acessados, utilizados e compartilhados por outras aplicações bem como por usuários finais dessas aplicações. Dessa forma, é de importância fundamental tratar problemas de autenticação e de autorização no acesso aos dispositivos disponibilizados como serviços no barramento. Um dos requisitos principais para uma infraestrutura de compartilhamento na Web das Coisas é estar segura, a fim de se certificar de que o acesso aos dispositivos não será concedido indevidamente.
A proposta deste artigo é prover gestão de autenticação e de autorização na Web das Coisas utilizando o protocolo OpenID Connect. Para isso, foi definido um modelo de gestão de autenticação e autorização para a Web das Coisas. Definido esse modelo, a proposta é de estender o barramento de serviços para a utilização do protocolo OpenID Connect para prover autenticação e autorização.
O restante deste artigo está estruturado da seguinte forma: a Seção 2 apresenta uma arquitetura para a Web das Coisas; na Seção 3 é descrito o modelo de autenticação e autorização, a ser utilizado na arquitetura apresentada na Seção 2, proposto neste trabalho; a Seção 4 apresenta um exemplo de aplicação cliente que utiliza a arquitetura proposta e o modelo de autenticação e autorização proposto; e na Seção 5 são apresentadas algumas considerações finais e direções para trabalhos futuros.
2. Arquitetura para a Web das Coisas
Apesar de a Web prover protocolos padrões que, por meio de serviços, permitem a troca de informações utilizando padrões como o XML (extensible markup language) e JSON (JavaScript Object Notation), a grande variedade de coisas, que podem ser acessadas utilizando a Web das Coisas, possuem protocolos e formatos diferentes e muitas vezes proprietários [9]. Dessa forma, a Web das Coisas demanda uma infraestrutura capaz de gerenciar a publicação, descoberta, composição, utilização e compartilhamento desses dispositivos na Web [10]. Neste trabalho, um barramento de serviços (ESB - Enterprise
Service Bus [8]) foi utilizado como infraestrutura para publicação, descoberta, composição, monitoramento, utilização e compartilhamento para a Web das Coisas.
Barramentos de serviços podem prover diversas funcionalidades para a Web das Coisas: transparência de localização; conversão de protocolo de transporte; transformação de mensagem; roteamento de mensagem; enriquecimento de mensagens; dentre outras. O fato de barramentos de serviços proverem essas funcionalidades indica ser uma infraestrutura eficiente para a Web das Coisas. Alguns trabalhos [13][14][15] estendem um barramento de serviços com outras funcionalidades, que demonstram a viabilidade da utilização do mesmo para a Web das Coisas. Entretanto, nesses trabalhos, a publicação e o acesso aos dispositivos no barramento ainda é feita de maneira ad hoc. Dessa forma, este artigo apresenta uma arquitetura para a Web das Coisas, que define como a publicação, a descoberta, a composição, o monitoramento, a utilização e o compartilhamento estão sendo tratados neste trabalho.
Conforme apresentado na Figura 1, essa arquitetura pode ser dividida em 5 componentes maiores: Communication; Enterprise Service Bus; Security; Web of Things Applications; e Semantic Web Services. Esses componentes serão explicados nas seções seguintes.
Figura 1. Arquitetura de infraestrutura para a Web das Coisas.
2.1. Communication
Conforme pode ser visto na Figura 1 (parte 1), “Communication” é o componente responsável por prover a comunicação com os dispositivos na rede. Nesse componente, deve ser possível descobrir, de forma automática, que um novo dispositivo se registrou na rede e descobrir, também automaticamente, qual o serviço provido pelo dispositivo.
2.2. Enterprise Service Bus
Uma vez que o componente “Communication” informou ao barramento de serviços (Figura 1, parte 2) que existe um novo dispositivo na rede e ainda qual é esse dispositivo, o
barramento deve prover uma forma desse dispositivo ser acessado na Web das Coisas. Para alcançar esse objetivo, é proposto na arquitetura o uso de modelos de acesso, baseados no protocolo de comunicação utilizado pelo dispositivo, aos dispositivos “conhecidos” para serem associados automaticamente aos dispositivos descobertos na rede. Esses modelos são chamados, conforme pode ser visto na Figura 1 (parte 2), de “Data Access Objects” (DAO), pois são componentes da arquitetura proposta responsáveis por se comunicar diretamente com os dispositivos físicos na rede.
Também foram definidos modelos de serviços RESTFul (ver Figura 1, parte 2) que, em conjunto com os DAOs, vão possibilitar a disponibilização dos dispositivos na Web das Coisas. Note que os modelos de serviços RESTful devem ser independentes do dispositivo físico e dependentes das funcionalidades do dispositivo. Em outras palavras, os modelos de serviços RESTFul devem refletir as funcionalidades do dispositivo, enquanto que os DAOs refletem os protocolos de comunicação com cada dispositivo.
2.3. Web of Things Applications
O componente “Web of Things Applications”, apresentado na parte 4 da Figura 1, da arquitetura proposta, tem por objetivo propor modelos de visualização dos dispositivos e dos seus serviços oferecidos, na Web. Em outras palavras, são modelos que reflitam, visualmente na Web, a funcionalidade do dispositivo.
2.4. Semantic Web Services
Os Serviços Web Semânticos (Semantic Web Services) têm o objetivo de automatizar tarefas como descoberta, composição, execução e monitoramento de Serviços Web. Neste artigo o componente “Semantic Web Services” é apresentado na parte 4 da Figura 1. Com esse componente, pretende-se utilizar algoritmos e métodos [1][2][3][4][11][12], baseados na descrição semântica dos serviços, de descoberta e composição automáticas para estender o barramento de serviços com semântica.
2.5. Security
O componente “Security” pode ser implementado utilizando duas tecnologias/padrões distintos: SAML (Security Assertion Markup Language) e OpenID Connect. O modelo de autenticação e autorização proposto neste trabalho utiliza o OpenID Connect, que é uma camada de identidade no topo do protocolo OAuth 2.0. Dessa forma, a Seção 3 apresenta os detalhes do modelo de segurança a ser utilizado neste trabalho.
3. Autenticação e Autorização na Web das Coisas
Conforme detalhado na Seção 2, o acesso aos dispositivos no mundo real é realizado por meio de um serviço implantado no barramento de serviços. Cada serviço implantado no barramento pode pertencer a um usuário, ou a um grupo de usuários, e devem ser definidos como público ou privado. Serviços públicos são aqueles abertos a qualquer aplicação, que requisite acessá-lo, sem necessidade de autenticação e autorização. Os serviços pertencentes a um usuário ou grupo de usuários podem ser classificados como público ou privado pelo proprietário desses serviços. Portanto, para os serviços proprietários, o detentor deve ter o poder de autorizar ou recusar as requisições de acesso ao serviço.
Esta seção apresenta três casos de uso referentes à autenticação e autorização no acesso aos dispositivos disponibilizados no barramento: i) usuário requisitando serviços públicos; ii) usuário requisitando serviços relativos a dispositivos de sua propriedade; iii)
usuário requisitando serviços relativos a dispositivos de propriedade de terceiros. O objetivo desses casos de uso é de proteger os recursos presentes no barramento e, por consequência, os dispositivos do mundo real. A proteção aos recursos será feita através do gerenciamento de acesso utilizando protocolo de autenticação e autorização: OpenID Connect.
Aplicações clientes dos serviços do barramento, ao realizarem requisições, podem ser direcionadas para um de três fluxos distintos, cada um correspondendo a um dos três casos de uso. O barramento possui uma aplicação dedicada ao gerenciamento de acesso e redirecionamento das aplicações clientes ao fluxo correspondente.
Figura 2. Usuário requisitando acesso a dispositivos públicos.
A Figura 2 ilustra o primeiro caso, em que o serviço é público. A aplicação cliente faz uma requisição ao serviço presente no barramento (passo 1 da Figura 2), que é filtrada pela aplicação de gerenciamento de acesso. Essa aplicação verifica que o serviço requisitado é público (passo 2 da Figura 2) e então o acesso é liberado sem autenticação (passo 3 da Figura 2).
Figura 3. Usuário requisitando acesso a dispositivos de sua propriedade.
O segundo caso, é um caso tradicional de autenticação e autorização na Web atual, utilizando os protocolos de autenticação e autorização OpenID e OAuth. Nesse caso, conforme ilustrado na Figura 3, a requisição enviada pela aplicação (passo 1 da Figura 3) é
filtrada pela aplicação de gerenciamento de acesso no barramento. Caso o serviço tenha acesso restrito, o usuário é redirecionado (passo 2 da Figura 3) a uma página de autenticação em um provedor OpenID Connect, externo ao barramento, para efetuar a autenticação. Uma vez autenticado, o usuário deve autorizar que a aplicação cliente tenha acesso aos seus dispositivos. Confirmada a autorização, a aplicação recebe como resposta o token de acesso (passo 3 da Figura 3), que poderá ser utilizado durante um limite de tempo configurado pelo provedor. As novas requisições (passo 4 da Figura 3) serão realizadas passando o token adquirido até que expire, então será necessário recomeçar um novo processo de autorização, para renovação do token de acesso.
O terceiro, ilustrado na Figura 4, é o caso em que um usuário tenta acessar um dispositivo de propriedade de outro usuário. Nesse caso, o provedor OpenID Connect enviará uma notificação (passos 3 e 4 da Figura 4) de solicitação de acesso ao proprietário e esse fornecerá, ou não, autorização de acesso ao serviço.
Conforme pode ser visto na Figura 4, caso o proprietário confirme a autorização, a aplicação recebe como resposta o token de acesso (passo 5 da Figura 4), que poderá ser utilizado durante um limite de tempo configurado pelo provedor. As novas requisições então serão realizadas passando o token adquirido até que este expire (passo 6 da Figura 4), então será necessário recomeçar um novo processo de autorização, para renovação do token de acesso.
Figura 4. Usuário requisitando acesso a dispositivos de terceiros.
4. Aplicação Cliente do Barramento de Serviços
Para validar os fluxos de autenticação e autorização propostos na Seção 3, será utilizada uma aplicação Web cliente do barramento de serviços proposta por Andrade e Prazeres [15]. Essa aplicação, ilustrada na Figura 5, acessa o módulo de descoberta da arquitetura apresentada na Seção 2 (Figura 1), lista todos os dispositivos (ver Figura 5) existentes no barramento de serviços e permite o acesso aos dispositivos a partir de interfaces (HTML e JavaScript) geradas dinamicamente.
Conforme ilustrado na Figura 5, a aplicação cliente proposta por Andrade e Prazeres [15] não controla o acesso (autenticação e autorização) aos dispositivos. Neste artigo, a proposta é utilizar um provedor OpenID Connect para gerenciar: autenticação de usuários; autorização do acesso aos serviços no barramento. A seguir será apresentado um
protótipo de como uma aplicação cliente, tal como a apresentada na Figura 5, pode utilizar um dos fluxos de autenticação e autorização apresentados na Seção 3.
Figura 5. Aplicação cliente do barramento de serviços (obtida de [15]).
A Figura 6 exibe o resultado da descoberta dos dispositivos na aplicação cliente da Figura 5, estendida com as funcionalidades de autenticação e autorização. Note na Figura 6 que somente para o sensor de temperatura “temp_0” o acesso é público (primeiro caso da Seção 3). Para os casos segundo e terceiro descritos na Seção 3 (figuras 3 e 4), o usuário, ao tentar acessar um serviço por meio da aplicação cliente, como ilustrado na Figura 6, será redirecionado para uma tela de autenticação, tal como a apresentada na Figura 7.
Figura 6. Aplicação cliente com as funcionalidades de autenticação e autorização.
Figura 7. Autenticação no provedor OpenID Connect (obtida de [16]).
No segundo caso (Figura 3 da Seção 3), após a autenticação, o usuário deve autorizar que a aplicação cliente tenha acesso a alguns ou todos dos seus dispositivos. Conforme Figura 8, o usuário pode liberar acesso a apenas alguns dispositivos e barrar o acesso outros. Negar, ou permitir, o acesso a um dispositivo, nesse contexto, implica em adotar essa opção para todas as funções do dispositivo. Pode-se notar na Figura 8 que o usuário tem a opção de liberar apenas algumas funcionalidades e bloquear outras caso deseje. Ainda na Figura 8, ao clicar em “Authorize”, o usuário libera o acesso aos dispositivos “buzzer_6”, “lampRed_8” e “lumi_5”, e negaria o acesso ao dispositivo “lampWhite_7”.
Figura 8. Segundo caso: autorização de acesso a dispositivos (adaptada de [16]).
Dessa forma, a aplicação cliente teria acesso aos dispositivos liberados tal como o dispositivo “lampRed_8” exibido na Figura 9.
Figura 9. Aplicação cliente com acesso a recurso “lampRed_8” autorizado.
Após a autenticação do usuário e autorização de acesso aos seus dispositivos, a aplicação cliente é capaz de interagir com os dispositivos disponíveis . Dessa maneira, o fluxo para o caso em que o usuário autoriza o acesso aos seus dispositivos é concluído. Assim, o usuário poderá interagir com o dispositivo até que sua permissão seja revogada ou o tempo de acesso expire. A Figura 10 ilustra o modo como a ocorre interação na aplicação cliente utilizada neste artigo: o usuário pode enviar comandos para os dispositivos (autorizados) por meio dos métodos HTTP (GET e POST, por exemplo).
Figura 10. Acesso a um dispositivo autorizado no barramento de serviços.
O terceiro caso (Figura 4 na Seção 3) não é trivial na Web atual: o usuário requisita acesso a um dispositivo privado que não o pertence. Ao requisitar, por exemplo, acesso a “lampYellow_9”, o usuário deverá aguardar a autorização por parte do proprietário. O proprietário do dispositivo requisitado deverá receber um aviso, indicando que existe uma requisição de acesso a seu dispositivo. Assim, o proprietário do dispositivo será direcionado à página de autorização para permitir ou negar o acesso, tal como ilustrado na Figura 11.
Figura 11. Terceiro caso: autorização de acesso a dispositivos (adaptada de [16]).
Na aplicação cliente utilizada neste artigo a cada dispositivo que um usuário tenta acessar o fluxo de autenticação e autorização (terceiro caso) envia um aviso, ao proprietário do dispositivo, do pedido de autorização para acesso de um usuário a um dispositivo. Entretanto, a implementação proposta neste artigo prevê a autorização a um conjunto de dispositivos e também prevê a autorização para um grupo de usuários. Essa abordagem permite, por exemplo, utilizar modelos baseados em redes sociais, em que um grupo de usuários recebe autorização de acesso a um conjunto de recursos.
5. Considerações Finais
Este artigo apresenta uma arquitetura para a Web das Coisas e uma proposta para autenticação de usuário e autorização para acesso aos dispositivos na arquitetura apresentada.
Como validação da proposta é apresentada uma aplicação cliente que, ao tentar acessar um dispositivo provido pelo barramento de serviços, é redirecionada para o protótipo de autenticação de usuário e de autorização para acesso a dispositivos proposto neste trabalho.
Para trabalhos futuros, pretende-se desenvolver o protótipo apresentado, bem como validar e avaliar a solução proposta. Também será implementado, validado e avaliado, o caso em que um usuário autoriza outros usuários (ou grupo de usuários) a terem acesso a um conjunto de seus dispositivos.
Referências
[1] Prazeres, C.V.S., Teixeira, C.A.C.; Munson, E. V.; Pimentel, M. G. C. Toward Semantic Web Services as MVC Applications: from OWL-S via UML. Journal of Web Engineering, v. 9, p. 243-265, 2010.
[2] Prazeres, C.V.S., Teixeira, C.A.C., Pimentel, M.G.C.: Semantic web services discovery and composition: Paths along workflows. In: Proceedings of the 2009 Seventh IEEE European Conference on Web Services. ECOWS '09, Washington, DC, USA, IEEE Computer Society (2009) 58-65
[3] Prazeres, C. V. S. ; Pimentel, M. G. C. iSWS: infraestrutura para publicação, descoberta e composição de Serviços Web Semânticos. In: WebMedia: XVII Simpósio Brasileiro de Sistemas Multimídia e Web, 2011, Florianópolis - SC. XVII Simpósio Brasileiro de Sistemas Multimídia e Web, 2011. p. 66-73.
[4] Prazeres, C. V. S. ; Pimentel, M. G. C. ; Teixeira, C. A. C. . Semantic Web Services Discovery by Matching Temporal Restrictions. In: SAINT, 2008, Turku, Finland. Proceedings of the 8th IEEE/IPSJ International Symposium on Applications and the Internet, 2008. p. 26-32.
[5] Beckel, C., Kleiminger, W., Staake, T., Santini, S., Improving Device-level Electricity Consumption Breakdowns in Private Households Using ON/OFF Events, Proceedings of the 3rd Workshop on Networks of Cooperating Objects (CONET) in conjunction with CPS Week, Beijing, China, April 2012.
[6] Tasic, V., Staake, T., Stiefmeier, T., Tiefenbeck, V., Fleisch, E., Tröster, G., Self-powered Water Meter for Direct Feedback, Internet of Things 2012 – Third International Conference on the Internet of Things (IoT 2012), Wuxi, P.R. China, October 2012.
[7] Weiss, M., Staake, T., Mattern, F., Leveraging smart meter data to recognize home appliances, IEEE Pervasive Computing and Communication (PerCom), Lugano, Switzerland, March 2012
[8] Chappell, D. A. Enterprise Service Bus. 1. ed. : O'Reilly Media, 2004. 245p.
[9] Guinard, D. A Web of Things Application Architecture - Integrating the Real-World into the Web. 2011. 245f. Tese (Doutorado em Computer Science) - University of Fribourg, ETH Zurich, 2011.
[10] Guinard, D.; Trifa, V.; Wilde, E., "A resource oriented architecture for the Web of Things," Internet of Things (IOT), 2010 , vol., no., pp.1,8, Nov. 29 2010-Dec. 1 2010 [11] Siming Yang; Yang Xu; Qingyi He, "Ontology Based Service Discovery Method for
Internet of Things," Internet of Things (iThings/CPSCom), 2011 International Conference on and 4th International Conference on Cyber, Physical and Social Computing , vol., no., pp.43,47, 19-22 Oct. 2011
[12] Mathew, S.S.; Atif, Y.; Sheng, Q.Z.; Maamar, Z., "Web of Things: Description, Discovery and Integration," Internet of Things (iThings/CPSCom), 2011 International Conference on and 4th International Conference on Cyber, Physical and Social Computing , vol., no., pp.9,15, 19-22 Oct. 2011
[13] Gramacho, S.; Prazeres, C. V. S.; Figueiredo, G. B. An Ad-Hoc Web of Things Service Bus. In: XIX Simpósio Brasileiro de Sistemas Multimídia e Hipermídia, 2013, Salvador. Anais do WebMedia 2013. Porto Alegre: SBC, 2013.
[14] Silva, C.; Prazeres, C. Barramento de serviços para publicação de dispositivos na Web das Coisas. 2013. Workshop de Trabalhos de Iniciação Científica do WebMedia 2013.
[15] Andrade Júnior, N.; Prazeres, C. V. S. Extensão de um barramento de serviços para descoberta e acesso a dispositivos na Web das Coisas. 2013. 67f. Monografia (Graduação em Ciência da Computação) – Universidade Federal da Bahia, UFBA, Salvador, 2013. [16] Gidlab (Laboratório de Experimentação em Gestão de Identidade). Aplicação exemplo de
cliente para provedor OpenID Connect. Visitado em 13/09/2013.
http://wiki.rnp.br/display/gidlab/
