uma infraestrutura de autenticação e de autorização para a ...siaibib01.univali.br/pdf/marlon...
TRANSCRIPT
MARLON CORDEIRO DOMENECH
UMA INFRAESTRUTURA DE AUTENTICACAO E DEAUTORIZACAO PARA A WEB DAS COISAS
Itajaı (SC), Fevereiro de 2015
UNIVERSIDADE DO VALE DO ITAJAI
CURSO DE MESTRADO ACADEMICO EM
COMPUTACAO APLICADA
UMA INFRAESTRUTURA DE AUTENTICACAO E DEAUTORIZACAO PARA A WEB DAS COISAS
por
Marlon Cordeiro Domenech
Dissertacao apresentada como requisito parcial aobtencao do grau de Mestre em Computacao Apli-cada.Orientador: Michelle Silva Wangham, Dra.
Itajaı (SC), Fevereiro de 2015
Marlon Cordeiro Domenech
Uma Infraestrutura de autenticação e de autorização para a Web dasCoisas
Dissertação apresentada como requisito parcial àobtenção do grau de Mestre em Computação Apli-cada.
Trabalho aprovado. Itajaí (SC), 27 de Fevereiro de 2015:
Profa. Michelle Silva Wangham, Dra.(UNIVALI)Orientadora
Prof. Cesar Albenes Zeferino, Dr.(UNIVALI)
Membro
Prof. Eros Comunello, Dr. rer. nat.(UNIVALI)
Membro
Prof. Emerson Ribeiro de Mello, Dr. (IFSC)Membro
Itajaí (SC)
Fevereiro de 2015
AGRADECIMENTOS
Agradeço aos meus pais, Inez e Gerson, por terem me apoiado durante toda a minha vida e deuma maneira ainda mais notável durante a realização deste trabalho. Tenham a certeza de que meuamor por vocês só aumentou durante este período.
Do mesmo modo, agradeço ao meu irmão, Matheus, por ter feito com que eu recordasse,diversas vezes, que a família é muito importante, muito mais do que este trabalho. Obrigado pela forçaque você teve e que transmitiu para mim nas mais diversas oportunidades.
À minha noiva e futura esposa, sempre companheira, Suelen, agradeço pela parceria, amizadee amor incondicionais durante todo esse tempo que passamos um pouco mais distantes um do outro.Sem você, os dias teriam sido sempre cinzentos e este trabalho teria sido muito mais árduo. Obrigadopelo apoio.
Aos meus sogros, Eldo e Sirlei, agradeço por tudo que fizeram por mim neste período. Tenhamcerteza de que serei eternamente grato pelo apoio que me deram nesta empreitada.
À minha orientadora e amiga Michelle, agradeço por ter ajudado a formar meu caráter comopesquisador e como ser humano. Sem sua colaboração, este resultado, e muitos outros, não teriam sidoalcançados. Tenha certeza que serei sempre grato por você ter superado as expectativas que eu tinhapara um orientador. Sempre terei você em conta.
Ao meu amigo Eros, agradeço por ter me proporcionado uma das experiências mais desafiadorasda minha vida ao apresentar a oportunidade de cursar o Mestrado. Obrigado também por ter ajudado ame formar como pesquisador e como pessoa.
Aos meus amigos de laboratório, Marcelo, Leonardo e Maykon, agradeço primeiro pela amizadee depois pelas produtivas conversas e intercâmbio de ideias. A colaboração técnico-científica de vocêsfoi essencial para que os resultados deste trabalho fossem alcançados. Minha consideração por vocês éindescritível.
Também agradeço aos meus amigos Paulo e Gabriel, pela colaboração que tiveram nestetrabalho. O trabalho de vocês colaborou muito para estes resultados.
Por fim, serei sempre grato a Carlos Bernardo González Pecotche. Seus ensinamentos foramimprescindíveis para que este trabalho viesse a ser concluído e para que a vida não se limitasse apenasa este labor.
UMA INFRAESTRUTURA DE AUTENTICACAO E DEAUTORIZACAO PARA A WEB DAS COISAS
Marlon Cordeiro Domenech
Fevereiro / 2015
Orientadora: Michelle Silva Wangham, Dra.
Área de Concentração: Computação Aplicada
Linha de Pesquisa: Sistemas Embarcados e Distribuídos
Palavras-chave: Internet das Coisas, Autenticação, Autorização.
Número de páginas: 164
RESUMO
A Internet das Coisas consiste na presença de uma diversidade de coisas (objetos) que inte-ragem e cooperam entre si a fim de atingir um objetivo comum, por exemplo, o compartilhamentode informações. Diversas características diferenciam a Internet das Coisas dos demais ambientescomputacionais, como a grande heterogeneidade de tecnologias e as restrições de recursos computaci-onais. Uma abordagem para tratar desta heterogeneidade é utilizar a Web como plataforma, conceitoconhecido como Web das Coisas. A característica distribuída e a heterogeneidade da Web das Coisas(WoT) levam à necessidade de autenticação em ambientes colaborativos, compostos por diferentesdomínios administrativos de segurança, bem como garantir que apenas entidades autorizadas acessemos recursos protegidos. O objetivo deste trabalho é prover autenticação e autorização de usuáriose de dispositivos na Web das Coisas diante de domínios de segurança diferentes, por meio de umainfraestrutura de autenticação e de autorização, chamada AAI4WoT. A AAI4WoT é capaz de prover aautenticação única de dispositivos e de usuários por meio de diferentes mecanismos de autenticação,além de permitir o uso de diferentes modelos de controle de acesso. A AAI4WoT foi projetada e éadequada para aplicações que envolvem a comunicação M2M (Machine to Machine). O trabalho en-volveu (1) a definição e implementação de uma infraestrutura de autenticação e de autorização baseadanos padrões SAML e XACML (AAI4WoT) e (2) a avaliação dos impactos do uso da AAI4WoT emuma aplicação de Web das Coisas para controle e monitoramento remoto de máquinas industriaisinteligentes. As métricas utilizadas na avaliação foram o consumo de potência elétrica, espaço dememória RAM e flash, uso de CPU, tempo de processamento, tamanho das mensagens e vazão da rede.Os resultados obtidos mostram que (1) é possível ter a autenticação única de dispositivos e de usuáriosem uma mesma infraestrutura diante de diferentes mecanismos de autenticação; (2) é possível proverflexibilidade de modelo de controle de acesso para as aplicações de WoT; e (3) que usar a AAI4WoT
demanda o uso de mais recursos computacionais dos dispositivos.
AN AUTHENTICATION AND AUTHORIZATIONINFRASTRUCTURE FOR THE WEB OF THINGS
Marlon Cordeiro Domenech
February / 2015
Advisor: Michelle Silva Wangham, Dra.
Area of Concentration: Applied Computer Science
Research Line: Embedded and Distributed Systems
Keywords: Internet of Things, Authentication, Authorization.
Number of pages: 164
ABSTRACT
The basic idea of the Internet of Things consists in the presence of a diversity of things (objects)that interact and cooperate to achieve a common goal, for example, sharing of information. The Internetof Things has many characteristics that differentiate it from other computational environments, such asthe great heterogeneity of technologies and restriction of computational resources. An approach to theheterogeneity of the Internet of Things is to use the Web as a platform, a concept known as Web ofThings. Distributed characteristic and heterogeneity of the Web of Things (WoT) leads to the needof authentication in collaborative environments, which are composed by differents security domains,and also to guarantee that only authorized entities can access protected resources. The objective ofthis work is to provide authentication and authorization of users and devices on the Web of Thingsfacing different security domains, through an authentication and authorization infrastructure, calledAAI4WoT. AAI4WoT enables device and user Single Sign-On (SSO) through different authenticationmechanisms, as well as the use of different access control models. AAI4WoT was designed and issuitable for applications involving Machine-to-Machine (M2M) communication. The work involved(1) definition and implementation of an authentication and authorization infrastructure based on SAMLand XACML standards (AAI4WoT), and (2) evaluation of impacts of using AAI4WoT on an Web ofThings application for remote monitoring and control of smart industrial machines. Metrics used wereelectric power consumption, RAM and flash usage, CPU usage, processing time, message size andnetwork throughput. Results show that (1) SSO for users and devices in the same infrastructure facingdifferent authentication mechanisms can be achieved; (2) flexibility of access control model can beprovided for WoT applications; and (3) using AAI4WoT requires more computational resources ofdevices.
LISTA DE ILUSTRACOES
Figura 1. Controle de Acesso ................................................................................... 45Figura 2. Modelo de Fluxo de dados do XACML ......................................................... 51Figura 3. Arquitetura do Hydra Identity Manager ......................................................... 56Figura 4. Arquitetura da IoT e passo-a-passo do protocolo de autenticação ........................ 58Figura 5. Arquitetura de autorização proposta em Seitz, Selander e Gehrmann (2013) .......... 61Figura 6. Cenário do Problema de Pesquisa ................................................................. 68Figura 7. Visão Geral da AAI4WoT - Cenário M2M ..................................................... 70Figura 8. Componentes da AAI4WoT ........................................................................ 72Figura 9. Etapa de Registro do Dispositivo SP ............................................................. 76Figura 10. AAI4WoT - Modo de Operação SP Restrito ................................................... 78Figura 11. Fluxo de mensagens de autorização no modo de operação SP Restrito.................. 80Figura 12. AAI4WoT - Modo de Operação SP Sem Restrições ......................................... 81Figura 13. Etapas e trocas de mensagens do mecanismo de autenticação de dispositivos ......... 83Figura 14. Telas de cadastro da aplicação de registro do IdP ............................................. 90Figura 15. Árvore do diretório de identidades do IdP ...................................................... 91Figura 16. Fluxo de mensagens do cenário de autenticação de dispositivos - parte 1 .............. 92Figura 17. Fluxo de mensagens do cenário de autenticação de dispositivos - parte 2 .............. 93Figura 18. Fluxo de mensagens de autenticação única do cenário de autenticação de dispositivos 97Figura 19. Aplicação de WoT para monitoramento e controle remoto de máquinas industriais . 99Figura 20. Simulador do Sistema SCADA - SIMSCADA................................................. 100Figura 21. Aplicação Cliente Desktop ......................................................................... 101Figura 22. Tela da aplicação Cliente Desktop integrada à AAI4WoT .................................. 103Figura 23. Experimento de Vazão da Rede - BeagleBone Black atua como SP...................... 128Figura 24. Experimento de Vazão da Rede - Aplicação na Nuvem atua como SP................... 130Figura 25. XSD para o contexto de autenticação utilizado nos experimentos - Parte 1 ............ 154Figura 26. XSD para o contexto de autenticação utilizado nos experimentos - Parte 2 ............ 155Figura 27. XSD para o contexto de autenticação utilizado nos experimentos - Parte 3 ............ 157Figura 28. XSD para o contexto de autenticação utilizado nos experimentos - Parte 4 ............ 158Figura 29. Diagrama de Sequência do Cliente Ativo SAML quando o cliente não possui uma
asserção SAML........................................................................................ 163Figura 30. Diagrama de Sequência da tomada de decisão de autorização ............................. 164
LISTA DE TABELAS
Tabela 1. Comparação dos Trabalhos Relacionados....................................................... 63Tabela 2. Footprint - Dados do Cliente ....................................................................... 108Tabela 3. Footprint - Dados do SP............................................................................. 109Tabela 4. Footprint - Dados de Consumo de Potência do Cliente...................................... 110Tabela 5. Footprint - Dados de Consumo de Potência do SP ........................................... 111Tabela 6. Montagem da Requisição de Autenticação SAML - Dados do Cliente com a AAI... 112Tabela 7. Tempo de processamento da Montagem da Requisição de Autenticação SAML
sem carregamento do OpenSAML - com a AAI .............................................. 113Tabela 8. Solicitação de Autenticação Sem Autenticação Única - com a AAI...................... 114Tabela 9. Solicitação de Autenticação Com Autenticação Única - com a AAI ..................... 114Tabela 10. Solicitação de Autenticação com e sem Autenticação Única - Tamanho das Mensa-
gens - com a AAI ..................................................................................... 115Tabela 11. Solicitação de Autenticação com e sem Autenticação Única - Tempo de Processa-
mento - com a AAI ................................................................................... 116Tabela 12. Participação dos subprocessos no processo de obtenção de uma asserção SAML -
com a AAI .............................................................................................. 117Tabela 13. Processo de Autenticação Completo com e sem Autenticação Única - com a AAI... 117Tabela 14. Processo de Autenticação Completo com e sem Autenticação Única - Uso de CPU
- com a AAI............................................................................................. 118Tabela 15. Processo de Autenticação Completo com e sem Autenticação Única - Consumo de
Potência - com a AAI ................................................................................ 119Tabela 16. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Memória RAM,
Flash/Disco e Tempo de Processamento......................................................... 120Tabela 17. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Tempo de Proces-
samento corrigido ..................................................................................... 121Tabela 18. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Tamanho das
Mensagens .............................................................................................. 121Tabela 19. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Consumo de Potência122Tabela 20. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Uso de CPU......... 123Tabela 21. Solicitação ao SP com e sem a AAI4WOT - Dados do SP ................................. 124Tabela 22. Solicitação ao SP com a AAI4WOT - Dados do SP - Tamanho das Mensagens ...... 124Tabela 23. Solicitação ao SP com e sem a AAI4WOT - Dados do SP - Uso de CPU .............. 125Tabela 24. Solicitação ao SP com e sem a AAI4WOT - Cenário Cliente Embarcado - Dados
do SP ..................................................................................................... 125Tabela 25. Solicitação ao SP com a AAI4WOT - Dados do PDP ....................................... 126Tabela 26. Processo Completo com e sem a AAI4WOT - com e sem Autenticação Única -
Dados do Cliente ...................................................................................... 127Tabela 27. Resultados da Revisão Sistemática da Literatura.............................................. 148
LISTA DE ABREVIATURAS E SIGLAS
6LoWPAN IPv6 over Low Power Wireless Personal Area Networks
ABAC Attribute Based Access Control
AC Autoridade Certificadora
ACL Access Control List
ACM Access Control Mechanism
AES Advanced Encryption Standard
API Application Programming Interface
AS Authorized Server
BPEL Business Process Execution Language
DAC Discretionary Access Control
DoS Denial of Service
DTLS Datagram Transport Layer Security
EAP Extensible Authentication Protocol
ECC Elliptic Curve Cryptography
ECCDH ECC Diffie-Hellman
ECP Enhanced Client or Proxy
EnHANTs Energy-Harvesting Active Networked Tags
GID Gestão de Identidades Digitais
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
IAA Infraestrutura de Autenticação e Autorização
IdM Identity Management
IdP Identity Provider
IoT Internet of Things
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
JSON JavaScript Object Notation
KDC Key Distribution Center
LDAP Lightweight Directory Access Protocol
M2M Machine to Machine
MAC Mandatory Access Control
MITM Man-In-The-Middle
NFC Near-Field Communication
PAP Policy Administration Point
PBAC Policy-Based Access Control
PDP Policy Decision Point
PEP Policy Enforcement Point
PIP Policy Information Point
RAM Random Access Memory
RBAC Role Based Access Control
REST REpresentational State Transfer
RFID Radio-Frequency IDentification
ROA Resource Oriented Architecture
ROM Read-only Memory
RSN RFID Sensor Network
RSSF Redes de Sensores Sem Fio
SGML Standard Generalized Markup Language
SAML Security Assertion Markup Language
SP Service Provider
SSO Single Sign-On
TLS Transport Layer Security
TPM Trusted Platform Module
UDDI Universal Description, Discovery and Integration
URI Uniform Resource Identifier
URL Uniform Resource Locator
WoT Web of Things
WABAC Workflow-oriented Attributed Based Access Control
WSAN Wireless Sensor and Actuator Network
WSDL Web Services Description Language
WSN Wireless Sensor Network
XML eXtensible Markup Language
XACML eXtensible Access Control Markup Language
SUMARIO
1 INTRODUÇÃO ................................................................................151.1 Problema de Pesquisa ...........................................................................171.1.1 Solução Proposta ....................................................................................... 201.1.2 Delimitação de Escopo................................................................................ 221.1.3 Justificativa .............................................................................................. 221.2 Objetivos............................................................................................... 241.2.1 Objetivo Geral .......................................................................................... 241.2.2 Objetivos Específicos .................................................................................. 241.3 Metodologia .......................................................................................... 251.3.1 Metodologia da Pesquisa ............................................................................ 251.3.2 Procedimentos Metodológicos ..................................................................... 261.4 Estrutura da Dissertação ......................................................................27
2 FUNDAMENTAÇÃO TEÓRICA ................................................292.1 Internet das Coisas ............................................................................... 292.1.1 Web das Coisas ......................................................................................... 312.2 Segurança na Internet das Coisas ........................................................ 342.2.1 Requisitos de Segurança ............................................................................. 352.2.2 Ameaças e Ataques .................................................................................... 372.2.3 Gestão de Identidades Digitais na Internet das Coisas ..................................... 392.2.4 Especificações de Segurança para XML e Serviços Web .................................. 472.3 Considerações....................................................................................... 53
3 TRABALHOS RELACIONADOS ..............................................553.1 Akram e Hoffmann (2008c) ................................................................. 553.2 Alam, Chowdhury e Noll (2011) .......................................................... 563.3 Conzon et al. (2012) ...............................................................................573.4 Liu, Xiao e Chen (2012) ....................................................................... 583.5 Gardel et al. (2013) ............................................................................... 593.6 Seitz, Selander e Gehrmann (2013) ..................................................... 603.7 Comparação dos Trabalhos Relacionados ........................................... 623.8 Considerações....................................................................................... 65
4 INFRAESTRUTURA DE AUTENTICAÇÃO E DE AU-TORIZAÇÃO PARA A WEB DAS COISAS - AAI4WOT ....66
4.1 Cenário Envolvido e Premissas .............................................................674.2 Visão Geral da AAI4WoT .................................................................... 694.3 Componentes e Funcionalidades da AAI4WoT ....................................714.4 Etapa de Registros e de Estabelecimento de Relações de Confiança .. 73
4.5 Modos de Operação da AAI4WoT ........................................................774.5.1 Modo de Operação SP Restrito .................................................................... 774.5.2 Modo de Operação SP Sem Restrições .......................................................... 804.6 Cliente Ativo SAML ............................................................................. 804.7 Uso de Mecanismos de Autenticação da IoT com o SAML ................. 824.8 Modelo de Ameaças ............................................................................. 844.9 Desenvolvimento....................................................................................874.9.1 Ferramentas Tecnológicas Utilizadas ............................................................ 874.9.2 Implementação do Protótipo da AAI4WoT.................................................... 894.9.3 Aplicação de Monitoramento e Controle de Máquinas Industriais .................... 984.9.4 Integração da Infraestrutura de Autenticação e de Autorização para a Web
das Coisas............................................................................................... 1024.10 Considerações do Capítulo .................................................................104
5 RESULTADOS E AVALIAÇÃO .................................................1065.1 Experimentos ......................................................................................1065.2 Resultados ...........................................................................................1075.2.1 Experimento de Footprint ......................................................................... 1075.2.2 Experimento de Solicitação de Autenticação .................................................1115.2.3 Experimento de Solicitação de Serviço ao SP ............................................... 1205.2.4 Experimento do Processo Completo ........................................................... 1265.2.5 Experimento de Vazão da Rede ................................................................. 1285.3 Comparação com os Trabalhos Relacionados ....................................130
6 CONCLUSÃO ................................................................................1326.1 Contribuição da Dissertação ...............................................................1346.2 Trabalhos Futuros ...............................................................................134
Referências ............................................................................................136APÊNDICE A – PROTOCOLO DE BUSCA E RESULTADOS
DA REVISÃO SISTEMÁTICA DA LITERA-TURA .......................................................................144
APÊNDICE B – POLÍTICA DE CONTROLE DE ACESSOUTILIZADA NOS EXPERIMENTOS ............149
APÊNDICE C – AUTENTICATION CONTEXT CLASS PARAO MECANISMO DE AUTENTICAÇÃO UTI-LIZADO NOS EXPERIMENTOS ...................154
APÊNDICE D – MODELAGEM DO PROTÓTIPO ...................159
15
1 INTRODUÇÃO
Em 2010, havia aproximadamente um bilhão e meio de computadores pessoais e mais de um
bilhão de celulares com acesso à Internet. Para 2020, é esperado que algo entre cinquenta e cem bilhões
de dispositivos estarão conectados à Internet (CERP-IOT, 2010). O próximo salto no crescimento da
Internet será a ampla integração dos objetos físicos do dia a dia (“coisas”), conectados em redes (ITU,
2005; COUNCIL, 2008). O paradigma da Internet das Coisas (Internet of Things – IoT) abrange uma
infraestrutura de hardware, software e serviços que conectam objetos físicos à rede de computadores
(COMMUNITIES, 2008). Babar et al. (2011) afirmam que nesse cenário estão coisas como roupas,
mobília, carros, smartcards, dispositivos médicos e máquinas industriais.
Segundo Atzori, Iera e Morabito (2010), a ideia básica da IoT consiste na presença de uma
diversidade de coisas (objetos) que interagem e cooperam entre si afim de atingir um objetivo comum
(p.e. o compartilhamento de informações), utilizando métodos de endereçamento único e protocolos
de comunicação padronizados. O paradigma de IoT integra uma grande variedade de conceitos e áreas,
tais como: eletrônica, automação, redes de comunicação, biotecnologia, mecânica e tecnologia dos
materiais (XIANG; LI, 2012).
Os avanços e a convergência das tecnologias de sistemas microeletromecânicos, comunicação
sem fio e eletrônica digital resultaram no desenvolvimento de dispositivos em miniatura capazes de
sensoriar, computar e se comunicar via rede sem fio a curtas distâncias. Deste cenário, deriva o conceito
de ambientes inteligentes (smart environments). A integração entre sensores-atuadores-Internet forma
a base tecnológica para o conceito de ambientes inteligentes, nos quais a informação gerada pode ser
compartilhada entre diversas plataformas e aplicações, permitindo o controle de determinadas coisas
(dispositivos) (GUBBI et al., 2013).
A IoT apresenta diversas características que a diferenciam dos demais ambientes computa-
cionais. Conforme Mahalle et al. (2012), Atzori, Iera e Morabito (2010) e Hummen et al. (2013),
os principais fatores que tornam desafiadora a integração dos objetos (coisas) com a Internet são as
restrições de recursos computacionais, conectividade, fontes de energia, segurança, fatores geográficos
e custo de instalação e operação.
Em função destas restrições, alguns dispositivos não suportam a conectividade direta com a
Internet, via protocolo IP. Neste caso, é possível utilizar um dispositivo intermediário entre a Internet e
16
o objeto, chamado de Smart Gateway. Esse dispositivo fornece uma interface de comunicação dos
objetos com sistemas finais na Internet e vice-versa. Isso permite que tais sistemas, que podem ser
outros objetos, se comuniquem com os objetos através desse Smart Gateway, sendo que este recebe
as mensagens vindas da Internet e repassa ao objeto por meio de sua API (Application Programming
Interface) de comunicação específica e vice-versa (TRIFA et al., 2009; MAHALLE et al., 2010).
Segundo Zeng, Guo e Cheng (2011), há uma tendência nas pesquisas atuais em tratar a IoT como
Web das Coisas (Web of Things – WoT), na qual os padrões abertos da Web são empregados para prover
o compartilhamento de informação e a interoperabilidade entre dispositivos. A interoperabilidade é
particularmente essencial para concepção de sistemas com dispositivos heterogêneos produzidos por
diferentes fabricantes. Na WoT, a integração dos dispositivos ocorre no nível de aplicação, acima da
conectividade de rede (ZENG; GUO; CHENG, 2011; GUINARD et al., 2011).
Uma possível abordagem para implementar o conceito de WoT é o estilo arquitetural REST
(REpresentational State Transfer). Esse estilo arquitetural pode ser empregado para desenvolver
sistemas que seguem uma arquitetura orientada a recursos (Resource Oriented Architecture – ROA).
O REST define um conjunto de princípios que, ao serem adotados, dão origem a sistemas RESTful
(GUINARD; TRIFA, 2009).
As questões mais desafiadoras na IoT são os aspectos de segurança, que requerem abordagens
diferenciadas em relação às abordagens adotadas nos ambientes computacionais tradicionais. Uma
forma de atender aos requisitos de segurança da IoT é por meio de uma infraestrutura de autenticação e
de autorização (Authentication and Authorization Infrastructure – AAI). Esta infraestrutura é conhecida
como o elemento central para prover a segurança e lidar com problemas de segurança em aplicações
distribuídas. Com esta infraestrutura, é possível implantar a gestão de identidades de forma a impedir
que usuários ou objetos não autorizados tenham acesso aos recursos, impedir que usuários ou objetos
legítimos acessem recursos que estes não estão autorizados e permitir que os usuários ou objetos
legítimos tenham acesso aos recursos a estes autorizados (LIU; XIAO; CHEN, 2012).
A gestão de identidades (Identity Management - IdM) pode ser entendida como o conjunto de
processos e tecnologias usados para garantir a identidade de uma entidade ou de um objeto, garantir a
qualidade das informações de uma identidade (identificadores, credenciais e atributos) e para prover
procedimentos de autenticação, autorização, contabilização e auditoria (ITU, 2009).
Uma das maneiras de prover a IdM em um ambiente com diferentes domínios de segurança é
utilizando um sistema baseado no modelo de gestão de identidades federadas (BHARGAV-SPANTZEL
17
et al., 2007). Este modelo se baseia no conceito de federação, descrito por Chadwick (2009) como
uma associação entre diversos provedores (de serviço e de identidades) que estabelecem entre si um
nível de confiança suficiente para permitir a troca de mensagens entre estes. Neste modelo, há mais de
um domínio administrativo de segurança participando da federação e o acordo de confiança existente
garante que usuários possam se autenticar em seu domínio de segurança e usar dessa autenticação
para acessar recursos protegidos, disponibilizados por entidades em outros domínios da federação
(BHARGAV-SPANTZEL et al., 2007). Se o mesmo evento de autenticação puder ser utilizado para
acesso a diversos serviços da federação, tem-se a autenticação única (Single Sign-On – SSO).
No contexto de gestão de identidades federadas, destaca-se o conjunto de especificações SAML
(Security Assertion Markup Language), que é um padrão baseado em XML (eXtensible Markup
Language) para a descrição e troca de asserções de segurança entre parceiros de negócio na Internet. O
SAML define regras para trocas de mensagens e a sintaxe destas permitindo, dentre outras coisas, a
autenticação única entre múltiplos domínios de segurança. O SAML tem suporte a diversos mecanismos
para gestão de identidades federadas, sendo uma das principais tecnologias para abordar o problema
(OASIS, 2008). Já no quesito de autorização, um padrão reconhecido é o XACML (eXtensible Access
Control Markup Language), que é uma linguagem também baseada em XML para a descrição de
políticas de autorização e para requisição/resposta de decisões de controle de acesso (OASIS, 2003).
Neste contexto, o presente trabalho visa contribuir na área de gestão de identidades para Internet
das Coisas.
1.1 PROBLEMA DE PESQUISA
Em Babar et al. (2011), algumas questões são levantadas em relação à segurança na IoT,
denotando a diferença em relação à segurança fora do ambiente de IoT:
• Segurança naturalmente consome recursos e, assim, acrescentar mecanismos de segurança
em dispositivos embarcados com restrições computacionais pode ser um desafio. Além disso,
o tempo de duração da bateria está ligado ao número de computações feitas, portanto, quanto
mais computação, menor a carga da bateria e menor a autonomia do sistema (restrições
de energia). Limitações em termos de armazenamento também podem ser obstáculos para
garantir requisitos de segurança nesses dispositivos;
• Criptografia é uma solução cara para dispositivos com restrições. Logo, em algumas si-
18
tuações, o uso de algoritmos criptográficos leves, otimizados para esse cenário, se faz
necessário;
• O acesso físico aos dispositivos é facilitado, em função do tipo de ambiente nos quais os
objetos estão inseridos. Assim, são necessárias as proteções lógica e física destes; e
• Diante da heterogeneidade dos dispositivos, desenvolver mecanismos de segurança que
possam ser executados em diferentes plataformas é um requisito importante.
A IoT é composta de dispositivos heterogêneos, que precisam provar a sua autenticidade
para as entidades com as quais se comunicam. Esses dispositivos estão localizados em domínios
administrativos de segurança que podem ser compostos de diferentes dispositivos e de diferentes
tecnologias de comunicação, bem como podem prover diferentes mecanismos para que tais dispositivos
provem a sua autenticidade. É possível que o cliente, seja ele um usuário ou um dispositivo, deseje
acessar um recurso que é disponibilizado em um domínio administrativo de segurança diferente do
seu, como descrito em Gusmeroli, Piccione e Rotondi (2013), Gardel et al. (2013), Liu, Xiao e Chen
(2012), Conzon et al. (2012) e Akram e Hoffmann (2008b). Conforme Wangham, Domenech e Mello
(2013), os dispositivos da IoT podem utilizar mecanismos de autenticação que são diferentes daqueles
utilizados por usuários humanos. Um problema neste cenário é garantir a autenticidade de dispositivos
e de usuários que se comunicam entre si e que estão em domínios administrativos de segurança
diferentes, bem como utilizam mecanismos de autenticação distintos.
Apesar da gestão de identidades federadas de usuários ser bem abordada na literatura, a gestão
de identidades federadas de dispositivos não é bem caracterizada e, segundo Miorandi et al. (2012),
é um desafio de pesquisa neste cenário. A autenticação de objetos e de usuários em uma mesma
infraestrutura que usa o modelo de gestão de identidades federadas na IoT não é tratada na literatura.
A autenticação de objetos e de usuários em uma mesma infraestrutura que usa o modelo centralizado é
abordada em Nguyen, Al-Saffar e Huh (2010) e Hanumanthappa e Singh (2012). Gusmeroli, Piccione
e Rotondi (2013) descrevem uma infraestrutura que segue o modelo tradicional.
Diante desse cenário, é preciso que diferentes mecanismos de autenticação (para usuários e
para dispositivos) possam ser utilizados na infraestrutura, de modo a garantir a capacidade destes
de provarem a sua identidade para as mais variadas entidades com as quais forem se comunicar. A
possibilidade de uso de diferentes mecanismos de autenticação na IoT foi abordada em Akram e
Hoffmann (2008b) e Conzon et al. (2012), contudo considerando apenas mecanismos para autenticar
usuários e não dispositivos.
19
A autenticação única (Single Sign On -SSO) de usuários em ambientes federados é tratada
na literatura por várias soluções, tais como o Liberty Alliance, OpenID e Windows CardSpace
(WANGHAM et al., 2010). As soluções de IdM com foco na IoT que abordam ambientes federados não
apresentam soluções para a autenticação única de dispositivos (LIU; XIAO; CHEN, 2012; AKRAM;
HOFFMANN, 2008b; GARDEL et al., 2013). Estas soluções abordam a autenticação única, contudo
apenas para usuários.
A especificação SAML permite o uso de diversos mecanismos de autenticação de usuários e
de dispositivos, gerando ao final uma asserção SAML sobre o evento de autenticação. Além disso, a
especificação provê pontos de extensão que permitem que outros mecanismos de autenticação sejam
tolerados, conforme a necessidade do ambiente (OASIS, 2005a).
A especificação SAML (OASIS, 2009d) é uma possível solução para o problema de autenti-
cação federada de dispositivos. Esta possui um perfil de utilização chamado ECP (Enhanced Client
and Proxy), o qual trata da troca de informações de segurança (p.e. asserções sobre autenticação e
autorização do cliente) envolvendo clientes ativos que não fazem uso de um navegador Web, sendo
que a autenticação única é uma das funcionalidades que a especificação oferece neste perfil. O perfil
pode ser utilizado por dispositivos para acessar um recurso protegido.
O perfil ECP exige o uso do protocolo SOAP nas trocas de mensagens entre as entidades,
além de incluir diversos cabeçalhos SOAP adicionais que o cliente deve processar (OASIS, 2009d).
Contudo, o uso do protocolo SOAP não é adequado para o cenário de IoT, pois é muito custoso
computacionalmente (ZENG; GUO; CHENG, 2011; HAMESEDER; FOWLER; PETERSON, 2011).
Alguns trabalhos já abordaram o uso do SAML no contexto da IoT. Em Seitz, Selander e
Gehrmann (2013), asserções SAML são utilizadas para expressar decisões de autorização em um
cenário de IoT, mas o trabalho aborda apenas a autorização e usa apenas as asserções e não protocolos
SAML. Em Akram e Hoffmann (2008b), o SAML é utilizado como parte de uma solução de IdM
para IoT, contudo este é empregado ao lidar com a autenticação de usuários e não ao lidar com a
autenticação de dispositivos.
Outro ponto importante na Internet das Coisas e nas infraestruturas de autenticação e autoriza-
ção, é o uso de mecanismos de autorização alinhados aos requisitos da IoT. Uma AAI que suporte
diferentes modelos e políticas de controle de acesso pode mais facilmente se adaptar às necessidades
dos processos de autorização em aplicações de IoT. A autorização é abordada em AAIs em Gusmeroli,
Piccione e Rotondi (2013) e Liu, Xiao e Chen (2012), contudo provendo suporte a apenas um modelo
20
de controle de acesso. Em Graf et al. (2011), é provido um mecanismo para construção de políticas de
controle de acesso flexíveis, contudo, não são descritos os modelos de controle de acesso suportados.
Nenhum destes trabalhos utiliza padrões de autorização amplamente aceitos. Apenas em Gusmeroli,
Piccione e Rotondi (2013), os esquemas XML utilizados são baseados nos esquemas dos padrões
SAML e XACML.
Diante desse contexto, as seguintes perguntas de pesquisa foram formuladas:
1. Como garantir a autenticação única (SSO) de usuários e de objetos físicos (dispositivos)
que utilizam diferentes mecanismos de autenticação e que estão em domínios de segurança
diferentes, tendo como base o padrão SAML e atendendo as necessidades de aplicações de
IoT?
2. Como suportar mecanismos de autorização flexíveis que reflitam as necessidades de aplica-
ções de IoT tendo como base o padrão XACML?
3. Quais os impactos na utilização de recursos computacionais dos dispositivos decorrentes
do uso de uma Infraestrutura de Autenticação e de Autorização em um ambiente industrial
inteligente que provê aplicações de monitoramento e controle de máquinas industriais?
1.1.1 Solução Proposta
A solução proposta nesse trabalho (Infraestrutura de Autenticação e de Autorização para a
Web das Coisas - Authentication and Authorization Infrastructure for Web of Things - AAI4WoT) visa
conceber uma infraestrutura de autenticação e de autorização (AAI) alinhada aos requisitos da Internet
das Coisas. Para atender as necessidades de autenticação e de autorização no cenário em que cliente
(usuário ou dispositivo) e provedor do recurso (dispositivo) estão em domínios de segurança diferentes,
a AAI4WoT está baseada no modelo de gestão de identidades federadas.
Os problemas de (i) autenticação de usuários e de dispositivos em uma única infraestrutura, (ii)
a autenticação única de dispositivos e de usuários e (iii) o uso de diferentes mecanismos de autenticação
de usuários e de dispositivos são abordados pela AAI4WoT por meio do uso do padrão SAML. A
especificação SAML é utilizada para a troca de dados de segurança (autenticação e atributos) entre
as entidades. Assim, o SAML é utilizado tanto como formato padrão para expressão de dados de
autenticação e atributos, por meio das asserções SAML, quanto para a requisição/resposta de tais
asserções, por meio dos protocolos SAML. Desse modo, provedores de identidade (Identity Providers -
21
IdPs), provedores de serviço (Service Providers - SPs) e clientes são capazes de tratar asserções SAML
e executar seus protocolos.
Para que o padrão SAML possa ser utilizado no cliente, foi proposto um "Cliente Ativo", o
qual tem como função intermediar a troca de mensagens entre o SP e o IdP. Uma das responsabilidades
do cliente ativo é solicitar e interpretar a política de qualidade de proteção do SP que o cliente deseja
acessar, para montar uma requisição de autenticação para um IdP que seja capaz de autenticar o cliente
conforme solicitado na política. Outra funcionalidade é utilizar a asserção SAML enviada pelo IdP
para o cliente, referente ao evento de autenticação realizado, para acesso ao SP desejado.
O SAML é extensível, o que permite que novos mecanismos de autenticação possam ser
utilizados. Desse modo, a solução proposta utiliza estes pontos de extensão para permitir que diferentes
mecanismos de autenticação de dispositivos sejam utilizados.
A fim de tratar dos aspectos do SAML que dificultam sua aplicação no cenário de IoT para
dispositivos, como a necessidade de utilizar o protocolo SOAP quando se utiliza o perfil SAML ECP,
a AAI4WoT teve seus componentes implementados utilizando Serviços Web RESTful. Assim, os
recursos providos pelos dispositivos são acessíveis por meio de Serviços Web RESTful, do mesmo
modo que os serviços de autorização e autenticação da AAI4WoT. Logo, não é utilizado o protocolo
SOAP nas trocas de mensagens, apenas o protocolo HTTP.
Para prover o suporte a mecanismos de autorização flexíveis, a AAI4WoT está baseada no
padrão XACML. Na AAI4WoT, o dispositivo que provê o recurso solicita decisões de autorização
à uma entidade da AAI com muitos recursos computacionais. Esta entidade centraliza, no domínio
do dispositivo, a função de tomada de decisões de autorização. Assim, cabe ao dispositivo apenas a
aplicação da decisão tomada. Para tomar essa decisão, a entidade utiliza políticas de autorização e
requisições/respostas em formatos descritos no padrão XACML. As funcionalidades das entidades de
autorização da IAA4WoT também são oferecidas como Serviços Web RESTful.
Como prova de conceito, um protótipo da AAI4WoT foi desenvolvido. Com o objetivo de
avaliar os impactos da AAI4WoT no desempenho da rede e no uso de recursos computacionais dos
dispositivos, a AAI4WoT foi integrada à uma aplicação de WoT para o monitoramento e controle de
máquinas industriais.
As seguintes hipóteses foram investigadas:
22
1. A utilização dos princípios REST e do protocolo HTTP como protocolo de aplicação e de
transporte, em uma AAI baseada no modelo de gestão de identidades federadas e no padrão
SAML, permite prover autenticação federada (e única) de usuários e de dispositivos diante
de diferentes mecanismos de autenticação em um cenário de IoT.
2. A tomada de decisões de autorização fora do dispositivo que provê o recurso, utilizando in-
tegralmente o padrão XACML e os princípios REST, torna possível o suporte a mecanismos
de autorização flexíveis que refletem as necessidades das aplicações de IoT;
3. O uso da AAI proposta em uma aplicação de IoT implica na utilização de mais recursos
computacionais dos dispositivos, porém o uso da autenticação única reduz os impactos no
consumo de recursos computacionais.
1.1.2 Delimitação de Escopo
Esse trabalho limita-se ao uso de mecanismos de segurança para prover a autenticação em
um cenário da IoT com múltiplos domínios administrativos de segurança. Não faz parte do escopo
a criação de novos mecanismos de autenticação, nem a definição de um novo modelo de gestão de
identidades para o cenário de IoT. Não foi criado um novo modelo de controle de acesso e não foi
criado um novo mecanismo para descrição de políticas de autorização. Também, não foram abordadas
questões relacionadas à auditoria e contabilização dentro do contexto da gestão de identidades na IoT.
Para a avaliação da AAI4WoT, esta foi integrada à uma aplicação de monitoramento e controle
de máquinas industriais inteligentes. A AAI4WoT foi implementada, enquanto que a aplicação de
WoT foi apenas adaptada e não faz parte das contribuições deste trabalho.
1.1.3 Justificativa
A IoT tem se mostrado um tópico de interesse e relevância para a comunidade acadêmica
e para a indústria, no qual se vê um grande impacto para as pessoas e organizações. A IoT integra
dispositivos heterogêneos, o que demanda uma preocupação em relação a interoperabilidade entre
estes (ATZORI; IERA; MORABITO, 2010; MAHALLE et al., 2012). A IoT possui características que
demandam abordagens diferenciadas em relação a segurança, sendo a segurança um dos pontos que
trazem desafios aos pesquisadores (BABAR et al., 2011; ROMAN; NAJERA; LOPEZ, 2011).
Diante do problema de pesquisa e das abordagens encontradas na literatura, como é mostrado no
23
Capítulo 3, a AAI4WoT diferencia-se ao ser uma solução que utiliza o modelo de gestão de identidades
federadas que permite, na mesma infraestrutura, a autenticação única de usuários e de dispositivos.
A AAI4WoT diferencia-se ainda ao possibilitar o uso de diferentes mecanismos de autenticação de
usuários e de dispositivos. Outro diferencial é o uso do XACML como solução de autorização em uma
infraestrutura que trata tanto de autorização como de autenticação de usuários e de dispositivos. Neste
aspecto, a AAI4WoT também diferencia-se ao oferecer as funcionalidades de autorização por meio de
Serviços Web RESTful.
Considerando o cenário de domínios administrativos de segurança heterogêneos, administrados
por organizações distintas, a escolha do modelo de gestão de identidades federadas foi a mais indicada.
Com o uso do modelo federado, cada domínio deve tratar da heterogeneidade de mecanismos de
autenticação apenas no escopo do seu domínio, uma vez que entidades externas são autenticadas em
seus respectivos domínios. Isso é possível em função das relações de confiança entre os IdPs e SPs dos
diferentes domínios de segurança de uma federação (autenticação federada).
Para resolver o problema de autenticação única de usuários e de dispositivos em uma única
infraestrutura em um ambiente federado, a AAI4WoT emprega o SAML como padrão para a troca
de informações de autenticação e de atributos dentro da federação. A escolha justifica-se por ser um
padrão amplamente utilizado em soluções de IdM fora do cenário de IoT, como em Cabarcos et al.
(2009), Garzoglio et al. (2011), Tormo, Millán e Pérez (2013) e em federações como a CAFe1 e a
GÉANT2.
O SAML provê suporte a mecanismos de autenticação de usuários e de dispositivos e à
autenticação única. Como mencionado, a especificação é extensível e permite que novos mecanismos
de autenticação sejam utilizados, de acordo com as necessidades de cada ambiente (OASIS, 2009a;
OASIS, 2005a). Logo, o uso do SAML facilita a interoperabilidade dos dispositivos da IoT com
sistemas da Internet atual.
O uso do estilo arquitetural REST na AAI4WoT vai ao encontro da necessidade de prover
mecanismos de segurança mais leves para a IoT e se mostra mais adequado quando comparado ao
SOAP (HAMESEDER; FOWLER; PETERSON, 2011). O uso de Serviços Web RESTful promove
uma maior interoperabilidade entre serviços e dispositivos, uma vez que o HTTP, um protocolo
extensamente usado na Web, é o protocolo de aplicação adotado. Guinard et al. (2009) e Guinard e
Trifa (2009) são trabalhos que corroboram com essa visão.1 http://portal.rnp.br/web/servicos/como-funciona2 http://www.geant.net/Pages/default.aspx
24
Na AAI4WoT, a flexibilidade de descrição de políticas de autorização e o suporte a diferentes
modelos de controle de acesso foi alcançado por meio do uso do XACML. Esta escolha justifica-se pelo
XACML ser um padrão consolidado na Internet para a descrição de políticas e requisição/resposta de
decisões de autorização, utilizado fora do contexto de IoT e juntamente com o SAML (GARZOGLIO
et al., 2011; TORMO; MILLáN; PéREZ, 2013; ULLTVEIT-MOE; OLESHCHUK, 2012). Ainda, o
XACML permite que decisões de autorização sejam solicitadas e entregues em diferentes formatos,
o que facilita a interoperabilidade com entidades que não utilizam o padrão XACML, sendo uma
opção para tratar a heterogeneidade da IoT. Outro aspecto em que o uso do XACML favorece a
interoperabilidade na IoT é a existência de perfis de uso bem definidos que suportam Serviços Web
RESTful (OASIS, 2013b).
Este trabalho está inserido em um projeto que estabelece uma parceria entre pesquisadores do
Mestrado em Computação Aplicada da Univali e uma indústria produtora de máquinas industriais. Este
projeto inclui o desenvolvimento de uma aplicação de WoT para controle e monitoramento remoto de
máquinas industriais inteligentes, em que as máquinas são monitoradas e controladas a partir de um
domínio de segurança diferente do domínio da máquina. Logo, a demanda pela resolução do problema
de pesquisa vem ao encontro das necessidades de um cenário real de ambientes industriais inteligentes,
sendo esta a aplicação utilizada na etapa de avaliação deste trabalho.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Prover autenticação e autorização de usuários e de dispositivos no cenário de Web das Coisas
para dispositivos e usuários em domínios de segurança diferentes, por meio de uma infraestrutura de
autenticação e de autorização.
1.2.2 Objetivos Específicos
Os objetivos específicos são:
1. Verificar como diferentes mecanismos de autenticação de dispositivos e diferentes modelos
de controle de acesso empregados nas aplicações de Internet das Coisas podem ser utilizados
em uma Infraestrutura de Autenticação e de Autorização baseada nos padrões SAML e
25
XACML;
2. Prover, em uma única infraestrutura, a autenticação única (SSO) de usuários e de disposi-
tivos que utilizam diferentes mecanismos de autenticação, diante de diferentes domínios
administrativos de segurança;
3. Prover um mecanismo de autorização flexível, com suporte a diferentes modelos de controle
de acesso e diferentes políticas de autorização, adequados aos requisitos de aplicações da
Internet das Coisas;
4. Avaliar os impactos do uso da infraestrutura de autenticação e de autorização quando utili-
zada em uma aplicação de Web das Coisas, em termos do uso de recursos computacionais
dos dispositivos.
1.3 METODOLOGIA
Esta seção apresenta a metodologia de pesquisa adotada neste trabalho.
1.3.1 Metodologia da Pesquisa
No desenvolvimento deste trabalho foi utilizado o método hipotético-dedutivo, pois pretendeu-
se confirmar ou refutar as hipóteses apresentadas por meio do desenvolvimento da AAI4WoT e do seu
uso em uma aplicação de controle e monitoramento remoto de máquinas industriais.
O método utilizado, sob o ponto de vista de sua natureza, foi o de pesquisa aplicada. Segundo
UNIVALI (2011), a pesquisa aplicada visa a utilização imediata na solução de problemas concretos.
Logo, a pesquisa teve por objetivo resolver o problema de IdM de dispositivos e de usuários em
aplicações distribuídas da IoT, diante de múltiplos domínios de segurança, por meio do uso de uma
AAI baseada nos padrões SAML e XACML, o que é de aplicação prática para os cenários relacionados.
Sobre a forma de abordagem do problema, a pesquisa foi quantitativa e qualitativa. A pesquisa
foi quantitativa, pois a execução dos experimentos permitiu, por meio do uso de métodos estatísticos,
a avaliação das hipóteses estabelecidas sobre o impacto do uso da AAI4WoT na aplicação de WoT
(hipóteses 3 e 4). A pesquisa foi qualitativa, no que se refere à investigação das hipóteses sobre (i) o
provimento de autenticação única de usuários e de dispositivos que utilizam diferentes mecanismos
de autenticação, diante de múltiplos domínios administrativos, e (ii) sobre o suporte a mecanismos
26
de autorização flexíveis (hipóteses 1 e 2). Há, nestes casos, uma subjetividade inerente ao problema,
que não pode ser traduzida em números, sendo esta dependente da interpretação dos fenômenos
observados e da atribuição correta de significado aos mesmos. Isso torna o uso de métodos estatísticos
facultativo (SILVA; MENEZES, 2005). Logo, a avaliação foi dada de forma descritiva, através da
análise e comparação de trabalhos e da análise do atendimentos de alguns requisitos.
Acerca dos objetivos do trabalho, a pesquisa caracteriza-se como exploratória. A pesquisa
exploratória deve ser constituída pela pesquisa bibliográfica disciplinada, crítica e ampla, visando tornar
o problema explícito ou construir hipóteses (MINAYO; DESLANDES, 1994; SILVA; MENEZES,
2005). Inicialmente, foi realizado um levantamento bibliográfico para o entendimento e definição do
problema de pesquisa, o que permitiu a elaboração das hipóteses e dos procedimentos metodológicos
que foram seguidos para investigar a veracidade das hipóteses, conforme descrito na Seção 1.3.2.
1.3.2 Procedimentos Metodológicos
Esta seção apresenta as etapas do trabalho que foram realizadas para o cumprimento dos
objetivos:
1. Pesquisa bibliográfica: esta etapa teve por objetivo prover o conhecimento teórico para
a definição da solução proposta. Foi realizado um levantamento bibliográfico sobre a
Internet das Coisas e a Web das Coisas. Também foram estudados os aspectos de segurança
computacional, mais especificamente aqueles relacionados a autenticação e a autorização
de usuários e de dispositivos na Internet das Coisas;
2. Análise de trabalhos relacionados: esta etapa visou analisar os trabalhos relacionados
encontrados na literatura que utilizam mecanismos de autenticação e de autorização na
IoT. Estes trabalhos foram selecionados e analisados por meio de critérios definidos em um
protocolo de busca de uma revisão sistemática. Também foi feita uma análise comparativa
das soluções abordadas em cada trabalho;
3. Definição da Infraestrutura de Autenticação e de Autorização: esta etapa visou atender
ao objetivo específico 1. Nesta, foi definido como a Infraestrutura de Autenticação e de
Autorização proposta deveria ser composta para atender aos objetivos desse trabalho. Esta
etapa incluiu o estudo das especificações SAML e XACML, o que permitiu a análise de
como estes padrões poderiam ser utilizados para tratar do problema de pesquisa. Também
27
foram definidas como deveria ser a troca de mensagens entre as entidades da Infraestrutura
de Autenticação e de Autorização;
4. Modelagem da Infraestrutura de Autenticação e de Autorização: esta etapa visou aten-
der, parcialmente, aos objetivos específicos 2 e 3, e compreendeu o levantamento de requisi-
tos e a modelagem da Infraestrutura de Autenticação e de Autorização;
5. Implementação e Integração da Infraestrutura de Autenticação e de Autorização: esta
etapa visou o atendimento parcial dos objetivos específicos 2 e 3. A etapa compreendeu a
implementação da AAI4WoT e a integração desta à aplicação de WoT utilizada na etapa de
Avaliação; e
6. Avaliação da Infraestrutura de Autenticação e de Autorização: esta etapa visou o aten-
dimento aos objetivos específicos 2, 3, e 4. A etapa compreendeu a avaliação dos impactos
decorrentes do uso da AAI4WoT na aplicação industrial de WoT, em termos de desempenho
da rede e do uso de recursos computacionais dos dispositivos, bem como em relação ao
atendimento aos objetivos de segurança.
1.4 ESTRUTURA DA DISSERTAÇÃO
O trabalho está organizado em seis capítulos correlacionados. O Capítulo 1 apresentou, por
meio de sua contextualização, o tema deste trabalho. Foram também estabelecidos o problema de
pesquisa, a solução proposta, os objetivos e a metodologia que foi seguida para atingir os objetivos.
O Capítulo 2 apresenta a fundamentação teórica sobre a Internet das Coisas, gestão de identida-
des digitais e sobre as especificações de segurança que foram utilizadas neste trabalho.
No Capítulo 3 são apresentados os trabalhos relacionados encontrados na literatura, que
abordam a gestão de identidades na Internet das Coisas e na Web das Coisas. Mais especificamente,
são descritos os trabalhos que apresentam infraestruturas que auxiliam nos processos de autenticação,
autorização e de controle de acesso de usuários e/ou de dispositivos.
O Capítulo 4 apresenta a infraestrutura de autenticação e de autorização para a Web das Coisas
(AAI4WoT). Neste capítulo são descritos os modos de operação e os componentes da AAI, assim como
o modelo de ameaças da solução proposta. Também é apresentado neste capítulo o desenvolvimento
da AAI4WoT e sua integração à uma aplicação de WoT para o controle e monitoramento remoto de
máquinas industriais, que compõe o estudo de caso realizado.
28
O Capítulo 5 apresenta os experimentos realizados e os resultados obtidos no estudo de caso,
bem como uma análise destes.
No Capítulo 6, são tecidas as considerações finais, relacionando o que foi realizado com os
objetivos e hipóteses do trabalho. Também são apresentados os trabalhos futuros.
O Apêndice A apresenta o protocolo de busca e os resultados da revisão sistemática da literatura
que foi conduzida. O Apêndice B apresenta a política de controle de acesso utilizada nos experimentos
(estudo de caso). O Apêndice C descreve como o mecanismo de autenticação de dispositivos utilizado
nos experimentos pode ser representado utilizando o padrão SAML. Por fim, o Apêndice D apresenta
a modelagem de software do protótipo desenvolvido.
29
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo, são apresentados os conceitos de Internet das Coisas (IoT) e Web das Coisas
(WoT), assim como os requisitos de segurança para estes paradigmas e as principais ameaças e
ataques. É abordada também a gestão de identidades digitais, os principais modelos de gestão de
identidades, bem como os aspectos relacionados à autenticação e autorização. Por fim, são apresentadas
as especificações SAML, XACML e WS-Policy, as quais são utilizadas em soluções de segurança para
XML e Serviços Web.
2.1 INTERNET DAS COISAS
O próximo passo para o crescimento da Internet é a integração de objetos físicos do dia a dia
(coisas) às redes de comunicação. Esse paradigma, chamado de Internet das Coisas (IoT), abrange
uma infraestrutura de hardware, software e serviços que conectam esses objetos físicos à Internet
(ITU, 2005; COMMUNITIES, 2008). Segundo o relatório ITU Internet Reports 2005: The internet
of things (ITU, 2005), a IoT pode trazer mudanças para a sociedade, como por exemplo, na maneira
como o indivíduo se relaciona com o ambiente, ou na maneira como são realizados os processos de
negócios. Além da comunicação e informação a qualquer momento e em qualquer lugar, na IoT, é
possível também a conectividade para qualquer coisa.
A IoT possui características diferentes quando comparada com cenários computacionais tradi-
cionais. As principais características da IoT são (WANGHAM; DOMENECH; MELLO, 2013):
• A IoT pode ser caracterizada como uma rede mundial de coisas/objetos/dispositivos in-
terconectados que se comportam como entidades ativas (ROMAN; NAJERA; LOPEZ,
2011);
• As coisas (dispositivos) na IoT, muitas vezes, possuem restrições de recursos como RAM
ou ROM, poder de processamento e energia (HUMMEN et al., 2013);
• Mecanismos de comunicação de alguns dispositivos, na maioria das vezes sem fio, possuem
baixa potência de transmissão e baixa taxa de dados (MAHALLE et al., 2010);
• Há uma grande quantidade de coisas com ciclo curto de vida, o que exige uma alta capaci-
dade de gerenciamento (FONGEN, 2012);
30
• Integra coisas heterogêneas, o que demanda uma preocupação em relação a interoperabili-
dade entre estas (ATZORI; IERA; MORABITO, 2010; MAHALLE et al., 2012);
• A rede possui uma topologia dinâmica, pois muitos nós entram e saem da rede com
frequência (MAHALLE et al., 2012; HANUMANTHAPPA; SINGH, 2012);
• Pode ser caracterizada como um ambiente contendo um grande número de computadores
ou dispositivos invisíveis que colaboram com o usuário, ou seja, um ambiente pervasivo e
ubíquo (HANUMANTHAPPA; SINGH, 2012); e
• Na IoT, os usuários podem interagir com as coisas em seu ambiente físico e virtual de
diversas maneiras (MAHALLE et al., 2012).
Os dispositivos na IoT também possuem características singulares. De acordo com Roman,
Najera e Lopez (2011), as coisas na IoT possuem cinco características principais e uma opcional:
• Existência: coisas que existem no mundo real podem também existir no mundo virtual, por
meio de dispositivos de comunicação embarcada;
• Auto conhecimento (do inglês, sense of self ): todas as coisas têm, explicitamente ou impli-
citamente, uma identidade que as descreve. As coisas podem processar informação, tomar
decisões e se comportar de maneira autônoma;
• Conectividade: as coisas podem iniciar a comunicação com outras entidades. Dessa maneira,
a comunicação com entidades nas suas proximidades ou em ambientes remotos é possível;
• Interatividade: as coisas podem interoperar e colaborar com uma variedade de entidades
heterogêneas, seja humanos ou máquinas virtuais ou reais. Desse modo, estas produzem e
consomem uma grande variedade de serviços;
• Dinamicidade: as coisas podem interagir entre si a qualquer momento, lugar ou maneira.
Estas podem entrar e sair de uma rede conforme quiserem, não estando limitadas a um
único local físico, podendo usar uma grande variedade de interfaces; e
• (opcional) Ciência do ambiente: sensores permitem que as coisas percebam as característi-
cas de seu ambiente (p.e. a sobrecarga da rede ou a radiação da água). Contudo, nem todas
as coisas possuem esta capacidade, como por exemplo, um objeto com uma etiqueta RFID.
31
O conceito de IoT pode ser aplicado de diversas maneiras na vida das pessoas e organizações.
Em Atzori, Iera e Morabito (2010), é feito um agrupamento dos diferentes tipos de aplicações da IoT
em quatro domínios. São estes:
• Transporte e logística: aplicações que envolvem meios de transporte de pessoas e de merca-
dorias, assim como aplicações para rodovias;
• Cuidados com a saúde: aplicações para auxílio de cuidados com a saúde das pessoas;
• Ambientes inteligentes: aplicações que tornam escritórios, casas, plantas industriais e ambi-
entes de lazer inteligentes; e
• Pessoal e social: aplicações que habilitam o usuário a interagir com outras pessoas para
manter e criar relacionamentos.
A realização do conceito de IoT no mundo real é possível por meio do uso e integração de
várias tecnologias habilitadoras (ATZORI; IERA; MORABITO, 2010). Como exemplos, pode-se citar
RFID (Radio-Frequency IDentification)1, WSN (Wireless Sensor Network)2, WSAN (Wireless Sensor
and Actuator Network)3, EnHANTs (Energy Harvesting Active Networked Tags)4, NFC (Near Field
Communications)5 e RSN (RFID sensor networks)6, conforme apresentado em Wangham, Domenech
e Mello (2013). Como mencionado, a IoT é composta de ambientes e dispositivos heterogêneos, o que
leva muitas vezes com que esta seja tratada como Web das Coisas (Web of Things – WoT).
2.1.1 Web das Coisas
Por bastante tempo, projetos e iniciativas relacionados à IoT focaram principalmente no
tratamento das questões relacionadas à conectividade em ambientes de rede restritos. Com base na
existência desta conectividade de rede, o próximo passo é a concepção de modelos de comunicação,
tendo como foco a camada de aplicação. Desse modo, quanto mais e mais dispositivos são conectados
à Internet, o uso da Web como uma plataforma para integrar os dispositivos inteligentes da IoT com o
dia-a-dia do ser humano se mostra uma boa escolha (GUINARD et al., 2011).1 (YAN et al., 2008; JUELS, 2006)2 (XIANG; LI, 2012; AKYILDIZ et al., 2002)3 (MARTINEZ et al., 2008)4 (GORLATOVA et al., 2010)5 (AHSON SYED A; ILYAS, 2012; CAVOUKIAN, 2012)6 (BUETTNER et al., 2008)
32
Segundo Guinard et al. (2011), na WoT, os dispositivos inteligentes e seus serviços são
integrados à Web através da reutilização e adaptação de tecnologias e padrões Web que são comumente
utilizados em conteúdos Web tradicionais. Por exemplo, tais dispositivos podem ser indexados na Web,
encontrados por ferramentas de busca e utilizados em ferramentas de bookmarking dos navegadores.
Do mesmo modo, tais objetos podem ser ativos e podem realizar publicações na Web, assim como
podem interagir entre si por meio de Serviços Web disponibilizados nos dispositivos.
Segundo Zeng, Guo e Cheng (2011), existem diversos motivos que favorecem a WoT. A Web
se tornou o principal meio de comunicação na Internet. Navegadores Web estão disponíveis para
quase todas as plataformas, de computadores a smartphones e tablets, o que os tornam a interface
de usuário padrão de fato para uma gama de aplicações. Por meio da Web, é possível fazer uso da
tecnologia dos Serviços Web, a qual tem se mostrado indispensável na criação de aplicações distribuídas
interoperáveis para a Internet. Diversos pequenos servidores Web embarcados estão disponíveis, sendo
que muitos deles podem ser construídos em apenas alguns KBytes. Logo, as coisas inteligentes, com
servidores Web embarcados, podem ser abstraídas como Serviços Web e perfeitamente integradas na
Web existente, sendo que torna-se natural a reutilização de tecnologias e padrões Web existentes para
unificar o mundo cibernético ao mundo das coisas físicas.
Como as tecnologias Web existentes podem ser reutilizadas e adaptadas, é possível construir
novas aplicações e serviços com a participação das coisas inteligentes. Em suma, diferente do ponto
de vista tradicional da IoT, que associa ao dispositivo um endereço IP e os torna interconectados na
Internet, a WoT habilita os dispositivos a "conversarem"na mesma língua, de modo que estes possam se
comunicar e interagir livremente na Internet (ZENG; GUO; CHENG, 2011; GUINARD et al., 2011).
Segundo Zeng, Guo e Cheng (2011), há dois métodos para integrar coisas à Web: integração
direta e integração indireta. Na direta, é requerido que todas as coisas tenham um endereço IP ou
que tenham um IP habilitado quando conectados à Internet. Servidores Web devem ser embarcados
nas coisas/dispositivos para que estas possam se entender por meio da linguagem da Web. Já na
integração indireta, nem todos os dispositivos podem ter recursos computacionais suficientes para
embarcar um servidor Web (p.e. uma etiqueta RFID). Além disso, algumas vezes não é necessário
integrar diretamente todas as coisas inteligentes dentro da Web, quando se considera custo, energia
e segurança. Como solução para integração indireta, pode-se usar de um proxy, chamado de smart
gateway, localizado entre os dispositivos inteligentes e a Web.
Um smart gateway é um componente que permite interação Web com diferentes tipos de
dispositivos embarcados. Sua função é integrar as APIs proprietárias dos dispositivos embarcados e
33
expor as funcionalidades dos dispositivos como recursos identificados por URI, diretamente acessíveis
na Web e manipuláveis por meio do uso do HTTP. Isso permite que sistemas finais na Internet, que
podem ser outros objetos, se comuniquem com os objetos através desse smart gateway, sendo que
este recebe as mensagens vindas da Internet e as repassa ao objeto, e vice-versa (TRIFA et al., 2009;
MAHALLE et al., 2010). Um smart gateway pode ser usado também para orquestrar a composição
de diversos serviços de baixo nível em serviços de alto nível, criando "mashups"com serviços dos
dispositivos, conhecidos como "mashups físicos"(GUINARD; TRIFA, 2009).
2.1.1.1 Serviços Web na Web das Coisas
Segundo W3C (2004), um Serviço Web é um sistema de software projetado para suportar
a interação interoperável máquina à máquina (M2M) sobre uma rede. Há duas grandes classes de
Serviços Web: Serviços Web em conformidade com o REST (FIELDING; TAYLOR, 2002) e Serviços
Web arbitrários, ou WS-* (W3C, 2004). O objetivo principal dos Serviços Web em conformidade
com o REST é manipular os recursos da Web usando um conjunto uniforme de operações sem estado,
enquanto que nos Serviços Web arbitrários usa-se um conjunto arbitrário de operações (W3C, 2004).
Segundo Wangham, Domenech e Mello (2013), ambos os paradigmas podem ser adotados por smart
things ou smart gateways.
Segundo Zeng, Guo e Cheng (2011), as tecnologias chave do paradigma WS-* são o SOAP,
a WSDL (Web Services Description Language), a UDDI (Universal Description, Discovery and
Integration) e a BPEL (Business Process Execution Language). WSDL e SOAP são dois padrões
baseados em XML que são complexos e pesados, que acabam contribuindo para que os Serviços Web
arbitrários demandem mais em termos de poder de processamento, largura de banda e armazenamento
do que os Serviços Web em conformidade com o REST.
Conforme definido em Fielding e Taylor (2002), o REST é um estilo de arquitetura de software,
desenvolvido como um modelo abstrato da arquitetura Web, que pode ser aplicado no desenvolvimento
de sistemas distribuídos fracamente acoplados, denominados RESTful. O conceito básico do REST é
que qualquer coisa é modelada como recurso, ou particularmente como recursos HTTP, com uma URI.
O REST promove a reutilização de padrões Web, permitindo uma interação direta do cliente
com o serviço, sem a necessidade de interpretar uma WSDL para isso. Dispositivos que disponibilizam
seus recursos através de Serviços Web RESTful não necessitam de APIs adicionais7 ou descrições de7 APIs necessárias para a interação entre cliente e servidor, devido ao fato de que ao utilizar WS-*, cada serviço pode
disponibilizar métodos arbitrários e, ao utilizar Serviços WEB RESTful, só é possível utilizar um conjunto fixo de
34
recursos ou funções, como ocorre com Serviços Web arbitrários. Assim, em função da simplicidade,
leveza e interfaces uniformes promovidas pelo REST, o paradigma de Serviços Web RESTful é prefe-
rido para integração ad hoc na Web, viabilizando uma integração mais transparente dos dispositivos
da WoT com redes globais, como a Internet (GUINARD et al., 2009; HAMESEDER; FOWLER;
PETERSON, 2011).
Conforme Zeng, Guo e Cheng (2011), os Serviços Web RESTful são mais adequados para a
WoT do que os Serviços Web arbitrários. O aspecto leve do REST torna-o um excelente candidato
para viabilizar que dispositivos restritos disponibilizem seus recursos como serviços na Web. Algumas
das características que colaboram para essa visão são a baixa complexidade do REST e o baixo
acoplamento das interações sem estado. Os autores fazem uma comparação entre os paradigmas de
Serviços Web RESTful e de Serviços Web arbitrários, e as diferenças mais relevantes são descritas
abaixo:
• Complexidade: considerada alta no WS-* e baixa no REST;
• Manutenção de estados: WS-* trabalha com manutenção de estados enquanto REST não
prevê a manutenção de estados;
• Acoplamento: considerado alto no WS-* e baixo no REST; e
• Flexibilidade: considerada baixa no WS-* e alta no REST.
Os resultados descritos em Hameseder, Fowler e Peterson (2011) corroboram com esta visão.
Por meio da comparação de desempenho entre REST e SOAP, fica claro que o uso do REST é melhor
em termos de quantidade de dados transmitidos na rede, tempo de requisição/resposta e tempo de
serialização/desserialização (montagem e interpretação de requisição/resposta).
2.2 SEGURANÇA NA INTERNET DAS COISAS
Segundo Roman, Najera e Lopez (2011), a segurança é identificada como um dos obstáculos a
serem transpostos para o efetivo uso da IoT. Assim, essa seção visa elucidar os principais aspectos
relacionados à segurança na IoT, dentre estes os que envolvem a gestão de identidades digitais e as
especificações de segurança para XML e Serviços Web mais importantes no contexto deste trabalho.
métodos.
35
A IoT, conforme mencionado na Seção 2.1, possui características que a diferenciam dos
cenários computacionais tradicionais, as quais afetam o modo como a segurança é provida. Dentre
as principais características que afetam a segurança estão as restrições de memória, processamento
e energia. Por exemplo, uma atividade computacional mais intensa, decorrente da execução de um
algoritmo criptográfico, pode causar uma diminuição relevante do tempo de vida do dispositivo, o que
não é desejável. Neste sentido, conforme destacado em Wangham, Domenech e Mello (2013)8, alguns
trabalhos acadêmicos e atividades de padronização de tecnologias e de mecanismos de segurança estão
sendo conduzidos, visando torná-los mais adequados à IoT.
A IoT também possui ameaças e ataques diferentes daqueles dos cenários computacionais
tradicionais. Com base nisto, esta seção aborda os principais requisitos de segurança na IoT, bem como
as principais ameaças e ataques descritos na literatura para este paradigma.
2.2.1 Requisitos de Segurança
Com base nas características singulares da IoT, descritas na Seção 2.1, Alam, Chowdhury e
Noll (2011) e Roman, Najera e Lopez (2011) definem diversos requisitos de segurança para a IoT e
indicam quais propriedades de segurança devem ser garantidas. Estas propriedades são:
• Confidencialidade: dados sensíveis de usuários ou organizações podem estar contidos nas
transações na IoT e, portanto, a confidencialidade de tais dados deve ser assegurada;
• Integridade: dados armazenados e transmitidos não devem ser alterados, removidos ou
incluídos por usuários ou dispositivos não autorizados;
• Disponibilidade: manter os serviços/recursos da IoT disponíveis para acesso por usuários e
dispositivos autorizados em qualquer momento e a partir de qualquer lugar;
• Autenticidade: necessidade de autenticação mútua, pois os dados de IoT são usados para
diferentes processos de tomada de decisão e atuação; e
• Privacidade: se refere a necessidade de prover aos usuários meios para que estes controlem
a exposição e a disponibilidade dos seus próprios dados e informações e tenham maior
transparência sobre como e por quem seus dados são usados.8 Este texto possui estudos previamente publicados por Wangham, Domenech e Mello (2013), os quais foram realizados
no âmbito do mestrado e em conjunto com os respectivos pesquisadores.
36
Conforme descrito em Babar et al. (2010), alguns outros serviços de segurança precisam ser
garantidos na IoT. Dentre estes serviços estão:
• Gestão de Identidades: trata da identificação e autenticação de usuários e de dispositivos
em um sistema, bem como controla acessos aos recursos deste sistema associando direitos e
restrições de acesso, de acordo com a identidade estabelecida (autenticação e autorização);
• Comunicação segura de dados: inclui a autenticação dos pares da comunicação, assegu-
rando a confidencialidade e integridade dos dados transmitidos, impedindo o repúdio de
uma transação e protegendo a identidade das entidades;
• Acesso seguro à rede: garante a possibilidade de conexão de rede ou o acesso a um serviço
apenas para dispositivos autorizados; e
• Resistência à violação: mantém as características de segurança, mesmo quando o dispositivo
for acessado fisicamente por um atacante.
A grande escala e escopo da IoT aumentam as opções de interação dos usuários com os
sistemas, levando à necessidade de estender os modelos atuais de privacidade, segurança e gestão de
identidades para incluir a forma como os usuários interagem com os objetos. Neste sentido, também
são levantados os requisitos de que deve ser possível identificar os objetos de maneira única, além
de permitir a autenticação única (SSO) de objetos na IoT (MAHALLE; PRASAD; PRASAD, 2013;
MAHALLE et al., 2013).
Outro requisito de segurança da IoT é a tolerância a faltas, que consiste no sistema recuperar
a transmissão de dados e reparar a estrutura da rede (p.e. a topologia) de forma autônoma, mesmo
diante de faltas em nós ou nos enlaces da rede (XIAOHUI, 2012; ROMAN; NAJERA; LOPEZ, 2011;
WEBER, 2010).
Weber (2010) destaca ainda o requisito de autenticação de dados, em que o endereço e os
dados do objeto da IoT devem ser autenticados. O controle de acesso sobre os dados providos pelos
objetos também é tido como um requisito. Por fim, apenas o provedor de informações deve ser capaz
de inferir sobre um determinado usuário do sistema a partir de seus dados, o que resulta no requisito
de privacidade do cliente.
37
2.2.2 Ameaças e Ataques
A IoT possibilita que sistemas computacionais se tornem ubíquos e transparentes para os
usuários. Essa transparência, juntamente com a onipresença, ameaçam a privacidade dos usuários e
impõe dificuldades para garantir a confidencialidade e a integridade dos dados trefegados (AKRAM;
HOFFMANN, 2008a).
Do mesmo modo, o compartilhamento de dispositivos entre as pessoas é uma das principais
ameaças à privacidade dos usuários. As pessoas, de posse de um dispositivo alheio, poderiam facilmente
obter dados não autorizados, uma vez que o acesso físico ao dispositivo facilita a ação de um atacante
(JINDOU; XIAOFENG; CHENG, 2012).
Uma das grandes diferenças do cenário da IoT em relação aos cenários computacionais
tradicionais é que, na IoT, os dispositivos podem atuar também no mundo físico. Isso significa que uma
ameaça à segurança de um dispositivo pode ter impactos no mundo físico. Assim, se um dispositivo
da IoT for corrompido, há o risco de que esse corrompimento influencie o mundo físico ao ponto de
atentar contra o bem-estar e até à vida das pessoas (LIU; XIAO; CHEN, 2012). Por exemplo, um
dispositivo que possua sensor de fumaça deve avisar uma central de controle sempre que detectar
fumaça no ambiente. Caso o dispositivo seja corrompido, este poderá emitir alertas falsos ou mesmo
deixar de emitir alertas diante de uma situação de perigo com fumaça.
Babar et al. (2011) dividem os ataques na IoT em cinco categorias, relacionadas a seguir:
• Ataques físicos: violam o hardware do dispositivo e são difíceis de executar, pois o material
necessário para executar os ataques é caro. De-packaging de um chip, micro-probing e
layout reconstruction são técnicas usadas para esse tipo de ataque;
• Ataques no canal de comunicação: ataques baseados em dados recuperados dos dispositivos
responsáveis por operações criptográficas. Esses dados são obtidos através de análise de
temporização, radiação emitida, potência consumida, dentre outras fontes, que permitem
que a chave de criptografia usada seja inferida;
• Ataques de análise de criptografia: ataques com foco no texto cifrado, buscando encontrar
a chave criptográfica para obter o texto em claro (p.e. ataque man-in-the-middle);
• Ataques de software: exploram vulnerabilidades dos softwares presentes no dispositivo.
Inclui ataques de exploração de estouro do buffer (buffer overflow) e uso de programas
38
cavalos de tróia, worms e vírus para injetar código malicioso no sistema; e
• Ataques de rede: no meio sem fio a transmissão é por difusão (broadcast) e assim há
vulnerabilidades inerentes ao próprio meio. Nessa categoria entram ataques como captura e
análise de tráfego (eavesdropping), mascaramento (masquerading - no qual um nó se faz
passar por outro), negação de serviço (Denial of Service – DoS), corrupção de mensagens,
ataques de roteamento, dentre outros (BONETTO et al., 2012).
Conforme Mahalle et al. (2012), as próprias características da IoT potencializam o ataque de
DoS. Dentre tais características, pode-se citar a topologia dinâmica da rede, a menor largura de banda,
as restrições computacionais e de energia. Em alguns casos na IoT, o ataque de DoS pode ser chamado
de ataque de esgotamento de recursos.
No cenário da IoT, quando um dispositivo envia dados para outro, esteja este na mesma rede
do remetente ou não, esses dados enviados podem ser armazenados temporariamente nos dispositivos
intermediários que atuam como roteadores. Caso algum dispositivo intermediário seja malicioso, há a
ameaça de que este altere a informação em trânsito ou ainda deixe de encaminhar a informação para o
nó destinatário (CONZON et al., 2012).
Mahalle, Prasad e Prasad (2013) ainda apontam preocupações sobre o processo de ingresso dos
dispositivos em uma rede. No momento do ingresso na rede, informações sobre chaves criptográficas,
parâmetros de domínio e outras configurações podem ser capturadas por entidades maliciosas e estas
poderiam fazer uso dessas informações para interceptar e reencaminhar dados de forma a não ser
percebido, caracterizando um ataque man-in-the-middle. Neste caso, Mahalle et al. (2012) apontam
que o ataque man-in-the-middle pode levar ao ataque de mensagem antiga (replay attack), no qual o
atacante busca utilizar de mensagens antigas (interceptadas) para se comunicar com outros dispositivos,
a fim de obter respostas desses dispositivos que inicialmente não seriam para ele, mas sim para o
remetente da mensagem original.
Em arquiteturas da IoT que fazem uso do protocolo 6LoWPAN, existe a ameaça de corrom-
pimento de mensagens de identificação ou de localização de dispositivos. O corrompimento dessas
mensagens pode levar ao comprometimento da autenticidade das mensagens e dos participantes de
uma comunicação, pois um intruso pode enviar mensagens falsas de atualização de localização de um
dispositivo. Isso faz com que mensagens não sejam enviadas para o dispositivo de destino, mas (i)
para o atacante, (ii) como parte de um ataque DoS, ou simplesmente (iii) evitando que as mensagens
cheguem ao seu destinatário (JARA et al., 2011).
39
Em Nguyen, Al-Saffar e Huh (2010), são abordados dois outros tipos de ataques na IoT: o
ataque de chave compartilhada (shared-key attack) e o ataque sybil. Em Nguyen, Al-Saffar e Huh
(2010), é descrita uma técnica de autenticação que é baseada em um mecanismo de distribuição de
chaves. Basicamente, cada dispositivo do ambiente recebe material criptográfico, chamado de espaço
de chaves, para poder fazer a negociação de chaves de sessão com outros dispositivos. O mecanismo
de autenticação funciona com base na probabilidade de que dois dispositivos compartilhem o mesmo
espaço de chaves, o que significa que estes conseguirão negociar uma chave de sessão simétrica. Assim,
no ataque de chave compartilhada, o atacante conhece o mecanismo de distribuição de chaves do
ambiente e, sabendo que dois nós estão próximos, supõe que estes compartilhem um mesmo espaço de
chaves. O ataque ocorre quando a chave compartilhada pelos dispositivos também pode ser inferida
pelo atacante, comprometendo a segurança do sistema. O ataque sybil é caracterizado quando um nó
malicioso assume múltiplas identidades falsas com o objetivo de roubar ou forjar a identidade de um
nó legítimo. Em Nguyen, Al-Saffar e Huh (2010), é descrito um cenário de IoT em que esse ataque
pode ocorrer nas situações em que um dispositivo troca de domínio de segurança.
Por fim, Liu, Xiao e Chen (2012) ressaltam a existência do ataque de controle de chaves
(key control attack), no qual uma dos participantes da comunicação força os demais participantes
a escolherem chaves criptográficas dentro de um conjunto restrito de valores ou mesmo um valor
pré-determinado. Desta forma, o atacante influencia o processo de escolha de chaves criptográficas
para facilitar a obtenção do controle sobre os dados trafegados.
2.2.3 Gestão de Identidades Digitais na Internet das Coisas
Uma identidade, no mundo digital, é representada por um conjunto de atributos. Esses atributos
podem ou não ser certificados (verificados e endossados) por uma terceira parte. Um indivíduo pode ter
um conjunto de identidades, que são compostas de diferentes conjuntos de atributos. O ciclo de vida de
uma identidade consiste de seu registro, armazenamento, recuperação, provisionamento e revogação
de atributos da identidade (BHARGAV-SPANTZEL et al., 2007).
Conforme ITU (2009), a gestão de identidades (Identity Management – IdM), pode ser enten-
dida como o conjunto de processos e tecnologias usados para garantir a identidade de uma entidade ou
de um objeto, garantir a qualidade das informações de uma identidade (identificadores, credenciais e
atributos) e para prover procedimentos de autenticação, autorização, contabilização e auditoria.
As entidades envolvidas em um sistema de IdM manipulam a identidade de indivíduos ao
40
longo do ciclo de vida da identidade. Um sistema de IdM possui três entidades principais, a saber
(BHARGAV-SPANTZEL et al., 2007):
• Provedor de Identidade (Identity Provider - IdP): responsável por gerar identidades, manter
a base de dados de usuários do domínio e validar suas credenciais (autenticar usuários);
• Provedor de Serviço (Service Provider - SP): oferece recursos ou serviços aos usuários; e
• Usuário ou dispositivo: utiliza um serviço fornecido por um SP.
É possível implantar a IdM por meio do uso de uma infraestrutura de autenticação e de
autorização (Authentication and Authorization Infrastructure – AAI). Esta infraestrutura é conhecida
como o elemento central para prover a segurança e lidar com problemas de segurança em aplicações
distribuídas (LOPEZ; OPPLIGER; PERNUL, 2004). Com a implantação da IdM, é possível impedir o
acesso de usuários não autorizados aos recursos que se deseja proteger. Também é possível impedir que
usuários legítimos (autenticados) acessem recursos que estes não estão autorizados, além de permitir
que usuários legítimos acessem os recursos que estes tem autorização (LIU; XIAO; CHEN, 2012).
2.2.3.1 Modelos de Gestão de Identidades Digitais
Para Bhargav-Spantzel et al. (2007), a evolução dos sistemas de gestão de identidades passou
por quatro modelos distintos: tradicional, centralizado, federado e centrado no usuário.
No modelo tradicional, o SP provê o serviço solicitado e atua como IdP do usuário. É respon-
sabilidade do SP fazer o gerenciamento das credenciais dos usuários e do contexto em que estas são
usadas. Nesse modelo, o usuário possui um identificador e credenciais únicas para cada SP que acessa
e não há compartilhamento de identidades entre organizações (BHARGAV-SPANTZEL et al., 2007;
JØSANG; POPE, 2005).
Segundo Jøsang e Pope (2005), o uso do modelo tradicional tende a ser mais simples para o SP.
Contudo, conforme Wangham et al. (2010), o uso deste modelo tende a ser custoso para os usuários e
para os SPs. Para os usuários, o custo reside em gerenciar inúmeras identidades. Dentre os problemas,
está ter que fornecer as mesmas informações diversas vezes para diferentes SPs e ter que se preocupar
em criar (e manter) credenciais diferentes para cada SP. Para os SPs, além do custo de manutenção
de uma base de usuários, há o problema de que, em função da tarefa onerosa de sempre fornecer as
mesmas informações para criação de sua identidade, o usuário pode não ser fiel no preenchimento de
41
atributos que não são cruciais para acessar o recurso oferecido pelo SP. Um exemplo de aplicação que
utiliza este modelo é o sistema de gestão de conferências EDAS9.
O modelo centralizado tenta resolver o problema de múltiplas identidades do usuário para
diferentes SPs e da possível inconsistência de informações de identidade por meio da utilização de
apenas um IdP. Assim, existe um IdP central que cria e mantém as informações de identidade do
usuário, no qual usuários e SPs devem confiar. Existe um compartilhamento de identidades dos usuários
entre SPs e é aplicado o conceito de autenticação única (SSO). Uma vantagem desse modelo é que o
usuário pode autenticar-se apenas uma vez e usufruir dessa autenticação em todos os SPs que utilizar.
Entre as desvantagens, estão o fato de que o IdP é um ponto único de falha e, por ser o único detentor
das informações do usuário, pode fazer o que bem entender com elas (BHARGAV-SPANTZEL et al.,
2007; WANGHAM et al., 2010). Um exemplo de uso deste modelo é o portal de serviços do Banco do
Brasil10, em que múltiplos serviços bancários podem ser acessados diante de uma única autenticação.
O modelo federado distribui a tarefa de autenticação por IdPs distintos, localizados em domínios
administrativos de segurança diferentes. Para que a identidade emitida e verificada por um IdP seja
aceita em outro domínio administrativo, devem existir acordos de confiança estabelecidos entre IdPs e
SPs. A partir do estabelecimento de tais acordos, forma-se uma federação entre SPs e IdPs. Logo, o
modelo federado também permite a autenticação única, pois um identificador de um domínio (antes
aceito apenas no domínio em que foi criado) torna-se um identificador único na federação, que é
aceito pelos IdPs e SPs que a compõe (WANGHAM et al., 2010; BHARGAV-SPANTZEL et al.,
2007; JØSANG et al., 2005). Uma vantagem do modelo federado é que este resolve o problema
do ponto único de falha do IdP, já que a tarefa de autenticação é distribuída. O modelo também
consegue oferecer facilidades para os usuários, pois evita que estes tenham que lidar com diversas
identidades e permite a autenticação única. Para os SPs, o benefício é que estes poderão lidar com um
número menor de usuários temporários. Contudo, uma desvantagem é em relação à falta de controle
do usuário acerca das credenciais, já que estas são controladas pelos IdPs (WANGHAM et al., 2010;
BHARGAV-SPANTZEL et al., 2007; JØSANG et al., 2005). Um exemplo do uso deste modelo é a
Federação CAFe11.
Tanto no modelo centralizado como no modelo federado existe a falta de controle do usuário so-
bre as informações disponibilizadas aos IdPs, haja vista que o IdP fica sob controle de tais informações
e pode disponibilizá-las a terceiros. Nesse sentido, surgiu o modelo de gestão de identidades centrado9 https://edas.info/10 bb.b.br11 http://portal.rnp.br/web/servicos/cafe
42
no usuário, que tem por objetivo dar maior controle ao usuário sobre as transações envolvendo os seus
dados de identidade (BHARGAV-SPANTZEL et al., 2007; WANGHAM et al., 2010). Implementações
desse modelo são feitas tendo como base um dos modelos apresentados anteriormente, sendo o modelo
de identidades federadas o mais usado. Em implementações desse modelo, verifica-se que se objetiva
devolver o poder ao usuário em relação à posse das informações de identidade, e que a liberação destas
para um SP fica condicionada ao desejo do usuário, obedecendo assim aos seus desejos de privacidade
(WANGHAM et al., 2010). Uma aplicação que utiliza este modelo é descrita em Maçaneiro (2013).
Conforme Wangham, Domenech e Mello (2013), na IoT, os modelos de IdM mais utiliza-
dos são o centralizado e o federado, em soluções acadêmicas e comerciais. Determinados tipos de
aplicações permitem o uso de infraestruturas centralizadas. Contudo, devido às características da
IoT, na qual usuários e dispositivos podem estar em domínios administrativos diferentes, o uso do
modelo centralizado pode não ser adequado, pois neste caso é necessário que exista um provedor de
identidades amplamente aceito, o que nem sempre ocorre (LIU; XIAO; CHEN, 2012). Em função
destas características, o modelo de gestão de identidades federadas mostra-se mais adequado à IoT
(AKRAM; HOFFMANN, 2008b; LIU; XIAO; CHEN, 2012).
2.2.3.2 Autenticação na Internet das Coisas
O serviço de autenticação trata da garantia de que a entidade com a qual está-se comunicando
é aquela que ela afirma ser. Dois serviços de autenticação são definidos na recomendação X.80012: (i)
autenticação da entidade par e (ii) autenticação da origem de dados. No primeiro serviço é provida
a confirmação da identidade de uma entidade par de uma associação. O objetivo é garantir que uma
entidade não está disfarçada ou realizando uma repetição não autorizada de uma conexão anterior.
No segundo serviço, é provida a confirmação da origem de dados, ou seja, o objetivo é garantir
que a entidade que enviou os dados é aquela que é alegada como remetente (STALLINGS, 2008).
Logo, a autenticação é uma premissa para os processos de autorização, haja vista que uma decisão de
autorização depende da garantia de que aquele que está sendo autorizado realmente é quem diz ser.
No cenário da IoT, os dispositivos podem pertencer a mais de uma rede ou domínio administra-
tivo, cenário que Horrow e Sardana (2012) chamam de Internetwork of Things. Esta situação pode
afetar o funcionamento dos procedimentos de autenticação e de autorização, em função da mobilidade
destes dispositivos entre redes diferentes.12 http://www.itu.int/rec/T-REC-X.800-199103-I/en
43
Em Wangham, Domenech e Mello (2013, p. 172) é ressaltado que, na literatura, a autenticação
na IoT é tratada de forma diferente para usuários e para dispositivos. Na IoT, usuários interagem com
muitos dispositivos inteligentes ou SPs para obter algum serviço útil para eles. Para que um usuário
acesse um objeto/dispositivo na IoT, muitas vezes, é necessário que este passe por um processo de
autenticação.
Uma análise sobre os modelos de autenticação utilizados para autenticar usuários na IoT é
conduzida em Wangham, Domenech e Mello (2013). Percebe-se a existência dos seguintes modelos:
• Autenticação Centralizada baseada em uma terceira parte confiável. Uma entidade central
(IdP ou KDC - Key Distribution Center) é responsável por criar a identidade do usuário
e autenticá-lo, sendo que os SPs que o usuário acessar devem confiar nessa autenticação.
Em Li, Wang e Deng (2010) é proposto o uso do LDAP em conjunto com o mecanismo
de autenticação Kerberos, de modo a prover autenticação única para usuários na IoT. Em
Konidala et al. (2005), o usuário deve registrar-se inicialmente em um servidor central (AS),
o qual é confiável para o usuário e para o SP. Para acessar o SP, o usuário autentica-se no
AS e recebe um token assinado por este, o qual deve ser apresentado ao SP na tentativa de
acesso. O SP verifica a assinatura digital do token antes de conceder o acesso;
• Criptografia de chave pública. Uma chave privada, correspondente a uma chave pública
(normalmente presente em um certificado digital), garante a autenticidade dos usuários
diante dos dispositivos. A criptografia de chave pública pode ser utilizada para garantir a
autenticidade da entidade par e a autenticidade de origem das mensagens. Um exemplo
pode ser encontrado em (ROTONDI; SECCIA; PICCIONE, 2011); e
• Modelo de gestão de identidades federadas. Este modelo é mais adequado à IoT do que o
modelo centralizado, já que na IoT nem sempre o cliente e o SP estão no mesmo domínio
administrativo e, portanto, não confiam no mesmo IdP (AKRAM; HOFFMANN, 2008b;
LIU; XIAO; CHEN, 2012). Em Liu, Xiao e Chen (2012) é proposto um mecanismo de
autenticação de usuários que segue este modelo. Em Akram e Hoffmann (2008b) o OpenID13
é destacado como uma das soluções de IdM usadas no Hydra Middleware14.
Em Wangham, Domenech e Mello (2013) também é feita uma análise dos modelos utilizados
para autenticar dispositivos na IoT, em que é possível perceber o uso dos seguintes modelos:13 http://openid.net/14 http://www.hydramiddleware.eu/
44
• Criptografia de chave pública com auxílio de um KDC. Nesse modelo, descrito em Mahalle
et al. (2012), o KDC é considerado confiável e auxilia os dispositivos gerando e distribuindo
chaves assimétricas com base em um protocolo ECC. Quando dois dispositivos desejam se
comunicar, estes utilizam o protocolo ECCDH para estabelecimento de uma chave de sessão,
com base no par de chaves de cada dispositivo. Após isso, um protocolo de desafio-resposta
é conduzido, para que a autenticação unidirecional ou mútua seja realizada;
• Certificados Digitais. Os dispositivos se autenticam utilizando certificados digitais. Um
exemplo é descrito em Kothmayr et al. (2012), em que uma arquitetura de segurança para
IoT é construída com base no protocolo DTLS. Dois cenários são descritos, um em que
os dispositivos possuem um hardware TPM (Tamper Proof Module) e outro em que os
dispositivos não possuem. No primeiro caso, os dispositivos estabelecem um canal seguro
DTLS e se autenticam mutuamente por meio de certificados X.509, emitidos por uma AC
reconhecida por ambos. No segundo caso, um servidor de controle de acesso (terceira parte
confiável) é utilizado para intermediar o processo de autenticação entre os dispositivos.
Neste sentido, em Hummen et al. (2013) são descritas alterações que podem ser feitas
no handshake do protocolo DTLS para viabilizar seu uso em cenários da IoT em que
dispositivos com restrições computacionais são utilizados;
• Criptografia simétrica. Uma chave criptográfica simétrica, compartilhada entre o dispositivo
de origem e destino, é utilizada para a autenticação mútua. Este modelo é utilizado em
Jara et al. (2011), em que é proposto um esquema de gestão de mobilidade segura para
dispositivos que fazem uso do protocolo 6LoWPAN e que atravessam diferentes domínios
administrativos. Neste trabalho, a autenticação das mensagens trocadas entre um dispositivo
e seu gateway usa criptografia simétrica; e
• Uso de métodos tradicionais de autenticação com o auxílio de um nó intermediário. Neste
modelo, os dispositivos com restrição da IoT podem se beneficiar das mesmas funcionalida-
des de segurança que são típicos de domínios sem restrições (Internet) sem, contudo, ter
que executar operações computacionalmente intensivas para estes dispositivos. Para que
isso seja possível, utiliza-se um nó confiável sem restrições computacionais (gateway) para
assumir as tarefas intensivas de computação. Um exemplo dessa abordagem utilizando o
protocolo EAP é descrito em Bonetto et al. (2012).
45
2.2.3.3 Autorização na Internet das Coisas
A segurança requer que ações em um sistema computacional possam ser atribuídas a indivíduos.
Os processos envolvidos no estabelecimento da identidade de um indivíduo são a identificação e
autenticação. O primeiro trata do processo em que o usuário afirma quem é, e o segundo trata do
processo em que evidências são providas acerca da validade da afirmação de identidade. A partir do
estabelecimento da identidade é possível decidir se uma determinada ação sobre um determinado
objeto é permitida ou não, processo conhecido como autorização. Logo, a autenticação, que permite
garantir a identidade de um indivíduo, é um pré-requisito para que decisões de autorização possam ser
tomadas corretamente (LANDWEHR, 2001).
Uma decisão de autorização é tomada como base para o processo de controle de acesso. O
controle de acesso limita o escopo das ações que um indivíduo, ou entidades em seu nome, podem
realizar em um sistema computacional. A Figura 1 apresenta o esquema básico do controle de acesso
exercido por meio em um sistema computacional (LENTO; FRAGA; LUNG, 2006).
Figura 1. Controle de Acesso
Fonte: Lento, Fraga e Lung (2006).
O Monitor de Referência (ANDERSON, 1972) define os mecanismos utilizados na efetivação
do controle de acesso. Segundo Lento, Fraga e Lung (2006), o monitor de referência atua como
intermediário nas tentativas de acesso de qualquer sujeito à qualquer objeto protegido. O monitor
de referência faz isto por meio da consulta às políticas de segurança, que são administradas pelo
administrador do sistema.
Conforme Lento, Fraga e Lung (2006) "Os modelos de segurança correspondem a descrições
formais do comportamento de um sistema atuando segundo regras de uma política de segurança".
46
Logo, a definição de políticas de segurança é normalmente orientada por modelos de segurança. A
seguir são descritos os modelos de segurança mais relevantes para este trabalho.
O controle de acesso discricionário (Discretionary Access Control – DAC) delega aos usuários
a tarefa de proteger seus recursos no sistema. Duas abordagens tradicionais para o DAC são as listas de
controle de acesso (Access Control List – ACL) e as listas de competências (ou listas de habilidades)
(LENTO; FRAGA; LUNG, 2006).
No modelo de ACL, a cada objeto é associada uma lista que contém os sujeitos com o acesso
autorizado ao objeto. Apesar de ser simples e bastante flexível, o modelo de ACL é custoso para
manutenção, quando aumenta o número de objetos protegidos ou de usuários. Nestes casos, atividades
como revogação de direitos de acesso podem ser bastante custosas (LENTO; FRAGA; LUNG, 2006;
WANGHAM; DOMENECH; MELLO, 2013). Na IoT, o modelo de ACL é utilizado no mecanismo
proposto em Guinard, Fischer e Trifa (2010), o qual integra a WoT com redes sociais.
Na abordagem de listas de competências (Capability Based Access Control – CapBAC), cada
sujeito possui uma lista que indica quais direitos de acesso o sujeito possui para cada objeto protegido
do sistema. A competência, ou habilidade, é um token, que dá direito aquele que a possui de acessar os
objetos descritos na habilidade. Assim, o token pode ser passado de um sujeito para outro, dando ao
recebedor os respectivos direitos de acesso. Este modelo oferece facilidades às operações de verificação
e revogação de direitos de acesso e também boa escalabilidade, uma vez que não é preciso confrontar a
identidade do usuário com uma lista de controle de acesso. Neste modelo, tem-se um número menor de
informações armazenadas na entidade responsável por aplicar o controle de acesso (LENTO; FRAGA;
LUNG, 2006; WANGHAM; DOMENECH; MELLO, 2013). Aplicações do CapBAC na IoT são
realizadas em Rotondi, Seccia e Piccione (2011), Mahalle et al. (2012) e Mahalle et al. (2013).
O modelo de controle de acesso baseado em papéis (Role Based Access Control – RBAC),
regula o acesso dos usuários com base nas atividades executadas e não com base nas identidades dos
usuários. O modelo funciona com base em papéis, definidos de acordo com as atividades associadas a
um cargo ou função. Aos papéis são associadas as regras de acesso e os usuários são associados aos
papéis. O RBAC é amplamente aceito na Internet por sua simplicidade para gerenciar permissões e
usuários (LENTO; FRAGA; LUNG, 2006; WANGHAM; DOMENECH; MELLO, 2013). O RBAC é
utilizado na IoT em Liu, Xiao e Chen (2012), Jindou, Xiaofeng e Cheng (2012) e Souza et al. (2008).
No modelo de controle de acesso baseado em atributos (Attribute Based Access Control –
ABAC), a tomada de decisão de autorização é feita por meio da avaliação de atributos de sujeitos
47
e objetos, das operações que o sujeito deseja realizar sobre o objeto e das condições do ambiente.
Isso permite que se garanta o acesso de sujeitos a objetos sem a necessidade de especificar relações
individuais entre estes e sem precisar conhecer a priori os objetos e sujeitos individualmente. Sistemas
que implementam o ABAC são capazes de implementar o DAC e o MAC (HU et al., 2014). O ABAC
é utilizado no cenário da IoT em Han e Li (2012) e Zhang e Liu (2011), em que adaptações são feitas
para adequá-lo ao cenário da aplicação.
O modelo de controle de acesso baseado em políticas (Policy Based Access Control – PBAC),
pode ser entendido como uma padronização e harmonização do ABAC em um nível empresarial,
capaz de suportar objetivos de governança específicos, como por exemplo, a adequação de toda
uma organização a uma política de controle de acesso que atende a um determinado requisito legal.
Enquanto no ABAC as decisões de controle de acesso são tomadas localmente, com base nas políticas
de controle de acesso locais (p.e. de uma filial), o PBAC leva em consideração as políticas globais da
organização. O modelo ainda leva em consideração os atributos utilizados no ABAC, contudo possui
uma maior orientação a políticas (NIST, 2009).
Conforme observado em Wangham, Domenech e Mello (2013), no contexto da IoT, os meca-
nismos de autorização implantam modelos de controle de acesso já empregados na Internet clássica,
como ACL, CapBAC, RBAC e ABAC. Em alguns casos, como foi mencionado nesta seção, estes
modelos podem sofrer adaptações para atender aos requisitos de uma determinada aplicação. Contudo,
tais adaptações normalmente não alteram o modelo propriamente dito.
2.2.4 Especificações de Segurança para XML e Serviços Web
Esta seção apresenta as especificações de segurança para XML e para Serviços Web mais
relevantes para este trabalho. No contexto de segurança para XML, são apresentadas as especificações
SAML e XACML. No contexto de segurança para Serviços Web, é apresentada a especificação
WS-Policy.
2.2.4.1 SAML
O padrão SAML, desenvolvido pela OASIS15, define um framework baseado em XML para
a troca de informações de segurança entre parceiros de negócio. Essas informações de segurança
são expressas através de asserções SAML portáveis entre os sistemas participantes. Tais sistemas,15 https://www.oasis-open.org
48
localizados em domínios de segurança distintos, podem confiar nas asserções trocadas entre si, sendo
possível a troca de informações de atributos, autenticação e autorização acerca de um sujeito. Para
isso, o padrão SAML define uma sintaxe precisa e regras para requisição, criação, comunicação e uso
das asserções SAML (OASIS, 2008).
Um dos motivos para adoção do SAML é que este possui mecanismos que permitem a
implementação do conceito de identidades federadas, que é útil caso os parceiros de negócio desejem
oferecer um ambiente de aplicação colaborativo para seus usuários em comum. Neste caso, deve haver
um entendimento sobre quem é o usuário referenciado nas informações de segurança trocadas entre
esses parceiros, que comumente é estabelecido por meio de um identificador compartilhado. Caso haja
essa referência comum para um mesmo usuário em domínios distintos, é dito que sua identidade é
federada (OASIS, 2008).
Outro aspecto que favorece a adoção do SAML é que este permite que suas asserções sejam
utilizadas em ambientes que não usam os protocolos SAML. A vantagem no uso dessas asserções é
que o SAML padroniza a troca de informações de segurança, como atributos de um sujeito, os quais
não são facilmente transmitidos através de outros formatos (p.e. os tokens do padrão WS-Security).
Essa modularidade é útil no desenvolvimento de mecanismos que abordam serviços de autorização e
frameworks de IdM (OASIS, 2008).
A arquitetura do SAML possui componentes que permitem atender a diversos casos de uso
diferentes. Os conceitos básicos da arquitetura do SAML são (OASIS, 2008):
• Asserções (Assertions): carregam sentenças sobre um sujeito que uma Asserting Party
afirma que são verdadeiras, sendo que sua estrutura e conteúdo são definidos por um XML
Schema;
• Protocolos (Protocols): as mensagens de um protocolo SAML são utilizadas para requisi-
ção/resposta e sua estrutura e conteúdos são definidos por um XML Schema;
• Ligações (Bindings): define como as mensagens de um protocolo SAML são transportadas
entre os participantes por meio de um determinado protocolo de comunicação;
• Perfis (Profiles): definem restrições ao conteúdo das asserções, protocolos e bindings, com
a intenção de atender a um caso de uso específico, visando a interoperabilidade;
• Contexto de Autenticação (Authentication Context): serve para expressar informações de-
talhadas sobre o tipo e força da autenticação realizada por um sujeito em um IdP, podendo
49
ser carregado dentro de uma asserção ou referenciado por ela. Pode também ser incluído
como parte da requisição por uma asserção, quando o SP informa ao IdP o tipo e força da
autenticação que o sujeito deve realizar para que a asserção seja aceita; e
• Metadados (Metadata): define uma maneira de expressar e compartilhar as informações
de configuração entre entidades SAML. Expressa, por exemplo, os bindings suportados e
informações de identificação e material criptográfico, por meio de um XML Schema.
As asserções SAML podem carregar três tipos de sentenças, a saber (OASIS, 2009a):
• Sentenças de Autenticação: afirmando, no mínimo, os meios utilizados por uma entidade
para autenticar um sujeito e quando isso foi feito;
• Sentenças de Atributos: afirmam sobre um determinado atributo do usuário, como por
exemplo, que o usuário desempenha um papel em uma organização; e
• Sentenças de Autorização: fazem afirmações acerca de alguma ação que o sujeito está
autorizado a fazer.
O SAML define também protocolos de requisição-resposta genéricos. Dentre os protocolos,
pode-se destacar: (i) o Authentication Request Protocol, que define como um sujeito pode fazer a
requisição de asserções contendo sentenças sobre autenticação e/ou atributos; (ii) o Assertion Query
and Request Protocol, que define um conjunto de consultas pelas quais uma asserção SAML pode ser
obtida, por meio da sua ID ou do sujeito envolvido; e (iii) o Artifact Resolution Protocol, que provê um
mecanismo pelo qual as mensagens SAML podem ser passadas por referência, utilizando um campo
curto e de tamanho fixo chamado artifact (OASIS, 2009a).
Os bindings do padrão SAML definem como as mensagens de protocolo SAML podem ser
transportadas por outros protocolos. Dentre os bindings disponíveis, destacam-se (i) aqueles utilizados
para troca de mensagens SAML utilizando como protocolo de transporte o HTTP (HTTP Redirect
Binding, HTTP POST Binding e HTTP Artifact Binding), e (ii) os bindings que utilizam mensagens
SOAP para o transporte de mensagens SAML (Reverse SOAP (PAOS) Binding e SAML SOAP Binding)
(OASIS, 2009b).
Conforme mencionado, os perfis SAML são combinações de asserções, bindings e protocolos
com algumas restrições, feitas a fim de favorecer a interoperabilidade em um cenário de uso específico.
50
Os perfis SAML mais relevantes no contexto deste trabalho são aqueles que proveem a autenticação
única, a saber (OASIS, 2009d):
• Web Browser SSO Profile: define como prover a autenticação única para clientes que fazem
uso de navegadores Web padrão, usando bindings baseados no protocolo HTTP; e
• Enhanced Client and Proxy (ECP) Profile: define um perfil de autenticação única em que
clientes especializados ou proxies podem utilizar os bindings baseados no SOAP e interme-
diar a troca de mensagens entre SP e IdP.
O perfil Web Browser SSO permite que um usuário, por meio de um navegador Web padrão,
acesse um recurso em um SP, ou acesse um IdP de modo que o SP e o recurso que deseja acessar
estão implícitos. O usuário deve se autenticar no IdP, o qual gera uma asserção de autenticação que é
consumida pelo SP, permitindo que este estabeleça um contexto de segurança para o cliente. Para a
implementação desse perfil, o protocolo SAML Authentication Request é utilizado em conjunto com
o binding HTTP Redirect, HTTP POST ou HTTP Artifact. Assume-se, ainda, que o usuário é capaz
de se autenticar no IdP utilizando algum mecanismo de autenticação, o qual está fora do escopo da
especificação SAML (OASIS, 2009d).
O perfil ECP possui como premissa a presença de um ECP no cenário. Um ECP é uma entidade
do sistema que sabe como contatar o IdP apropriado para determinada operação e suporta o binding
Reverse SOAP (PAOS). O perfil ECP dá suporte ao cenário em que um cliente, por meio de um ECP,
tenta acessar um recurso em um SP, ou acessa um IdP de modo que o recurso e o SP que o cliente
deseja acessar estão implícitos. O cliente se autentica no IdP, que produz uma asserção de autenticação.
O SP consome esta asserção e estabelece seu próprio contexto de segurança para o cliente. Para a
implementação desse perfil, o protocolo SAML Authentication Request é utilizado em conjunto com o
binding Reverse SOAP (PAOS). Neste contexto, o ECP é visto como um SOAP intermediary entre o
SP e o IdP, responsável por encaminhar as mensagens entre as entidades e processar os cabeçalhos
SOAP adicionais que são necessários (OASIS, 2009d).
2.2.4.2 XACML
O XACML (eXtensible Access Control Markup Language) é uma linguagem baseada em
XML para a descrição de políticas de autorização e para requisição/resposta de decisões de controle
de acesso (OASIS, 2003). O XACML permite basear a decisão de autorização em características do
51
sujeito ou do recurso que o sujeito irá acessar, não apenas na identidade destes. Isto é possível por
meio de mecanismos de identificação única de atributos de recursos e de sujeitos. Também é possível
embasar uma decisão de autorização no conteúdo de um recurso. Além disso, o XACML provê um
conjunto de operadores lógicos e matemáticos que operam sobre tais atributos (OASIS, 2013a).
O XACML permite ainda que as políticas sejam escritas por diferentes autores, armazenadas em
locais diferentes e aplicadas (enforced) em locais diferentes. Contudo, muitas vezes o PEP (responsável
por aplicar a decisão de autorização) está em sistemas que não “falam” XACML e os atributos utilizados
para tomada de decisão (feita pelo PDP) podem estar em outros formatos, enquanto que o XACML é a
linguagem utilizada pelo PDP para troca de mensagens e descrição das políticas de autorização. Isso é
resolvido no XACML por meio de um passo intermediário de conversão do formato entendido pelo
PEP para o formato entendido pelo PDP, e vice-versa (OASIS, 2013a).
Figura 2. Modelo de Fluxo de dados do XACML
Fonte: Adaptada de OASIS (2013a).
Conforme OASIS (2013a), a especificação XACML provê um modelo de fluxo de dados, o
qual descreve como os dados referentes à tomada de decisão de autorização fluem entre as entidades
previstas no modelo. Este modelo é mostrado na Figura 2 e é descrito a seguir. (1) O PAP escreve
52
políticas e os disponibiliza ao PDP; (2) O requisitante de acesso solicita acesso ao PEP; (3) O PEP
envia a requisição de acesso ao manipulador de contexto (context handler) no formato original da
requisição; (4) O manipulador de contexto constrói uma requisição no formato XACML (contexto
XACML) e envia ao PDP; (5) O PDP requisita (se necessário) ao manipulador de contexto atributos
adicionais de sujeitos, recursos, ações e do ambiente; (6) O manipulador de contexto requisita os
atributos ao PIP; (7) O PIP obtém os atributos solicitados; (8) O PIP retorna os atributos solicitados
ao manipulador de contexto; (9 - Opcional) O manipulador de contexto inclui no contexto o próprio
recurso; (10) O manipulador de contexto envia os atributos requisitados e (opcionalmente) o próprio
recurso ao PDP. O PDP avalia a política; (11) O PDP retorna o contexto de resposta (inclui a decisão
de autorização) ao manipulador de contexto; (12) O manipulador de contexto traduz o contexto de
resposta para o formato nativo de resposta do PEP e envia a resposta a este; (13) O PEP atende às
obrigações (XACML Obligations); (14 - Não mostrado) Se o acesso for permitido, o PEP permite o
acesso ao recurso; Caso contrário, o acesso é negado.
2.2.4.3 WS-Policy
Segundo W3C (2007), o Framework Web Services Policy 1.5, também conhecido como WS-
Policy, provê um modelo de propósito geral e uma sintaxe para descrição de políticas de entidades
em um sistema baseado em Serviços Web. Essas políticas se referem a habilidades, requisitos e
características gerais das entidades citadas.
Basicamente, uma política é uma coleção de alternativas de políticas. Uma alternativa de
política é uma coleção de asserções de políticas. Uma asserção de política representa um requisito,
habilidade ou outra propriedade de um comportamento de uma entidade de um sistema baseado em
Serviços Web. Uma expressão de política é uma representação da política feita na linguagem XML
Infoset16 (W3C, 2007).
Aplicado ao cenário de sistemas baseados em Serviços Web, uma política pode ser utilizada
para transportar condições de uma interação entre entidades (p.e. aplicação requisitante, SP, etc.). Como
uma interação envolve uma ou mais trocas de mensagens entre duas entidades, é responsabilidade do
autor da asserção definir o escopo desta, o que inclui definir restrições em relação a quais sujeitos e a
quais mensagens de uma interação a asserção pode ser aplicada. Do mesmo modo, qualquer entidade
em um sistema baseado em Serviços Web pode usar uma política para expor as condições sob as
quais a entidade funciona. Por exemplo, se duas entidades, um requisitante e um provedor, expõe suas16 http://www.w3.org/TR/xml-infoset/
53
políticas conforme descrito anteriormente, o requisitante pode utilizar a política do provedor para
decidir se deve ou não utilizar o serviço oferecido (W3C, 2007).
2.3 CONSIDERAÇÕES
Ao comparar o cenário da IoT com os cenários computacionais tradicionais, tornam-se claras as
diferenças entre estes. Tais diferenças, exemplificadas principalmente pelas restrições computacionais
e de energia dos dispositivos, bem como pela heterogeneidade de dispositivos e tecnologias, levam a
diversos desafios. Dentre tais desafios destacam-se aqueles relacionados à garantia das propriedades
de segurança computacional (confidencialidade, integridade, disponibilidade, autenticidade e não-
repúdio) para dispositivos e para a comunicação destes com outros sistemas computacionais. Também
destacam-se os desafios relacionados à interoperabilidade entre os próprios dispositivos e entre estes e
os sistemas computacionais já existentes na Internet.
Diante desse cenário, a WoT mostra-se uma abordagem interessante para ambos os desafios. O
fato da WoT trazer para a IoT os recursos já utilizados na Web atual, como o uso de navegadores Web,
URIs e o protocolo HTTP, permite abordar a interoperabilidade entre os sistemas da Web e os sistemas
da IoT de uma maneira simples e direta, uma vez que as ferramentas da Web podem ser reaproveitadas
no cenário da IoT.
Em relação à segurança dos dispositivos, da comunicação entre estes e da comunicação entre
dispositivos e sistemas computacionais da Internet atual, também podem ser utilizadas abordagens
existentes na Web atual. Esse reaproveitamento favorece o desenvolvimento de soluções seguras para
a IoT, uma vez que estas são baseadas em padrões já consolidados da Web. Também é favorecida a
interoperabilidade entre soluções de segurança da Web atual com as soluções de segurança da IoT,
uma vez que as últimas são baseadas nas primeiras.
Assim, ao vislumbrar a IoT como parte da Internet atual, é bastante coerente perseguir a
interoperabilidade com a Web. Diante disso, uma opção que favorece essa integração é basear as
soluções de segurança da WoT em soluções de segurança já consolidadas na Web atual, ou seja, buscar
a interoperabilidade com padrões da Web.
Neste capítulo, foi apresentada a IoT e a WoT, bem como as questões de segurança que
permeiam esses conceitos. Foi abordada também a gestão de identidades digitais como um tópico
relevante, que deve ser considerado em soluções que procurem atender aos requisitos de segurança de
determinados cenários da IoT. Foram apresentadas algumas especificações de segurança para XML e
54
Serviços Web, que são utilizadas na Web atual. Tais tópicos formam a base conceitual deste trabalho,
bem como a base para entender como o trabalho se relaciona com os trabalhos descritos no próximo
capítulo.
55
3 TRABALHOS RELACIONADOS
Este capítulo apresenta os trabalhos correlatos encontrados na literatura que abordam a gestão
de identidades na Internet das Coisas e na Web das Coisas. Mais especificamente, são apresentados os
trabalhos que tratam dos processos de autenticação, autorização e controle de acesso de usuários e de
dispositivos, por meio de propostas de infraestruturas de autenticação e/ou autorização. Ao final do
capítulo, é feita a comparação dos trabalhos descritos com este trabalho.
A escolha dos trabalhos foi feita com base em uma revisão sistemática da literatura, a qual foi
realizada em sete bases de busca para trabalhos publicados entre 2005 e 2014. Esta revisão sistemática
da literatura foi realizada conforme o protocolo de busca descrito no Apêndice A.
3.1 AKRAM E HOFFMANN (2008C)
O framework de IdM apresentado em Akram e Hoffmann (2008b) é parte integrante do Hydra
Middleware (LinkSmart Middleware) 1. O objetivo do framework é abstrair dos desenvolvedores os
mecanismos de IdM utilizados em suas aplicações em ambientes federados. O Hydra Middleware é
baseado em WS-* e utiliza os padrões WS-Security, WS-Trust, WS-Policy e WS-Federation (AKRAM;
HOFFMANN, 2008b).
O framework possui uma arquitetura híbrida, que usa o OpenID, o SAML e o Windows
CardSpace. Na Figura 3, que ilustra o framework proposto (HIM - Hydra Identity Manager), é
mostrado que no topo do WCF2 está o UIB (Universal Identity Bus), que provê interfaces para o
HIM. Por meio dessas interfaces, o UIB alimenta o HFE (Hydra Federation Engine) com serviços
como o "cross-matching"de diferentes tipos de tokens, protocolos e information cards (p.e. Windows
CardSpace e DigitalMe) (AKRAM; HOFFMANN, 2008b).
É o HFE que os desenvolvedores utilizam se precisam dos papéis de IdP, RP (Relying Party)
ou de sujeito, conforme os padrões OpenID e SAML, ou se precisam implementar o serviço de seleção
de identidades do Windows Cardspace. O HFE serve para que o desenvolvedor consiga implementar
uma federação baseada no Hydra Middleware (AKRAM; HOFFMANN, 2008b).
O Hydra Middleware trata da autenticação única de usuários por meio dos mecanismos1 http://www.hydramiddleware.eu/2 Windows Communication Foundation, framework utilizado para construção de Serviços Web seguros
56
Figura 3. Arquitetura do Hydra Identity Manager
Fonte: Adaptada de Akram e Hoffmann (2008b).
suportados (p.e. OpenID e SAML). A autorização é tratada para usuários com base no modelo
de controle de acesso baseado em contexto (Context Based Access Control – CBAC) (HOFFMANN et
al., 2010) . Contudo, a autenticação e autorização de dispositivos não é tratada. Vale ressaltar que, além
do modelo de gestão de identidades federadas, a abordagem também é centrada no usuário. Um dos
pontos que podem trazer dificuldades no uso do middleware na IoT, é que este é baseado nos padrões
WS-*, que não são adequados para o ambiente de IoT, conforme apresentado no Capítulo 2. Por fim, o
trabalho não descreve a implementação da proposta, mas pelos títulos dos Deliverables3 do projeto
(não acessíveis ao público), pode-se inferir que protótipos foram desenvolvidos.
3.2 ALAM, CHOWDHURY E NOLL (2011)
Em Alam, Chowdhury e Noll (2011) o objetivo é prover o acesso seguro a serviços na IoT e
a interoperabilidade semântica de atributos de segurança entre diferentes domínios administrativos,
uma vez que atributos de segurança de domínios diferentes normalmente são diferentes (p.e. papéis,
responsabilidades delegadas aos papéis e níveis de segurança).3 http://www.hydramiddleware.eu/articles.php?article_id=90
57
É proposto o uso de ontologias de sensores, de eventos no ambiente e das entidades de controle
de acesso. Desse modo, é possível fazer um mapeamento dos atributos de segurança de um domínio
para os atributos de outro domínio. Para utilizar isso no contexto de autorização de acesso são utilizadas
regras semânticas, baseadas nas ontologias, para expressar restrições de autorização, que são usadas
para tomar decisões de autorização. Assim, o framework proposto permite que o controle de acesso
em uma organização seja influenciado pelos mecanismos e modelos de controle de acesso utilizados
em outras organizações (domínios de segurança distintos), evitando ambiguidades e favorecendo uma
operação integrada entre domínios (ALAM; CHOWDHURY; NOLL, 2011).
O foco principal do trabalho é a autorização em um ambiente federado de IoT, em que é
proposto um mecanismo independente do modelo de controle de acesso que permite integrar atributos
de diferentes domínios, que atuam sobre uma mesma semântica. Contudo, a autenticação de usuários e
de dispositivos não foi abordada.
3.3 CONZON ET AL. (2012)
Em Conzon et al. (2012), é apresentado o VIRTUS, um middleware que possui o objetivo de
prover comunicação segura entre entidades em um cenário de IoT. O VIRTUS é baseado no XMPP
(SAINT-ANDRE, 2004), que é um protocolo baseado em XML usado na troca de mensagens em tempo
real, troca de informações de presença e serviços de requisição/resposta. O cenário abordado pelo
middleware é de usuários acessando dispositivos da IoT, por meio de dispositivos como smartphones.
O VIRTUS provê mecanismos de autenticação e de controle de acesso nativos do XMPP.
Na arquitetura, um dispositivo deve suportar os protocolos TLS (DIERKS; ALLEN, 1999) e SASL
(MELNIKOV; ZEILENGA, 2006). O TLS é utilizado para garantir a confidencialidade e integridade
dos dados transmitidos, enquanto que o SASL faz a autenticação de entidades por perfis específicos
XMPP, permitindo diversos mecanismos de autenticação, tais como login e senha, SAML, Kerberos e
certificados X.509. No caso da comunicação entre usuários e dispositivos localizados em domínios
diferentes, os servidores que implementam o VIRTUS devem estabelecer um canal seguro usando o
TLS e o SASL e, por meio desse canal seguro, entidades de domínios diferentes podem comunicar-se
(CONZON et al., 2012).
O trabalho trata principalmente da interoperabilidade de comunicação entre dispositivos e
usuários que utilizam tecnologias de comunicação diferentes, provendo essa interoperabilidade de
maneira segura. A autenticação de usuários que utilizam o middleware e servidores que implementam
58
o middleware é tratada, mas a autenticação única de usuários e a autenticação de dispositivos não é
abordada. A autorização para acesso aos dispositivos é feita utilizando o modelo de lista de controle
de acesso (ACL). Para isso, cada módulo do middleware que intermedia o acesso a determinado
dispositivo é configurado para (i) liberar o acesso ao recurso para requisições vindas de outros
domínios de segurança ou somente para requisições do mesmo domínio; e (ii) para permitir ou não
o acesso de determinado usuário ao recurso do dispositivo. Assim, a abordagem segue o modelo de
gestão de identidades tradicional. Portanto, caso o número de dispositivos de um domínio de segurança
aumente, pode haver um aumento expressivo da carga administrativa, uma vez que alterações nas
políticas de segurança devem ser realizadas individualmente nos recursos providos.
3.4 LIU, XIAO E CHEN (2012)
Em Liu, Xiao e Chen (2012) é proposta uma arquitetura para IoT baseada no OpenID, que trata
da autenticação e do controle de acesso em um ambiente federado, em que usuários de um domínio de
segurança consomem recursos de dispositivos de outro domínio. Na inicialização do sistema, cada
dispositivo deve se registrar em uma entidade confiável (Registration Authority – RA) de seu domínio,
que auxiliará no processo de autenticacão. A Figura 4 mostra a arquitetura proposta.
HRA
ObjetoUsuário
RA
Domínio de Segurança A
2
7
1
Domínio de Segurança B
5.2
5.1
6
5
34
Figura 4. Arquitetura da IoT e passo-a-passo do protocolo de autenticação
Fonte: Adaptada de Liu, Xiao e Chen (2012).
59
A autenticação do usuário no seu domínio de segurança, feita no HRA (Home Registration
Authority), pode ser aceita no domínio do RA (LIU; XIAO; CHEN, 2012), em função das relações de
confiança entre as entidades da federação. A sequência de passos do mecanismo é mostrada na Figura
4. No Passo 1, o usuário requisita acesso ao dispositivo, o qual envia a requisição de autenticação para
a RA em que se registrou, para que esta verifique a solicitação do usuário (Passo 2). A RA requisita ao
usuário a sua ID (Passo 3) e recebe como resposta do usuário a indicação da HRA de confiança deste
(Passo 4). No Passo 5, a RA verifica a informação recebida sobre a HRA e solicita a esta a verificação
da ID do usuário. Essa verificação é feita pela HRA por meio do envio de um desafio ao usuário e
confirmação da respectiva resposta (Passos 5.1 e 5.2). O Passo 6 consiste da resposta da HRA para
a RA, indicando se a ID do usuário é válida ou não. Diante dessa confirmação, a RA responde ao
dispositivo se a ID do usuário é válida (Passo 7).
Caso o usuário seja válido, é executada uma etapa de geração de chave de sessão entre o RA
e o usuário, bem como a posterior distribuição dessa chave ao dispositivo. O protocolo de geração
e distribuição de chave de sessão proposto é proprietário. A RA gera uma chave privada para o
dispositivo e o usuário gera a próprias chaves criptográficas. Com base neste material criptográfico,
uma chave de sessão é negociada entre a RA e o usuário (usando ECC – Elliptic Curve Cryptography),
para ser usada entre o usuário e o dispositivo (LIU; XIAO; CHEN, 2012).
O foco principal do trabalho reside na técnica de autenticação do usuário com o dispositivo e
no protocolo de estabelecimento e distribuição de chave de sessão. O modelo de controle de acesso
utilizado é o RBAC. Apesar de tratar da autenticação e autorização de usuários que acessam o
dispositivo, a autenticação e autorização de dispositivos não é abordada. Do mesmo modo, um cenário
M2M também não é tratado pelos autores. Por fim, a proposta não foi implementada e nem avaliada.
3.5 GARDEL ET AL. (2013)
Em Gardel et al. (2013), é utilizado um barramento de serviços4 como infraestrutura de
publicação e descoberta para a WoT. A proposta é prover gestão de autenticação e de autorização da
WoT utilizando o protocolo OpenID Connect.
No barramento de serviços são aplicadas as políticas de controle de acesso aos dispositivos, por
meio de uma aplicação de gerenciamento de acesso que implementa o framework OpenID Connect,
utilizando o modelo de controle de acesso CapBAC. Os serviços da WoT disponibilizados pelo4 Este barramento de serviços está instalado em uma infraestrutura sem restrições computacionais.
60
barramento de serviços como Serviços Web RESTful, são classificados como públicos ou privados.
Serviços públicos podem ser acessados por qualquer aplicação ou usuário, sem necessidade de
autenticação, enquanto que serviços privados precisam da autorização do dono do recurso (GARDEL
et al., 2013).
Caso o usuário queira acessar um serviço de um dispositivo do qual é dono, a requisição é
filtrada pela aplicação de gerenciamento de acesso no barramento e o usuário é redirecionado a uma
página de autenticação em um provedor OpenID Connect, externo ao barramento, para efetuar a
autenticação. Após a autenticação, 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 um token de acesso
temporário, o qual deverá ser incluído em uma nova requisição de acesso (GARDEL et al., 2013).
Caso um usuário deseje acessar um dispositivo de um terceiro, o provedor OpenID Connect
enviará uma notificação de solicitação de acesso ao proprietário do dispositivo. Este poderá fornecer,
ou não, autorização de acesso ao serviço. Caso o proprietário confirme a autorização, a aplicação do
requisitante recebe como resposta um token, o qual poderá ser utilizado temporariamente para acesso
ao serviço (GARDEL et al., 2013).
Apesar de ser um trabalho com foco na WoT, não é tratada da comunicação entre dispositivos
(M2M). Um ponto importante é que o cenário descrito é de uma federação, em que pode-se utilizar um
provedor OpenID Connect que seja confiável tanto para a aplicação de gerenciamento de acesso como
para o usuário requisitante, não estando restrito a um único provedor OpenID Connect. Por fim, um
ponto forte do trabalho é que este foi implementado.
3.6 SEITZ, SELANDER E GEHRMANN (2013)
O trabalho descrito em Seitz, Selander e Gehrmann (2013) apresenta um framework de controle
de acesso com granularidade fina e flexível aos recursos dos dispositivos com restrições computacionais
da IoT, em um cenário M2M. O framework é independente do mecanismo de autenticação e faz uso
do modelo de gestão de políticas de outsourcing, em que a decisão de autorização é tomada por um
servidor menos restrito chamado AE (Authorization Engine), conforme mostrado na Figura 5 (SEITZ;
SELANDER; GEHRMANN, 2013).
Apesar de usar o modelo de outsourcing, a decisão final de autorização ocorre no dispositivo
em que o recurso será acessado. Para isso, o framework faz uso do padrão XACML e, por meio das
XACML Obligations, expressa as condições que devem ser satisfeitas no dispositivo para que a decisão
61
Authorization Engine
Dispositivo
Usuário
Diretório de Recursos
Internet
1
2 2.1
3.13
Figura 5. Arquitetura de autorização proposta em Seitz, Selander e Gehrmann (2013)
Fonte: Adaptada de Seitz, Selander e Gehrmann (2013).
seja válida. Para transportar as decisões de autorização tomadas na AE para o dispositivo, o framework
utiliza asserções baseadas nas asserções SAML de autorização. Também é utilizado um Diretório
de Recursos, o qual mantém descrições de recursos, como informações relevantes à segurança dos
dispositivos (p.e. chave pública e capacidade de processar XACML Obligations localmente) (SEITZ;
SELANDER; GEHRMANN, 2013).
O mecanismo proposto consiste de três etapas, as quais são mostradas na Figura 5. Na primeira
etapa (passo 1), o usuário consulta o Diretório de Recursos e recupera a URI do dispositivo e o AE que
o dispositivo confia. Na segunda etapa (passo 2), o usuário solicita à AE o acesso a um recurso. A AE
roda internamente o protocolo XACML de requisição-resposta para tomar a decisão de autorização
(Passo 2.1). Caso a autorização seja concedida, a AE gera a asserção SAML de autorização. Como
o usuário e o AE são considerados ricos em recursos computacionais, padrões comuns da Internet,
como HTTP e TLS, podem ser utilizados nessa comunicação. A última parte do processo (passo 3) é a
tentativa de acesso do usuário ao dispositivo, fazendo uso da asserção de autorização obtida. Isso é feito
por meio da inclusão da asserção SAML em uma requisição CoAP, a qual é enviada com o payload
encriptado com uma chave conhecida pelo dispositivo (simétrica ou assimétrica), obtida pelo usuário
na etapa de geração da asserção. O dispositivo valida a requisição com a asserção recebida, bem como
verifica se existem XACML Obligations que precisam ser avaliadas (Passo 3.1). Se a validação da
requisição e a avaliação das XACML Obligations for bem sucedida, o recurso é fornecido ao usuário
62
(SEITZ; SELANDER; GEHRMANN, 2013).
Para reduzir o tamanho das respostas XACML e das asserções SAML, foi definido um sub-
conjunto dos dois padrões, visando simplificar o processamento no dispositivo. Também com esse
objetivo, a representação do subconjunto escolhido foi substituída por uma notação em JSON. Essa
escolha permitiu reduzir o tamanho das asserções SAML em aproximadamente dez vezes (SEITZ;
SELANDER; GEHRMANN, 2013).
Um dos pontos positivos do trabalho é que este foi implementado, mostrando-se viável no
dispositivo testado (Arduino Mega 2460). Contudo, a autorização de dispositivos em um cenário M2M
não é tratada. Por fim, a autenticação também não é abordada.
3.7 COMPARAÇÃO DOS TRABALHOS RELACIONADOS
A Tabela 1 mostra a comparação dos trabalhos descritos em diversos aspectos. A coluna
Autenticação/Autorização aponta qual foi o foco principal do trabalho, se foi na autenticação (Aut.) ou
na autorização (Autz.) de dispositivos ou de usuários. A coluna Interoperabilidade de Autenticação
aponta se o trabalho tratou da interoperabilidade entre usuários e dispositivos que utilizam diferentes
mecanismos de autenticação. Nos casos em que a autenticação não foi tratada, esta característica não se
aplica (N/A) ao trabalho. A coluna Modelo de IdM mostra qual foi o modelo de gestão de identidades
utilizado.
A coluna Modelo de Controle de Acesso mostra qual foi o modelo de controle de acesso
utilizado no trabalho. Há trabalhos que tratam somente de autenticação, em que não se aplica (N/A) essa
a característica. Para os trabalhos em que o modelo de controle de acesso utilizado não está explícito
nem implícito, a coluna foi preenchida com "Não define". A coluna Suporte a SSO aponta se o
trabalho abordou a autenticação única para usuários ou para dispositivos na IoT. A coluna Tecnologias
de Autenticação e Autorização aponta quais foram as tecnologias utilizadas no trabalho com foco
específico em autenticação ou autorização de usuários ou de dispositivos.
As colunas Autenticação de Usuários e Autenticação de Dispositivos mostram, respecti-
vamente, se o trabalho abordou a autenticação de usuários e de dispositivos. Nos casos em que o
trabalho não abordou, explicitamente, autenticação, essas características não se aplicam (N/A). A
coluna Implementação mostra se o trabalho foi implementado. A coluna M2M mostra se o trabalho
abordou um cenário de comunicação M2M, em que os dispositivos atuam sem a intervenção humana,
ou seja, de forma autônoma. A coluna WoT mostra se o trabalho apresentou uma abordagem para a
63
Tabela 1. Comparação dos Trabalhos RelacionadosTr
abal
hos
Aut
entic
ação
/A
utor
izaç
ão
Inte
rope
rabi
lidad
ede
Aut
entic
ação
Mod
elo
deId
M
Mod
elo
deC
ontr
ole
deA
cess
o
Supo
rte
aSS
O
Tecn
olog
iasd
eA
uten
ticaç
ãoe
Aut
oriz
ação
Aut
entic
ação
deU
suár
ios
Aut
entic
ação
deD
ispo
sitiv
osIm
plem
enta
ção
M2M
WoT
Akram eHoffmann
(2008c)
Aut. eAutz.
Usuários
Federadoe
Centradono
Usuário
CBAC Usuários
OpenID, SAML,WindowsCardspace,
WS-Security /Trust / Policy /
Federation
X - X - X
Alam,Chowdhury e
Noll (2011)Autz. N/A Federado Independ. N/A Não define N/A N/A X X X
Conzon et al.(2012)
Aut. eAutz.
Usuários Tradic. ACL - TLS e SASL X - X - -
Liu, Xiao e Chen(2012)
Aut. eAutz
- Federado RBAC - OpenID X - - - X
Gardel et al.(2013)
Aut. eAutz.
- Federado CapBAC UsuáriosOpenIDConnect
X - X - X
Seitz, Selander eGehrmann
(2013)Autz. N/A Centraliz.
Nãodefine
-SAML eXACML
N/A N/A X - X
Este Trabalho Aut. eAutz. X Federado Independ. X
SAML,XACML eWS-Policy
X X X X X
Web das Coisas.
A partir do estudo dos trabalhos relacionados, é possível perceber que a autenticação e a
autorização, e consequentemente o controle de acesso no contexto de IoT, são temas relevantes e
abordados na literatura. Também é possível perceber a necessidade de uma infraestrutura que seja
capaz de tratar tanto a autenticação quanto a autorização de usuários e de dispositivos em um ambiente
que envolva múltiplos domínios administrativos, e que possa prover a autenticação única de usuários e
de dispositivos e a interoperabilidade de diferentes mecanismos de autenticação. Também percebe-se
a necessidade de prover mecanismos de autorização flexíveis, capazes de implementar políticas de
autorização flexíveis e diferentes modelos de controle de acesso.
64
Sobre a autenticação de dispositivos da IoT, percebe-se que não há ainda um padrão adotado
pela academia ou pela indústria. A grande heterogeneidade de tecnologias de comunicação, arquiteturas
de hardware e software e mecanismos de autenticação faz com que sejam necessárias abordagens que
permitam a interoperabilidade de dispositivos que utilizam diferentes mecanismos para provar sua
autenticidade. Com isso, seria possível criar uma certa independência de mecanismos de autenticação e,
a priori, cada dispositivo poderia utilizar o mecanismo que melhor atendesse ao seu contexto, podendo
provar sua autenticidade para dispositivos que utilizam mecanismos de autenticação diferentes do seu.
Entretanto, nenhum dos trabalhos abordou a interoperabilidade de mecanismos de autenticação para
dispositivos na IoT. De maneira semelhante, pode-se perceber que a autenticação única de dispositivos
também não foi tratada, bem como não foi provida uma infraestrutura capaz de autenticar tanto usuários
como dispositivos.
Sobre o controle de acesso na IoT, é possível notar que diferentes modelos de controle de acesso
são utilizados, estando estritamente relacionado com os requisitos da aplicação de IoT. Apenas um dos
trabalhos não descreve o modelo de controle de acesso utilizado. Também, apenas um dos trabalhos é
independente de modelo de controle de acesso, contudo o trabalho não aborda a autenticação. Assim,
é reforçada a ideia de que há a necessidade de se prover um mecanismo de controle de acesso flexível,
que permita a implementação de diferentes modelos de controle de acesso.
Dentre os quatro trabalhos baseados no modelo de gestão de identidades federadas, apesar
de todos abordarem cenários de WoT, nenhum tratou da autenticação de dispositivos em um cenário
M2M. Pode-se perceber ainda que três trabalhos fizeram uso do OpenID (ou OpenIDConnect) como
mecanismo de autenticação, enquanto que o trabalho restante não tratou de autenticação.
Cinco trabalhos tiveram abordagens para a WoT e, destes, apenas um abordou um cenário
M2M. Isso pode indicar que as abordagens da literatura tem focado na WoT não para M2M, mas sim
para permitir que o usuário tenha acesso mais fácil aos dispositivos, por meio do uso da plataforma
Web, já bastante difundida e com a qual os usuários estão mais habituados. A maioria dos trabalhos (5)
teve implementação, o que mostra a aplicabilidade dos mecanismos propostos.
Por fim, a Tabela 1 apresenta de forma introdutória o posicionamento deste trabalho em relação
aos trabalhos relacionados que apresentam infraestruturas de autenticação e/ou autorização para a IoT.
65
3.8 CONSIDERAÇÕES
A autenticação e a autorização, tanto de usuários quanto de dispositivos, são aspectos impor-
tantes para garantir a segurança das operações realizadas no contexto da IoT. Garantir que dispositivos
e usuários que utilizam diferentes mecanismos de autenticação possam provar sua autenticidade uns
para os outros, mesmo diante de um cenário com múltiplos domínios administrativos, é um passo
importante para prover a interoperabilidade na IoT. A heterogeneidade de aplicações e de dispositivos
exige que as soluções de controle de acesso sejam capazes de suportar diferentes modelos de controle
de acesso.
Sendo assim, compreender o funcionamento das infraestruturas de autenticação e autorização
para a IoT é um passo importante para a abordagem do problema de pesquisa. Este capítulo apresentou
os trabalhos encontrados na literatura que abordaram infraestruturas de autenticação e autorização para
a IoT. Tais trabalhos serviram de base para a definição e desenvolvimento da infraestrutura proposta.
A AAI proposta e sua integração à uma aplicação de WoT são apresentados em detalhes no
Capítulo 4.
66
4 INFRAESTRUTURA DE AUTENTICAÇÃO E DE AUTORIZA-
ÇÃO PARA A WEB DAS COISAS - AAI4WOT
Este trabalho tem como objetivo prover autenticação e autorização de usuários e de dispositivos
por meio de uma infraestrutura de autenticação e de autorização (Authentication and Authorization
Infrastructure – AAI), chamada de AAI4WoT, alinhada aos requisitos singulares da IoT, que faz uso
dos padrões SAML e XACML.
A AAI4WoT possibilita o uso de diferentes mecanismos de autenticação e de autorização para
usuários e dispositivos. Está fora do escopo deste trabalho conceber novos mecanismos de autenticação
ou de autorização, mas sim tornar a AAI flexível para possibilitar o uso de diferentes mecanismos já
propostos na literatura.
A AAI4WoT proposta tem por objetivo prover segurança para aplicações na WoT sem prejudicar
a interoperabilidade entre os dispositivos. Para isto, a infraestrutura está baseada em padrões abertos e
amplamente aceitos na Internet, como o protocolo HTTP, Serviços Web RESTful, os padrões SAML e
XACML. A AAI4WoT provê a autenticação única de usuários e de dispositivos e permite o uso de
mecanismos de autorização flexíveis.
Este capítulo apresenta a AAI que foi desenvolvida neste trabalho (AAI4WoT). A Seção 4.1
apresenta uma visão geral da AAI4WoT e do cenário em que se apresenta o problema de pesquisa, bem
como algumas das premissas que são assumidas. As funcionalidades e os componentes da AAI4WoT
são descritos na Seção 4.3, sendo seguida pela descrição dos modos de operação da AAI4WoT na
Seção 4.5 e do cliente ativo proposto, na Seção 4.6. A descrição de como a AAI4WoT irá estender
a especificação SAML, de modo a permitir o uso de mecanismos de autenticação como descrito
nos profiles do SAML (OASIS, 2005a), é apresentada na Seção 4.7. Na Seção 4.8, é apresentado o
modelo de ameaças contra a AAI4WoT. Em seguida, a Seção 4.9 apresenta as ferramentas utilizadas
no desenvolvimento da AAI4WoT e como esta foi integrada a uma aplicação de WoT para controle e
monitoramento remoto de máquinas industriais.
67
4.1 CENÁRIO ENVOLVIDO E PREMISSAS
O cenário em que o problema de pesquisa se apresenta é caracterizado pela existência de mais
de um domínio administrativo, sendo que estes domínios pertencem a uma federação1.
Um sistema de gestão de identidades federadas define que em uma federação há uma associação
entre domínios, na qual podem existir diferentes autoridades de autenticação e de atributos (Provedores
de Identidade - Identity Providers - IdPs) e diferentes provedores de serviços (Service Providers -
SPs). Basicamente, cada domínio administrativo é constituído por uma instituição, a qual possui suas
próprias políticas de segurança. Na federação, assume-se a existência de relações de confiança entre
SPs e IdPs dos domínios administrativos.
A AAI4WoT adota o modelo de identidades federadas e o objetivo desta adoção é permitir que
usuários e dispositivos tenham seus dados de identidade (p.e. credenciais e atributos) armazenados e
gerenciados apenas no domínio administrativo ao qual pertencem, mas que estes possam ter acesso a
recursos oferecidos em diferentes domínios (identidades federadas). Neste cenário, cada dispositivo e
usuário de um domínio possui um identificador estabelecido previamente, que o identifica de maneira
única na federação.
A Figura 6 ilustra um cenário em que dois domínios administrativos fazem parte de uma
federação e estão conectados através da Internet. Em um domínio administrativo podem existir
dispositivos com restrições computacionais2 e dispositivos sem tais restrições. Em ambos os casos,
esses dispositivos podem ter um servidor Web embarcado e prover serviços (papel de SP) ou podem
consumir serviços (papel de cliente). Cada domínio administrativo possui um IdP, responsável tanto
pela autenticação de usuários quanto de dispositivos, além de dispositivos que proveem serviços
(SPs) e dispositivos clientes. Na federação, clientes podem acessar serviços disponibilizados por
dispositivos SPs que estejam dentro ou fora de seu domínio administrativo. Este acesso pode ser feito
por um usuário com o auxílio de um navegador Web ou por usuário que utiliza uma aplicação em
um dispositivo cliente. Além disso, estes acessos podem ser feitos a partir de outros dispositivos,
localizados dentro ou fora do domínio administrativo do dispositivo SP, sem que esta ação esteja ligada
a uma intervenção humana. Isso caracteriza uma interação autônoma entre o dispositivo cliente e o
dispositivo SP (comunicação M2M - Machine to Machine).
Os dispositivos e seus serviços embarcados disponibilizam o acesso aos seus recursos por1 Um conjunto composto por provedores de serviço e provedores de identidade que possuem relações de confiança
estabelecidas entre si (CHADWICK, 2009).2 Neste trabalho, sistemas embarcados caracterizam dispositivos com restrições computacionais.
68
DOMÍNIO ADMINISTRATIVO A DOMÍNIO ADMINISTRATIVO B
Modelo de Controle de Acesso: ABAC Modelo de Controle de Acesso: RBAC
IdP-B (AAI)
Wi-Fi
LR-WPAN
IdP-A (AAI)
Usuário AplicaçãoAccess Point
Ethernet
Bluetooth
Ethernet
Dispositivo SPSmart Gateway Dispositivo Cliente
Figura 6. Cenário do Problema de Pesquisa
meio de uma Arquitetura Orientada a Recursos (Resource Oriented Architecture – ROA), fazendo
uso de Serviços Web RESTful. Assim, dispositivos clientes são capazes de fazer requisições aos
dispositivos SPs e IdPs utilizando o protocolo HTTP. Outra característica do cenário assumido é
a heterogeneidade das tecnologias de comunicação que podem ser utilizadas pelos dispositivos da
IoT. Conforme ilustrado na Figura 6, é possível que um determinado domínio suporte mais do que
uma tecnologia de comunicação. Nestes casos, pode ocorrer que alguns dispositivos não suportem a
pilha TCP/IP, sendo que para viabilizar essa conectividade é utilizado um dispositivo intermediário,
chamado Smart Gateway. O Smart Gateway atua como ponte entre estes dispositivos e a Internet, pois
compreende os diferentes protocolos dos dispositivos conectados a este e fornece uma interface para tais
dispositivos se comunicarem com os sistemas finais na Internet (MAHALLE et al., 2010). Um exemplo
pode ser visto na Figura 6. No domínio administrativo A, os dispositivos estão interconectados por meio
dos protocolos de comunicação Wi-Fi, LR-WPAN e Ethernet, enquanto no domínio administrativo B
os protocolos utilizados são Ethernet e Bluetooth.
Na AAI4WoT, de acordo com a necessidade dos dispositivos e usuários de um determinado
domínio, o IdP deste domínio pode prover diversos mecanismos de autenticação que atendam tanto
usuários quanto dispositivos. Além disso, os SPs da federação podem implementar diferentes modelos
de controle de acesso aos recursos dos dispositivos (SPs). Um exemplo disso por ser visto na Figura 6,
69
em que os SPs do domínio A adotam o modelo de controle de acesso baseado em atributos (Attribute
Based Access Control – ABAC), enquanto que os SPs do domínio B utilizam o modelo de controle de
acesso baseado em papéis (Role Based Access Control – RBAC).
Diante do cenário apresentado, as seguintes premissas são assumidas neste trabalho:
• A AAI4WoT (IdPs e componentes de autorização) e os SPs não estão comprometidos;
• Os dispositivos SPs possuem um hardware resistente à violação (Trusted Platform Module -
TPM), o qual dá suporte às operações envolvendo as credenciais desses dispositivos;
• Os dispositivos clientes, quando utilizam um mecanismo de autenticação envolvendo o uso
de chaves criptográficas, possuem um hardware TPM;
• As informações de identidade de usuários e de dispositivos estão cadastradas em uma base
de dados acessível ao IdP do domínio, considerada segura e confiável.
4.2 VISÃO GERAL DA AAI4WOT
Para a troca de dados de autenticação de usuários e de dispositivos, foi utilizado o padrão SAML.
Cada domínio administrativo da federação possui a AAI4WoT que pode ser utilizada para prover a
autenticação e contribuir com o controle de acesso de serviços disponibilizados pelos dispositivos
na WoT. A AAI4WoT adota o padrão XACML para expressar políticas de controle de acesso e
como formato para descrição de requisições e respostas de decisão de autorização, visando o uso de
mecanismos de autorização flexíveis.
O SAML, como mencionado na Seção 2.2.4.1, é um padrão baseado em XML (eXtensible
Markup Language) para a descrição e troca de asserções de segurança entre parceiros de negócio na
Internet. O SAML permite, dentre outras coisas, a autenticação única (Single Sign On - SSO) entre
múltiplos domínios administrativos, provendo suporte a alguns mecanismos de autenticação, sendo
uma das principais tecnologias que possibilita a gestão de identidades federadas (OASIS, 2008).
Conforme mencionado na Seção 2.2.4.2, o XACML é uma linguagem também baseada em
XML para a descrição de políticas de autorização e para requisição/resposta de decisões de autorização.
O XACML, um padrão OASIS3), é genérico. Isso significa que o XACML é independente de modelo
de controle de acesso. O XACML também pode ser distribuído, ou seja, é possível que uma política de3 https://www.oasis-open.org/
70
autorização faça referência a outras políticas, localizadas em locais arbitrários, construindo uma única
decisão de autorização. Outro ponto importante é a fácil integração do XACML com o SAML, já que
existem diversos perfis e extensões que tratam da interoperabilidade entre os dois padrões (OASIS,
2003).
A AAI4WoT é disponibilizada por meio de Serviços Web RESTful. Conforme analisado no
Capítulo 2, o uso de Serviços Web RESTful é mais adequado para a WoT do que o uso de Serviços
Web arbitrários ou WS-*. O aspecto leve do REST possibilita que dispositivos restritos ofereçam seus
serviços na Web. As características que colaboram para esta visão são a baixa complexidade do REST,
o baixo acoplamento das interações sem estado e sua alta flexibilidade (ZENG; GUO; CHENG, 2011).
Enquanto os Serviços Web arbitrários demandam mais recursos em termos de poder de processamento,
largura de banda e armazenamento, o REST promove a reutilização de padrões Web, permitindo uma
interação direta do cliente com o serviço, sem a necessidade de interpretar uma WSDL ou utilizar
APIs adicionais para interagir com um serviço específico. Assim, em função da simplicidade, leveza e
interfaces uniformes promovidas pelo REST, o paradigma de Serviços Web RESTful é preferido na
WoT (GUINARD et al., 2009; HAMESEDER; FOWLER; PETERSON, 2011).
DOMÍNIO ADMINISTRATIVO A
Infraestrutura de Autenticação e
Autorização para WoT (AAI4WoT)
Infraestrutura de Autenticação e
Autorização para WoT (AAI4WoT)
DOMÍNIO ADMINISTRATIVO B
Dispositivo Provedor de Serviço (SP)
DispositivoClienteRequisição de Serviço + SAML
SAMLXACML
HTTP
1
2
3
Figura 7. Visão Geral da AAI4WoT - Cenário M2M
A Figura 7 apresenta uma visão geral da AAI4WoT. A infraestrutura proposta, quando neces-
sário, pode retirar grande parte da carga computacional do dispositivo SP, referente às funções de
autorização de acesso ao serviço. Em função disso, a AAI é executada em um ambiente sem restrição
71
de recursos computacionais4. Conforme a Figura 7, a AAI4WoT no domínio do SP visa auxiliar as
operações de autenticação e de autorização. No domínio do cliente, a AAI4WoT inclui um IdP no qual
usuários e dispositivos devem se autenticar.
A Figura 7 mostra ainda as trocas de mensagens, em alto nível, realizadas entre os componentes
da AAI4WoT e o cliente, que visa autenticar o dispositivo cliente e autorizar o acesso ao recurso dispo-
nibilizado pelo SP. As trocas de mensagens do dispositivo cliente com a AAI4WoT, para autenticação
do dispositivo cliente, ocorrem usando o protocolo SAML sobre o protocolo HTTP (Passo 1). Após
autenticado na infraestrutura de seu domínio, o cliente envia ao SP mensagens HTTP que contém,
além da requisição, uma asserção SAML de autenticação (Passo 2). Já as trocas de mensagens entre o
SP e a AAI4WoT para requisição/resposta de decisões de autorização, ocorrem usando mensagens em
formato XACML encapsuladas em mensagens HTTP (Passo 3). Todas as trocas de mensagens são
feitas sobre um canal de comunicação seguro, implementado por meio do TLS, com o objetivo de
garantir a autenticidade, integridade e confidencialidade dos dados trocados.
4.3 COMPONENTES E FUNCIONALIDADES DA AAI4WOT
A Figura 8 ilustra os componentes da AAI4WoT para lidar com as responsabilidades de
autenticação e de autorização. É importante ressaltar que cada domínio administrativo possui sua
própria AAI4WoT, conforme ilustrado na Figura 8. Os componentes são descritos a seguir:
• Provedor de Identidade (IdP): atua como autoridade de autenticação, sendo responsável por
autenticar usuários e dispositivos. Atua também como autoridade de atributos, sendo capaz
de gerar asserções sobre os atributos dos usuários e dos dispositivos autenticados. Também
possui a lista dos IdPs que este confia e é responsável por validar as asserções SAML
assinadas com base nas relações de confiança pré-estabelecidas na federação (autenticação
no outro domínio de segurança);
• PEP (Policy Enforcement Point): a entidade do sistema de autorização responsável por
requisitar decisões de controle de acesso ao PDP e aplicar tais decisões (OASIS, 2013a);
• PDP (Policy Decision Point): a entidade do sistema de autorização que, diante de uma
requisição de decisão de autorização, avalia as políticas aplicáveis (fornecidas pelo PAP)4 Neste trabalho, quando é mencionado um ambiente sem restrição de recursos computacionais, o autor refere-se a um
ambiente com características computacionais bem menos severas do que as dos dispositivos da Internet das Coisas. Umambiente sem restrições computacionais é caracterizado neste trabalho por um ambiente de Computação em Nuvem.Contudo, deve-se ressaltar que utilizar um ambiente de Nuvem não é uma premissa.
72
DOMÍNIO ADMINISTRATIVO
Cliente Ativo
Dispositivo Cliente
AAI4WoT
Dispositivo Provedor de Serviço (SP)
PAP PIP IdPPDP
PEP
Figura 8. Componentes da AAI4WoT
e as informações disponíveis (fornecidas pelo PIP) e toma uma decisão de autorização
(OASIS, 2013a);
• PAP (Policy Administration Point): a entidade do sistema de autorização que cria políticas
ou conjuntos de políticas (ou por meio da qual um administrador de sistemas cria as políticas)
e as disponibiliza ao PDP, quando da necessidade de tomar uma decisão de autorização
(OASIS, 2013a);
• PIP (Policy Information Point): a entidade do sistema de autorização que possui (ou sabe
como encontrar) as informações que são necessárias para a tomada de decisão de autorização,
feita pelo PDP. Tais informações são avaliadas diante das políticas de autorização e podem
ser, por exemplo, o status do recurso, estado de sessão e horário (OASIS, 2013a);
• Cliente Ativo SAML: O dispositivo cliente faz uso deste componente de software que
auxilia no uso da AAI. Caso o cliente seja um usuário que deseja acessar o dispositivo
SP por meio de um navegador Web, o Cliente Ativo SAML irá atuar como um proxy.
Caso o cliente seja um dispositivo, o Cliente Ativo SAML é um componente de software
(biblioteca), que implementa o padrão SAML e que pode ser acessado via API para facilitar o
uso da AAI4WoT para os desenvolvedores do software embarcado do dispositivo. O Cliente
73
Ativo SAML, ao invés de ser um cliente ativo conforme preconizado pela especificação
SAML, que deve necessariamente implementar o protocolo SOAP e o SOAP Reverso5, o
componente proposto usa estritamente o protocolo HTTP, conforme os princípios REST. O
Cliente Ativo SAML auxilia as trocas de mensagens entre o cliente e o IdP e entre o cliente
e o SP, visando viabilizar a troca de mensagens SAML no cenário de WoT com Serviços
Web RESTful. O Cliente Ativo SAML é o responsável por buscar a política de qualidade
de proteção do SP (que define os requisitos de segurança que o cliente deve atender para
ter acesso ao recurso oferecido pelo SP) e por montar a requisição de autenticação para o
cliente, no padrão SAML. Também é tarefa do Cliente Ativo SAML anexar a asserção SAML
recebida do IdP nos pedidos a serem enviados para o SP (no cabeçalho das mensagens
HTTP).
A AAI4WoT garante a autenticação única de dispositivos e de usuários na WoT, uma vez que
permite que usuários e dispositivos se autentiquem e recebam uma asserção SAML referente ao evento
de autenticação realizado. Esta asserção SAML pode ser usada pelo cliente dentro da federação para
acesso a serviços fornecidos pelos SPs, sem que nova autenticação seja necessária para consumo de
diferentes serviços da federação. Nos componentes PDP, PIP, PAP e PEP, as trocas de mensagens são
requisições/respostas segundo o padrão XACML.
4.4 ETAPA DE REGISTROS E DE ESTABELECIMENTO DE RELAÇÕES DE
CONFIANÇA
Para que clientes e dispositivos possam fazer uso da AAI4WoT, uma etapa de registros e de
estabelecimento de relações de confiança precisa ser realizada. Esta etapa compreende os processos de:
(i) registro dos domínios de segurança, (ii) estabelecimento das relações de confiança entre os IdPs dos
domínios de segurança e (iii) registro dos clientes (usuários e dispositivos) e dos dispositivos SPs no
IdP do domínio correspondente.
O processo de registro de um domínio de segurança deve ser executada por todos os domínios
de segurança que farão parte da federação. Este processo consiste de dois passos:
1. Registro do domínio: nesta etapa, o domínio de segurança é registrado na estrutura de DNS
da Internet e pode ser acessado por meio de uma URL (p.e. http://dominioa.com); e5 O uso do SOAP Reverso faz com que seja necessário que o SP e o IdP também suportem o protocolo SOAP
74
2. Registro da AAI: nesta etapa, os componentes da AAI4WoT são registrados na estrutura de
DNS do domínio local. Assim, os componentes da AAI podem ser acessados por meio de
uma URL de acordo com a seguinte estrutura http://componente.aai.dominioa.com).
O processo seguinte consiste no estabelecimento das relações de confiança entre os IdPs dos
domínios de segurança que fazem parte da federação. Assume-se que estes IdPs possuam certificados
digitais emitidos por CAs (Certificate Authority - Autoridades Certificadoras) confiáveis no contexto
da federação. Este processo consiste dos seguintes passos:
1. Estabelecimento de um canal seguro: é estabelecido um canal seguro TLS mutuamente
autenticado entre os dois IdPs; e
2. Troca de metadados: é realizada a troca de metadados entre os IdPs, usando o mecanismo de
publicação e resolução de metadados chamado Well-Known Location, definido em OASIS
(2009c).
Os metadados dos IdPs devem estar no formato de metadados definido na especificação SAML
2.0, conforme descrito em OASIS (2009c), o qual é baseado em XML. O mecanismo de publicação e
resolução de metadados Well-Known Location define que uma entidade deve publicar seus metadados
em um local acessível por meio de uma URL, a qual deve ser definida por meio de seu identificador
único (p.e. http://idp.dominioa.com). A resolução dos metadados, quando o mecanismo Well-Known
Location é utilizado, pode ser feita pela simples resolução da URL por meio da qual o documento de
metadados é acessível.
No documento de metadados, é possível publicar as informações de segurança necessárias para
estabelecer as relações de confiança entre os IdPs. Por exemplo, é possível incluir as informações dos
certificados digitais que podem ser usados pelos IdP ao assinarem as asserções SAML geradas. Assim,
quando o cliente apresentar ao SP uma asserção SAML gerada e assinada por um dado IdP, o IdP do
domínio do dispositivo SP pode verificar se foi realmente o IdP com o qual este tem uma relação de
confiança que assinou a asserção.
O processo seguinte consiste no registro dos clientes no IdP do domínio do qual fazem parte.
Esta etapa pode variar conforme a entidade que deseja se registrar, a qual pode ser um dispositivo SP,
um dispositivo cliente ou ainda um usuário cliente.
Para o caso do registro de um dispositivo SP na AAI4WoT de seu domínio, a sequência de
75
passos a ser executada é mostrada na Figura 9 e descrita a seguir:
1. Geração de certificado digital temporário para o SP: com apoio do administrador do IdP, o
IdP gera um certificado digital auto-assinado, o qual é inserido manualmente no SP antes
de sua instalação. Esse certificado é utilizado apenas para a etapa de registro e só pode ser
utilizado uma vez.
2. Conexão do dispositivo SP com o IdP: após instalado, o dispositivo SP estabelece um canal
seguro com o IdP, mutuamente autenticado e baseado no protocolo TLS;
3. Envio de informações do SP: o dispositivo SP envia ao IdP um documento WADL (Web
Application Description Language), o qual provê uma descrição dos Serviços Web RESTful
oferecidos pelo SP. O SP também envia ao IdP a sua política de qualidade de proteção no
formato WS-Policy;
4. Registro do SP: o IdP gera um identificador único na federação para o dispositivo e registra-
o no DNS local. O IdP envia esse identificador único ao dispositivo SP e armazena em sua
base a WS-Policy;
5. Emissão de certificado do SP: O SP gera um par de chaves (uma pública e outra privada) e
solicita para uma CA (válida no contexto da federação) a emissão de um certificado digital,
que será utilizado para estabelecer as conexões TLS (em que o SP é autenticado) com os
demais componentes durante o funcionamento da AAI. A CA emite o certificado e envia ao
SP; e
6. Criação da política de controle de acesso do Dispositivo SP: o administrador do sistema
cria políticas de controle de acesso para os recursos do dispositivo SP, por meio de uma
aplicação no PAP.
Para o caso do registro de um dispositivo cliente no IdP de seu domínio, a sequência de passos
a ser executada é descrita a seguir:
1. Conexão do dispositivo cliente com o IdP: o dispositivo cliente estabelece um canal seguro
com o IdP via protocolo TLS; e
2. Registro do Dispositivo: o dono do dispositivo cliente registra o dispositivo e, de acordo
com o mecanismo de autenticação utilizado, recebe material criptográfico gerado pelo
76
DOMÍNIO ADMINISTRATIVO A
Dispositivo Provedor de Serviço (SP)
AAI4WoT
2
4
IdP
3 4
Serviço de Diretório
Administrador
PAP
6
CA
5
DNS
4
1
1
Figura 9. Etapa de Registro do Dispositivo SP
IdP (p.e. chaves criptográficas ou certificado digital). O IdP armazena as informações
necessárias para a autenticação em um serviço de diretório e envia ao dispositivo cliente um
identificador único do dispositivo.
Para o registro de um usuário como cliente no IdP de seu domínio, o processo de registro é
realizado por meio do navegador Web pelo administrador do IdP. O processo a ser executado é descrito
a seguir:
1. Registro do Usuário: o administrador do IdP registra o usuário, informando ao IdP (uma
aplicação Web de cadastro) os dados cadastrais e o certificado digital do usuário, que deve
ter sido assinado por uma AC válida no contexto da federação e ter sido enviado para o
administrador do IdP previamente, através de um canal seguro TLS. O identificador e os
atributos dos usuários são armazenados em um serviço de diretório.
77
4.5 MODOS DE OPERAÇÃO DA AAI4WOT
A AAI4WoT possui dois modos de operação, que existem em função das possíveis diferenças
em relação à capacidade computacional do SP. Os dois modos de operação são descritos a seguir:
1. Modo de Operação SP Restrito: SP com restrição computacional o que torna custosa a
tomada de decisão de autorização no próprio dispositivo; e
2. Modo de Operação SP sem Restrição: SP com recursos computacionais suficientes para
executar todos os componentes de autorização da AAI4WoT, sendo capaz de tomar a
decisão de autorização no dispositivo.
4.5.1 Modo de Operação SP Restrito
No modo de operação SP Restrito, a AAI4WoT, no domínio do SP, possui os seguintes
componentes: PDP, PIP, PAP e o IdP. O IdP tem as funções de autenticar os clientes do respectivo
domínio e validar as asserções SAML assinadas por IdPs de dispositivos clientes. Nesse modo, o SP
é responsável pelo provimento do serviço e por desempenhar as funcionalidades de PEP (aplicar a
decisão de autorização tomada pelo PDP).
Conforme ilustrado na Figura 10, a AAI4WoT é uma infraestrutura distribuída, composta de
duas partes: uma disponibilizada como Serviços Web (contemplando o PDP, PIP, PAP e um IdP) e
outra que deve ser embarcada em cada dispositivo para que estes possam fazer uso das funcionalidades
de autenticação e de autorização da AAI4WoT. A parte embarcada trata da implementação do PEP no
lado do dispositivo SP e do Cliente Ativo SAML no lado do dispositivo cliente.
Como pode ser visto na Figura 10, o modelo de controle de políticas escolhido foi o de
outsourcing (MOORE et al., 2001). Neste modelo, a solicitação de acesso recebida pelo guardião do
serviço, o PEP, é encaminhada a um PDP externo para tomada de decisão de autorização. Esta tomada
de decisão é feita com base na asserção SAML resultante do processo de autenticação do cliente e na
política de controle de acesso do dispositivo SP. O PEP é responsável por receber e aplicar a decisão
tomada pelo PDP, liberando ou bloqueando o acesso ao serviço protegido.
Vale ressaltar que todas as trocas de mensagens mostradas na Figura 10 são feitas sobre um
canal seguro implementado via protocolo TLS. As trocas ocorrem conforme descrito a seguir:
78
DOMÍNIO ADMINISTRATIVO A DOMÍNIO ADMINISTRATIVO B
Dispositivo Cliente
AAI4WoT
1
6
15
Dispotisivo Provedor de Serviço (SP)
PAP PIP
IdP PDP
Cliente AtivoPEP
9
Componentes Propostos
Tráfego HTTP sobre TLSTráfego SAML sobre
HTTP sobre TLSTráfego XACML sobre
HTTP sobre TLSCertificado
Digital
2
10 - 13
78 14
AAI4WoT
PAP PIP
IdP PDP
5 4 3
Figura 10. AAI4WoT - Modo de Operação SP Restrito
• Passo 1: O cliente, por meio do Cliente Ativo SAML, obtém a política de qualidade de
proteção (WS-Policy) do SP que encontra-se vinculada (attached) ao serviço provido;
• Passo 2: O Cliente Ativo SAML monta uma requisição de autenticação com base na política
recebida;
• Passo 3: O Cliente Ativo SAML envia a requisição de autenticação para o IdP (requisição
SAML);
• Passo 4: Ocorre as trocas de mensagens entre o IdP e o Cliente Ativo, necessárias no
processo de autenticação do cliente, de acordo com o mecanismo de autenticação suportado
no IdP;
• Passo 5: Caso a autenticação seja bem-sucedida, o IdP responde ao Cliente Ativo com uma
asserção SAML assinada de acordo com o que foi solicitado pelo Cliente Ativo. Caso a
autenticação falhe, o IdP informa a falha de autenticação ao Cliente Ativo;
79
• Passo 6: O Cliente Ativo SAML requisita ao SP o serviço desejado pelo cliente e envia
junto com a requisição a asserção SAML gerada pelo IdP;
• Passo 7: O PEP recebe a requisição do cliente e solicita ao IdP do domínio do dispositivo a
validação da asserção SAML recebida;
• Passo 8: O IdP responde ao PEP indicando se a asserção SAML é válida (confiável) ou não;
• Passo 9: Caso a asserção SAML sejá confiável, o PEP cria e envia ao PDP uma requisição
de decisão de autorização no formato XACML, tendo como base a requisição do cliente e a
asserção SAML recebida;
• Passos 10-13: Diante da requisição e das políticas de controle de acesso aplicáveis, o PDP
toma a decisão de autorização (detalhamento das trocas de mensagens é mostrado na Figura
11);
• Passo 14: O PDP responde para o PEP com a decisão de autorização tomada, usando para
isso uma mensagem no formato XACML; e
• Passo 15: O PEP aplica a decisão de autorização. Caso o acesso seja autorizado, o SP
responde ao cliente com o recurso desejado, caso contrário responde com um erro HTTP.
O XACML não define protocolos para troca de mensagens entre os componentes de autorização,
apenas a linguagem de descrição de políticas e de descrição das mensagens de pedido e resposta
de pedido de autorização. As trocas de mensagens entre os componentes da AAI4WoT (PEP, PDP,
PIP e PAP) são feitas por meio do protocolo HTTP pois, como mencionado, todos os recursos de
autorização da AAI4WoT são providos por meio de Serviços Web RESTful. A troca de mensagens
entre os componentes de autorização, omitida na Figura 10, é mostrada na Figura 11 e descrita a seguir:
• Passo 10: O PDP verifica com o PAP a existência de políticas de autorização mais novas do
que aquelas que o PDP mantém localmente;
• Passo 11: O PAP responde ao PDP com as novas políticas, caso estas existam;
• Passo 12: Caso necessário, o PDP solicita ao PIP informações adicionais para a tomada de
decisão, como informações do recurso, data e hora e condições específicas do ambiente de
rede;
• Passo 13: O PIP responde ao PDP com as informações solicitadas; e
80
DOMÍNIO ADMINISTRATIVO A
AAI4WoT
PDP
Tráfego XACML sobre HTTP sobre TLS
CertificadoDigital
PIP PAP11
10
12
13
Figura 11. Fluxo de mensagens de autorização no modo de operação SP Restrito
• Passo 14: O PDP toma a decisão de autorização e a envia ao PEP (passo 14 da Figura 10).
4.5.2 Modo de Operação SP Sem Restrições
No segundo modo de operação, o SP tem recursos computacionais suficientes para tomar as
decisões de autorização por conta própria. Ou seja, o SP não precisa mais delegar à uma parte externa
a tomada de decisão de autorização referente aos acessos aos serviços que disponibiliza.
Neste caso, a visão geral da AAI4WoT da Figura 7 pode ser especificada de acordo com a
Figura 12. Neste modo de operação, os componentes responsáveis pelas funcionalidades relacionadas
à autorização (PEP, PDP, PIP e PAP) estão todos no SP. A agregação de componentes de autorização
no SP é feita pois as atividades de autorização estão estritamente ligadas com o fornecimento do
serviço aos clientes. Neste caso, utiliza-se o modelo de controle de políticas provisioning, em que os
mecanismos de decisão e aplicação da decisão de autorização (enforcement) são locais, o que elimina
o acoplamento externo e aumenta a robustez da arquitetura diante de falhas de comunicação. O único
componente que fica fora do SP é o IdP, responsável pelas operações relacionadas à autenticação
dos clientes do domínio administrativo e pela validação de assinaturas digitais das asserções SAML
recebidas.
4.6 CLIENTE ATIVO SAML
Esta seção apresenta um detalhamento das funções do Cliente Ativo SAML. Uma das funci-
onalidades deste componente é buscar a política de qualidade de proteção do serviço que o cliente
deseja acessar. Logo, quando o cliente indicar qual serviço de um provedor de serviços deseja acessar,
o Cliente Ativo SAML deve primeiramente buscar pela respectiva política de qualidade de proteção
81
DOMÍNIO ADMINISTRATIVO A
Provedor de Identidade (IdP)
DOMÍNIO ADMINISTRATIVO B
Dispositivo Cliente1
6
10Dispositivo
Provedor de Serviço (SP)
PAP
PIP
PDP
Cliente Ativo
PEP
2
9
CertificadoDigital
Componentes PropostosTráfego SAML sobre
HTTP sobre TLSTráfego HTTP sobre TLS
87
AAI4WoT
PAP PIP
IdP PDP
345
Figura 12. AAI4WoT - Modo de Operação SP Sem Restrições
deste serviço. Essa política contém regras que definem, por exemplo, os mecanismos de autenticação
aceitos pelo SP e as informações que o SP precisa ter sobre o cliente para que possa tomar uma decisão
de autorização acerca da requisição de acesso ao serviço.
De posse da política de qualidade de proteção do serviço, o Cliente Ativo SAML auxilia o
cliente no fornecimento de tais informações para o SP, que normalmente incluem a prova de identidade
do cliente. Para isto, o Cliente Ativo SAML deve interpretar a política de qualidade de proteção
recebida. A maneira utilizada neste trabalho para a prova de identidade do cliente é a autenticação
em um IdP SAML que o SP confie, o qual atua como autoridade de autenticação e autoridade de
atributos. Assim, quando um IdP autentica um cliente este atesta, por meio de uma asserção SAML,
quais atributos o cliente possui.
O Cliente Ativo SAML é responsável por montar as requisições de autenticação no padrão
SAML que atenda aos requisitos indicados pelo serviço em sua WS-Policy, usando o protocolo SAML
Authentication Request Protocol.
82
Caso a autenticação seja bem sucedida, o Cliente Ativo SAML recebe do IdP uma asserção
SAML contendo uma sentença (statement) que descreve como o cliente se autenticou. Essa asserção
pode conter também sentenças relativas com os atributos do cliente que são atestados (assinados) pelo
IdP. O Cliente Ativo SAML é responsável ainda por inserir nas requisições de acesso ao serviço a
asserção SAML (no cabeçalho da mensagem HTTP).
4.7 USO DE MECANISMOS DE AUTENTICAÇÃO DA IOT COM O SAML
Conforme descrito na Seção 2.2.4.1, muitos parâmetros são utilizados na especificação SAML
para definir um contexto de autenticação, o qual é descrito por meio de uma Authentication Context
Declaration. Em função dessas variações, a especificação define diversas Authentication Context
Classes de modo a agregar contextos de autenticação similares, além de prever extensões para que
novas Authentication Context Classes possam ser definidas. Isso faz com que o SAML seja agnóstico
ao mecanismo de autenticação utilizado.
Alguns contextos de autenticação de dispositivos e de usuários para a IoT não estão definidos
na especificação SAML e, portanto, demandam do uso das extensões previstas para que possam ser
representados em asserções SAML. Este é o caso do contexto de autenticação de dispositivos utilizado
no protótipo desenvolvido como prova de conceito da infraestrutura, bem como os contextos dos
mecanismos descritos em Mahalle et al. (2012), Nguyen, Al-Saffar e Huh (2010), Hanumanthappa e
Singh (2012), Konidala et al. (2005) e Fu, Jing e Sun (2011).
Devido a isto, a especificação SAML foi estendida para representar o mecanismo de auten-
ticação de dispositivos utilizado no protótipo da AAI4WoT. O mecanismo é baseado no acordo de
chaves autenticado não-interativo Sakai-Ohgishi-Kasahara, descrito em Sakai, Ohgishi e Kasahara
(2000). Este é um criptossistema baseado em identidades, no qual a chave pública da entidade é
calculada com base em um parâmetro público de sua identidade. As etapas e trocas de mensagens que
compõe o mecanismo são mostradas na Figura 13. Na inicialização do sistema, o IdP gera uma chave
mestra (s), única, aleatória e secreta. Com base nesta chave, em uma função hash pública (H1) e em
um parâmetro público da identidade do IdP (IDidp), o IdP gera sua chave privada (sPidp). Para os
dispositivos clientes, as chaves privadas (sPcli) são geradas pelo IdP também com base na chave mestra
e em um parâmetro público da identidade do dispositivo (IDcli), mas durante a fase de registro do
dispositivo. Para a autenticação, o IdP gera uma chave de sessão (SK) com base na sua chave pública
(Pidp) e privada (sPidp) e com base na chave pública do dispositivo (Pcli). Essa chave de sessão serve
para criptografar um número aleatório r gerado pelo IdP, usando o algoritmo AES_256, compondo
83
IdP Cliente
Inicialização
Gera s
Registro
Gera sPcli
IDcli
IDcli
sPcli
PIdP = H1(IDIdP)
Gera sPIdP
Autenticação
IDcli
Pcli = H1(IDcli)
Pcli = H1(IDcli)
SK = e(sPIdP, PIdP, Pcli)
Gera r
R = SK(r)
R
SK(R) = r’
SK = e(sPcli, Pcli, PIdP)
R’ = SK(r’-1)
R’
r’’ = SK(R’)
SE r’’ == r-1 : aut. ? não aut.
Figura 13. Etapas e trocas de mensagens do mecanismo de autenticação de dispositivos
84
o challenge (R) do protocolo de challenge-response descrito em Needham e Schroeder (1978). Ao
receber o challenge, o dispositivo cliente deve calcular a mesma chave de sessão calculada pelo IdP
(SK), com base em sua chave pública (Pcli) e privada (sPcli) e na chave pública do IdP (Pidp). Essa
chave de sessão é utilizada para descriptografar o challenge (r’). Após descriptografado, o dispositivo
calcula r’-1 e criptografa o resultado com a chave de sessão, que compõe o response (R’). Ao receber o
response, o IdP o descriptografa e verifica o resultado (r”) e, se r” for igual a r-1, o dispositivo cliente
está autenticado.
A extensão à especificação SAML foi feita por meio de um XML Schema Definition (XSD)
que restringe o uso do XSD da especificação SAML. O XSD define os elementos de um documento
XML válido para a descrição de um evento de autenticação que utilizou o mecanismo de autenticação
de dispositivos. Este XSD está descrito no Apêndice C.
4.8 MODELO DE AMEAÇAS
Um modelo de ameaças descreve o quê um atacante é capaz de fazer contra um recurso ou
sistema. Este deve conter informações acerca da capacidade computacional do atacante, as informações
que este possui e o controle que detém do sistema. Um modelo de ameaças possui dois propósitos: (i)
identificar as ameaças que o sistema está suscetível e (ii) definir quais ameaças estão não são tratadas
(fora do escopo) (RESCORLA; KORVER, 2003).
Para definição do modelo de ameaças das aplicações que farão uso da infraestrutura proposta,
tomou-se como base (i) o modelo de ameaças da Internet, descrito em Rescorla e Korver (2003) e (ii)
as considerações de segurança da especificação SAML, descritas em OASIS (2005b). A seguir, são
descritas as premissas que são assumidas para a construção do modelo:
• Um atacante possui muitos recursos computacionais;
• O canal de comunicação é inseguro (pode ser atacado);
• Os protocolos de segurança utilizados foram implementados corretamente; e
• São usados protocolos de criptografia forte.
Com base nas considerações de segurança da especificação SAML (OASIS, 2005b), as quais
assumem como modelo de ameaças o modelo da Internet descrito em Rescorla e Korver (2003), a
85
maneira como o processo de autenticação é realizado é considerada fora do escopo do modelo de
ameaças da AAI4WoT. A especificação SAML permite que declarações sejam criadas sobre processos
de autenticação, mas não impõe requisitos ou especificações sobre como é realizado o processo em si.
Logo, declarações acerca deste processo serão emitidas, mas fica a cargo do receptor dessa asserção
avaliar o quanto pode confiar no processo de autenticação realizado pelo IdP.
A seguir, são descritas as ameaças que foram identificadas para a AAI4WoT, com base nas
ameaças descritas em Rescorla e Korver (2003), OASIS (2005b), Babar et al. (2010), Babar et al.
(2011) e Covington e Carskadden (2013) e as medidas que são tomadas para eliminar ou mitigar tais
ameaças:
• Comprometimento da autenticidade das partes comunicantes e comprometimento da confi-
dencialidade e integridade dos dados em trânsito;
– Esta ameaça é mitigada pelo o uso de um canal seguro estabelecido com o protocolo
TLS para troca de mensagens;
• Comprometimento da autenticidade e integridade no nível de mensagem SAML. No cenário
em questão, esta é uma ameaça à mensagem SAML que contém a asserção SAML. É uma
ameaça pois a asserção SAML não é enviada diretamente do IdP para o SP, mas sim do IdP
para o cliente e do cliente para o SP. Assim, há a ameaça de que o próprio cliente (caso este
seja malicioso) comprometa a integridade e autenticidade da asserção SAML;
– Esta ameaça é mitigada (i) pelo o uso do XML Signature (EASTLAKE et al., 2008)
pelo IdP ao gerar mensagens de protocolo e asserções SAML assinadas e (ii) pelo
timestamp, tempo de validade e indicação do SP alvo das mensagens, uma vez que as
mensagens e asserções podem ser utilizadas apenas em um SP específico e por um
curto período de tempo;
• Roubo de credenciais quando em trânsito pela rede (comunicação entre dispositivo cliente e
IdP/SP);
– Esta ameaça é mitigada pelo uso de um canal seguro criptografado entre as partes;
• IP Spoofing ou MAC Spoofing, caracterizado quando um atacante cria um pacote IP ou
quadro com endereço de origem de outro sistema final;
86
– Esta ameaça é mitigada pelo fato de que é necessário, no caso dos servidores, que
estes sejam autenticados utilizando certificados digitais (autenticação do protocolo
TLS). No caso do cliente, este precisa provar sua identidade para um IdP para então
poder receber a asserção SAML. Deste modo, o IP Spoofing ou MAC Spoofing não
são suficientes para forjar a identidade do cliente;
• Ataque de Repetição de Mensagens (Replay Attack), caracterizado quando o atacante envia
ao receptor uma sequência de mensagens que já foi enviada anteriormente;
– Esse ataque é mitigado pelo uso de um canal seguro estabelecido com o protocolo
TLS e pelo timestamp e tempo de validade das mensagens SAML;
• Ataque de Inserção de Mensagens, caracterizado quando o atacante forja uma mensagem e
a injeta na rede, normalmente forjando também o endereço de origem da mensagem;
– Este ataque é mitigado pelo uso de um canal seguro autenticado estabelecido usando
o TLS. O uso do canal seguro inviabiliza a inserção de mensagens maliciosas sem a
percepção do receptor;
• Ataque Man-in-the-Middle, em que o atacante fica entre o cliente e o servidor (IdP, SP ou
qualquer outro componente da AAI) sem ser percebido por ambos;
– Este ataque é mitigado por meio do uso de um canal seguro, usando TLS (conforme
descrito em Rescorla e Korver (2003));
• Acesso físico ao dispositivo, levando à ameaça de acesso indevido às credenciais do
dispositivo, como a chave privada do certificado digital no caso do SP e as credenciais de
autenticação no caso do cliente;
– Esta ameaça é mitigada pelo uso de hardware TPM no dispositivo SP e no dispositivo
cliente (quando este realiza operações com chaves criptográficas). Deste modo, as
operações que envolvem o uso das credenciais são feitas no hardware TPM;
• Ataque de negação de serviço no dispositivo SP;
– O fato do SP não precisar manter uma sessão HTTP aberta enquanto o cliente faz
a autenticação no IdP SAML evita que o SP tenha seus recursos esgotados em uma
operação normal com muitos clientes. Porém, este ataque ainda é possível. A solução
proposta não trata ataques de negação de serviço, uma vez que tratar esse tipo de
ataque demanda o emprego de mecanismos que estão fora do escopo deste trabalho.
87
• Ataque de negação de serviço na AAI4WoT;
– Pelo mesmo motivo que o caso anterior, o ataque de negação de serviço contra a AAI
não é tratado.
4.9 DESENVOLVIMENTO
Esta seção descreve a implementação de um protótipo da AAI4WoT e a integração da infraes-
trutura à uma aplicação de WoT para monitoramento e controle de máquinas industriais. O protótipo é
uma implementação parcial da AAI4WoT, conforme será descrito nas próximas seções. Inicialmente,
são descritas as tecnologias utilizadas na implementação e alguns aspectos do desenvolvimento do
protótipo. Em seguida, a aplicação de WoT utilizada (estudo de caso) é descrita. Por fim, é descrita a
integração da AAI4WoT à aplicação de WoT.
4.9.1 Ferramentas Tecnológicas Utilizadas
A AAI4WoT está baseada no uso de Serviços Web RESTful e das especificações SAML,
XACML e WS-Policy. Como a linguagem de programação JAVA possui várias APIs para desenvolvi-
mento de Serviços Web RESTful e implementações das referidas especificações, optou-se por esta
linguagem de programação para o desenvolvimento da AAI.
A biblioteca OpenSAML6, que implementa a especificação SAML, foi utilizado na AAI4WoT.
Esta biblioteca implementa a especificação SAML 2.0, é de código aberto e é utilizada em diversos
projetos que fazem uso do padrão SAML, como os projetos eduGAIN7, Shibboleth8 e CAS9. Esta
biblioteca foi utilizada nos pontos da AAI4WoT que necessitam do uso de SAML, exceto no IdP, o
qual foi implementado utilizando o framework SimpleSAMLphp 10. Este framework foi escolhido
por ser de código aberto, por ter ampla documentação mantida pelos desenvolvedores e pela comuni-
dade de usuários e por fornecer uma implementação pronta de IdP, facilmente parametrizável e em
conformidade com a especificação SAML 2.0.
O XACML foi utilizado no PEP e no PDP por meio da biblioteca Balana11, a qual é de6 https://wiki.shibboleth.net/confluence/display/OpenSAML/Home7 http://services.geant.net/edugain/Pages/Home.aspx8 http://shibboleth.net/9 http://www.ja-sig.org/products/cas/downloads/index.html10 https://simplesamlphp.org11 http://xacmlinfo.org/category/balana/
88
código aberto e implementa o XACML 3.0 conforme a especificação. Na implementação dos Serviços
Web RESTful em Java, foi adotada a especificação JAX-RS 2.0 e utilizado o framework Jersey12
(JSR-33913), o qual é de código aberto e é a implementação de referência para esta especificação.
O serviço de diretório no qual são armazenadas as identidades dos usuários e dos dispositivos
que autenticam-se no IdP foi implementado utilizando o OpenLDAP14, por ser de código aberto e
facilmente integrável com o SimpleSAMLphp. Os certificados digitais autoassinados utilizados para
autenticação de usuários e dos componentes da AAI4WoT foram gerados usando o Java Keytool
e a biblioteca OpenSSL15. Já para a autenticação de dispositivos, a biblioteca RELIC (ARANHA;
GOUVEA, 2009) foi utilizada para implementação do mecanismo de autenticação escolhido, descrito
na Seção 4.7 e baseado no acordo de chaves descrito em Sakai, Ohgishi e Kasahara (2000) e no
protocolo de challenge-response descrito em Needham e Schroeder (1978).
Os softwares desenvolvidos para o dispositivo cliente e o dispositivo SP utilizado no protótipo
foram embarcados em BeagleBoneBlack 16. Optou-se por esta solução de hardware pois a aplicação
de WoT a utilizada nos experimentos e por esta possuir uma plataforma de hardware aberta. Como
Container Web das aplicações Java que proveem Serviços Web RESTful, foi utilizado o Apache
Tomcat17, uma vez que este já era utilizado na aplicação de WoT, tanto na parte embarcada no
BeagleBone Black como na parte alocada na infraestrutura de Nuvem.
Como ferramentas de apoio aos testes realizados, foram utilizados o Wireshark18 e o TCP-
DUMP19 para análise dos pacotes transmitidos na rede e o Java Mission Control 20 para verificação
do consumo de memória e CPU das aplicações Java. Também foi utilizado o comando df do sistema
operacional Linux para os testes de consumo de memória flash/disco e um multímetro digital para os
testes de consumo de potência elétrica.12 https://jersey.java.net/13 https://jcp.org/en/jsr/detail?id=33914 http://www.openldap.org/15 https://www.openssl.org/16 http://beagleboard.org/BLACK17 http://tomcat.apache.org/18 https://www.wireshark.org/19 http://www.tcpdump.org/20 http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html
89
4.9.2 Implementação do Protótipo da AAI4WoT
Para auxiliar o uso da AAI4WoT, como prova de conceito, foi desenvolvida uma Aplicação
de Registro para usuários e para dispositivos. Esta aplicação serve para que o administrador do IdP
cadastre e gerencie as identidades dos usuários e dos dispositivos que poderão se autenticar no IdP. A
aplicação foi desenvolvida em PHP, sendo as identidades armazenadas em um serviço de diretório
LDAP. Com a aplicação, é possível gerenciar o ciclo de vida das identidades de usuários e dispositivos
(operações de inserção, consulta, exclusão e alteração de identidades).
No protótipo, foram definidos os metadados das identidades de usuários e de dispositivos. Os
metadados dos usuários são compostos dos atributos: nome, sobrenome, e-mail, organização, unidade
organizacional, função, cpf (identificador único) e certificado digital no formato X.509. Os metadados
dos dispositivos tiveram como base os atributos utilizados para descrever dispositivos em plataformas
de IoT em Nuvem 21. Os atributos dos dispositivos são: o número de série (identificador único),
nome de exibição, contato do administrador, organização, unidade organizacional, descrição, tipo de
dispositivo, referência de localização física, latitude, longitude, altitude, disposição (fixo ou móvel),
exposição (indoor ou outdoor) e status (online ou offline). A Figura 14 mostra as telas de cadastro de
usuários e de dispositivos da aplicação de registro, enquanto a Figura 15 mostra a árvore de diretório
LDAP do IdP utilizado nos experimentos.
As informações que farão parte da identidade dos usuários dependem ainda dos mecanismos
de autenticação implementados pelo IdP. No protótipo desenvolvido, o IdP permite o uso de dois
mecanismos: (i) autenticação de usuários via certificado digital no formato X.509 e (ii) autenticação
de dispositivos por meio do acordo de chaves autenticado não-interativo Sakai-Ohgishi-Kasahara,
descrito na Seção 4.7. O registro de usuários ocorre com base na inserção das informações na tela de
cadastro e na inserção de um certificado digital no formato X.509, feitos pelo administrador do IdP.
Caso a inserção não seja bem sucedida, uma tela de erro é apresentada. Para os experimentos, foram
utilizados certificados autoassinados.
Para registar um dispositivo, o administrador do domínio insere os atributos da identidade do
dispositivo na aplicação de registro. Esta executa uma aplicação escrita em linguagem C para gerar
a chave privada do dispositivo. Essa chave privada é gerada com base na chave pública (calculada
com base no número de série enviado) e na chave mestra (única, conhecida somente pelo IdP e gerada
antecipadamente - ver Figura 13) . Após a geração da chave privada, a aplicação a exibe para o21 Foram utilizadas como base as plataformas DeviceHive, Xively, Thingworx, Evrything e Axeda.
90
Figura 14. Telas de cadastro da aplicação de registro do IdP
administrador do IdP , o qual deve inserir manualmente no dispositivo que está sendo registrado.
Esta chave privada não é armazenada no IdP. Na implementação do acordo de chaves Sakai-Ohgishi-
Kasahara, foi utilizada a biblioteca RELIC (ARANHA; GOUVEA, 2009).
Optou-se pelo uso de certificados digitais para autenticação de usuários por ser um meca-
nismo mais forte do que a autenticação por usuário e senha. A opção pelo uso do acordo de chaves
Sakai-Ohgishi-Kasahara ocorreu pela necessidade de se utilizar um mecanismo mais adequado para
autenticação de dispositivos, como é o caso do mecanismo escolhido. A escolha por um mecanismo
baseado em identidades evita a necessidade do uso de certificados digitais (e o elevado custo da compra
e manutenção de um certificado para cada dispositivo) e, ao mesmo tempo, mantém a possibilidade do
uso de criptografia assimétrica para autenticação. Por fim, a escolha por mecanismos de autenticação
diferentes para usuários e dispositivos e o suporte a estes no mesmo IdP visou atingir o objetivo
específico 2 deste trabalho.
No protótipo, dois cenários foram desenvolvidos. Em ambos, o IdP e o PDP estavam aloca-
dos em uma infraestrutura de Nuvem (Modo de Operação SP com restrição). No primeiro cenário
(autenticação de dispositivos), uma aplicação Java embarcada em um dispositivo BeagleBone Black
atua como dispositivo cliente de um Serviço Web RESTful, que está embarcado em outro BeagleBone
Black (dispositivo SP). No segundo cenário (autenticação de usuários), uma aplicação Java é executada
91
dc=idp-t-marlon,dc=cloudapp,dc=net
-objectClass: top-objectClass: dcObject-objectClass: organization-dc: idp-t-marlon-o: DomainA
-dn: dc=idp-t-marlon,dc=cloudapp,dc=net
ou=person
-objectClass: top
-objectClass: organizationalUnit-ou: person
-dn: ou=person,dc=idp-t-marlon,dc=cloudapp,dc=net
ou=device
-objectClass: top-objectClass: organizationalUnit-ou: device
-dn: ou=device,dc=idp-t-marlon,dc=cloudapp,dc=net
uid=identifier
-objectClass: top-objectClass: person
-dn: uid=Identifier,ou=person,dc=idp-t-marlon,dc=cloudapp,dc=net
-objectClass: organizationalPerson-objectClass: inetOrgPerson
-cn: commonName-sn: surName-mail: [email protected]: Role-description: description of the person-uid: unique identifier with 256 characters-userCertificate: user's digital certificate
-objectClass: extensibleObject
uniqueIdentifier=identifier
-objectClass: top-objectClass: device
-dn: uniqueIdentifier=Identifier,ou=device,dc=idp-t-marlon,dc=cloudapp,dc=net
-cn: commonName-adminContact: device administrator's mail address
-deviceType: type of the device-description: description of the device
-uniqueIdentifier: unique identifier with 256 characters
-l: name of location
-objectClass: extensibleObject
-latitude: latitude of the device-longitude: longitude of the device-altitude: altitude of the device
-exposure: outdoor or indoor-disposition: mobile or fixed
-status: online or offline
Figura 15. Árvore do diretório de identidades do IdP
em um notebook e atua como cliente não Web e o Serviço Web RESTful é embarcado no BeagleBone
Black (dispositivo SP).
Os diagramas de sequência das Figura 16 e 17 mostram as trocas de mensagens para a
autenticação de dispositivos, conforme descritas a seguir:
• Passo 1: Cliente Ativo monta uma requisição de autenticação SAML22 que não é assinada
digitalmente. No campo da requisição que aponta o gerador desta, é inserido o identificador
único do SP que o cliente deseja acessar;
• Passo 2: Antes do envio da requisição de autenticação, é estabelecido um canal TLS entre o
cliente e o IdP, sendo que o IdP é autenticado por meio do seu certificado SSL. A requisição
de autenticação SAML é enviada via HTTP POST, de acordo com o Binding HTTP POST22 Diferente do que foi descrito na Seção 4.5.1, no protótipo, não foi implementada a busca da política de qualidade de
proteção do dispositivo SP conforme descrito na Seção 4.5.1. Assume-se no protótipo, que o Cliente Ativo obteve aWS-Policy e extraiu as informações necessárias para montar a requisição SAML.
92
1 - Gera SAML AuthnRequest
IdPCliente Ativo
2 - HTTPS POST - /SSOService {SAML Authn Request}
HTTPS Redirect {/selectsource + cookieSess}
/selectsource
3 - HTTPS GET - /selectsource {cookieSess}
HTTPS Redirect {/logindevice + cookieMec}
4 - HTTPS GET - /selectsource {mecanismo + cookieSess}
/logindevice
5 - HTTPS GET - /logindevice {cookieSess + cookieMec}
HTTPS Redirect {/logindevice + challenge}
6 - HTTPS POST - /logindevice {NumSerie + cookieSess + cookieMec}
CalculaChallenge
/logindevice
7 - HTTPS GET - /logindevice {cookieSess + cookieMec}
8 – Calcula Response
HTTPS Redirect {SP/resource + SAML Response + cookieAuth}
9 - HTTPS POST - /logindevice {NumSerie + response + cookieSess + cookieMec}
10 – Extrai SAML Response
Figura 16. Fluxo de mensagens do cenário de autenticação de dispositivos - parte 1
93
SPCliente Ativo
11 - HTTPS GETSP/resource {SAML Response}
17 - HTTPS 200 {recurso} / Erro HTTP
PDP
12 - Verifica Assinatura SAML Response
12 - Verifica Assinatura SAML Assertion
12 – Gera XACML Request
15 - HTTPS 200 {XACML Response}
13 - HTTPS POST - /decisionrequest {XACML Request}
14 - Toma Decisão de Autorização
16 – Verifica Decisão de Autorização
Figura 17. Fluxo de mensagens do cenário de autenticação de dispositivos - parte 2
(OASIS, 2009b), para o endpoint de autenticação do IdP (/SSOService). Em função do uso
deste Binding, para o IdP, o cliente foi redirecionado pelo respectivo SP para o endpoint
de autenticação. Como resposta, o IdP envia uma mensagem HTTP de redirecionamento,
encaminhando o Cliente Ativo para outro endpoint no mesmo IdP (/selectsource), para que
o cliente escolha qual mecanismo deseja se autenticar (certificado digital ou o acordo de
chaves Sakai-Ohgishi-Kasahara). Além do redirecionamento, a resposta HTTP contém um
cookie (cookieSess), o qual deve ser enviado pelo Cliente Ativo durante as futuras interações
com o IdP. Esse cookie serve para que o IdP possa fazer a manutenção da sessão do cliente,
sendo o único ponto da AAI4WoT que mantém estados de sessão (necessário para prover a
autenticação única). Percebe-se, assim, que para interagir com sucesso com o IdP, o Cliente
Ativo deve simular o fluxo de mensagens que seria realizado por um navegador Web;
• Passo 3: Neste passo, o Cliente Ativo solicita, via HTTP GET, o conteúdo do endereço
para onde o IdP o redirecionou no Passo 2, enviando junto o cookieSess. Como resposta, o
cliente recebe o respectivo conteúdo
• Passo 4: O Cliente Ativo seleciona o mecanismo de autenticação desejado, neste caso, o
acordo de chaves Sakai-Ohgishi-Kasahara. A opção é indicada em nova requisição HTTP
94
GET (via Query String - na URL) que o Cliente Ativo envia para o endpoint do IdP para o
qual foi redirecionado no Passo 2 (/selectsource). Como resposta, o IdP envia mensagem
HTTP redirecionando o Cliente Ativo para outro endpoint (/logindevice), responsável pelo
processo de autenticação. A mensagem de redirecionamento contém, ainda, um cookie
que deve ser mantido pelo cliente (cookieMec), indicando o mecanismo de autenticação
escolhido;
• Passo 5: Neste passo, o Cliente Ativo solicita, via HTTP GET, o conteúdo do endereço para
onde o IdP o redirecionou no Passo 4, enviando junto o cookieSess e o cookieMec. Como
resposta, o cliente recebe o respectivo conteúdo;
• Passo 6: O Cliente Ativo envia para o IdP o parâmetro público no qual sua chave pública é
baseada, por exemplo, seu número de série. Esse envio é feito via mensagem HTTP POST,
em que o conteúdo é do tipo application/x-www-form-urlencoded e o número de série é
enviado como um par do tipo chave-valor. Ao receber a requisição, o IdP irá executar uma
aplicação escrita em C que calcula challenge para o cliente, conforme descrito na Seção 4.7.
O challenge é enviado na URL para a qual o Cliente Ativo é redirecionado;
• Passo 7: Neste passo o Cliente Ativo solicita, via HTTP GET, o conteúdo do endereço para
onde o IdP o redirecionou no Passo 6, enviando junto o cookieSess e o cookieMec. Como
resposta, o cliente recebe o respectivo conteúdo
• Passo 8: O Cliente Ativo extrai o challenge da URL para a qual foi redirecionado e executa
uma aplicação em C para o cálculo do response, conforme descrito na Seção 4.7;
• Passo 9: O response é enviado para o IdP junto com o número de série do cliente via HTTP
POST23, sendo que o número de série e o response são enviados como pares do tipo chave-
valor. Junto com a requisição são enviados o cookieSess e o cookieMec. Caso o response
esteja correto, o cliente é autenticado e o IdP responde ao cliente (com uma mensagem
redirecionando para o endereço do recurso no SP desejado), enviando no corpo a mensagem
SAML Response com a asserção SAML, que indica que o cliente foi autenticado e os
atributos que este possui. Tanto a SAML Response como a Asserção SAML são assinadas
digitalmente pelo IdP. A mensagem HTTPS do IdP contém ainda um cookie que indica ao
IdP o contexto de segurança do cliente (cookieAuth). Este deve ser armazenado pelo Cliente
Ativo e utilizado em requisições futuras juntamente com os demais cookies, evitando uma
nova autenticação e permitindo a autenticação única;23 O conteúdo é do tipo application/x-www-form-urlencoded.
95
• Passo 10: Neste passo, o Cliente Ativo não segue o redirecionamento solicitado pelo IdP no
Passo 9 e extrai do corpo da resposta HTTP a mensagem SAML Response enviada pelo
IdP;
• Passo 11: O Cliente Ativo estabelece com o SP um canal seguro TLS (SP é autenticado pelo
Cliente Ativo por meio de certificado SSL). Em seguida, envia a solicitação para o recurso
do SP (SP/resource) utilizando o método HTTP GET. A mensagem SAML Response é
enviada em um cabeçalho (HTTP Header) chamado SAMLResponse;
• Passo 12: O PEP do SP extrai o cabeçalho HTTP e obtém a mensagem SAML Response.
A etapa de verificação de assinaturas digitais que seria delegada ao IdP do domínio local,
conforme descrito na Seção 4.5.1, foi executada localmente no SP. Assim, o SP verifica
se a assinatura digital da mensagem SAML Response e da Asserção SAML são de algum
dos IdPs que fazem parte do círculo de confiança do SP. Se sim, o SP gera uma requisição
de decisão de autorização no formato XACML, tendo como base o recurso que o cliente
deseja acessar, a ação que o cliente deseja realizar (método HTTP da solicitação), o dia da
solicitação e os atributos do cliente contidos na Asserção SAML;
• Passo 13: O PEP do SP envia a solicitação de decisão de autorização no formato XACML
para o PDP (/decisionrequest) em uma mensagem HTTP POST, sobre um canal TLS
mutuamente autenticado;
• Passo 14: O PDP toma a decisão de autorização com base na requisição recebida. Os
componentes PIP e PAP, descritos na Seção 4.5.1 não foram implementados. Sendo assim,
as decisões de autorização são tomadas com base nas políticas de controle de acesso que o
PDP possui localmente (a política utilizada nos experimentos está descrita em detalhes no
Apêndice B). Com base na decisão tomada, é gerada uma resposta XACML, contendo a
respectiva decisão de autorização;
• Passo 15: O PDP envia ao PEP a decisão de autorização no formato XACML (XACML
Response);
• Passo 16: O PEP verifica se a decisão de autorização permite que o recurso seja fornecido; e
• Passo 17: Caso a decisão de autorização permita, o recurso é fornecido ao cliente. Caso
contrário, um erro HTTP é enviado ao cliente.
96
Vale destacar que, no Passo 1, a requisição de autenticação SAML gerada pelo Cliente Ativo
possui, no campo que aponta o gerador da requisição, o identificador do SP que o cliente deseja acessar.
Logo, para o IdP, o cliente chegou ao endpoint de autenticação com a requisição SAML em função de
um redirecionamento feito pelo SP. Na especificação SAML, a requisição de autenticação precisa ser
gerada por um SP. Neste caso, o SP ficaria responsável pela geração da requisição de autenticação para
o cliente e precisaria manter o estado de sessão deste até que retornasse ao SP para consumir o recurso.
Uma alternativa seria o cliente realizar o fluxo de autenticação iniciado no IdP, em que o cliente não
envia uma requisição de autenticação SAML, mas indica ao IdP o SP que deseja acessar. Contudo, ao
fazer isso, o cliente pode não atender aos requisitos de segurança do SP com a autenticação realizada.
Assim, esta opção foi tomada para manter a compatibilidade com o padrão SAML nas mensagens
trocadas entre cliente e IdP.
Sobre o Passo 11, em que a mensagem SAML Response é enviada no cabeçalho (HTTP
Header), percebe-se que esta não segue um dos Bindings definidos na especificação SAML. Para
manter a conformidade com o SAML e usar apenas mensagens HTTP, há duas alternativas: (i) usar o
HTTP POST Binding ou (ii) usar o HTTP Artifact Binding. No primeiro caso, a mensagem do cliente
para o SP utiliza sempre o método HTTP POST para envio da SAML Response. Neste caso, o SP
precisará manter uma sessão do cliente e, após receber a SAML Response e avaliar a Asserção SAML
contida nesta, deverá redirecionar o cliente para o recurso desejado. Essa opção não é adequada em
função do redirecionamento adicional e da necessidade de manutenção do contexto de segurança. No
segundo caso, o cliente receberá do IdP e enviará ao SP apenas um token (artefato) que referencia a
mensagem SAML Response contida no IdP. O SP deverá solicitar ao IdP a mensagem SAML Response
por meio de um canal direto com o IdP, usando o protocolo SOAP. Essa opção também não é adequada,
em função do uso do SOAP pelo SP. Logo, para tratar deste problema, optou-se por incluir a SAML
Response no cabeçalho da requisição HTTP enviada ao SP.
Quando o cliente ativo precisar consumir novamente um recurso de algum SP da federação, este
poderá usufruir da autenticação única. Neste caso, o fluxo de mensagens com o SP não mudará e apenas
o fluxo de autenticação será alterado (Figura 16). O fluxo de autenticação única para dispositivos é
mostrado no diagrama da Figura 18 e é descrito a seguir:
• Passo 1: Cliente Ativo monta uma requisição de autenticação SAML;
• Passo 2: É estabelecido um canal TLS entre o cliente e o IdP. A requisição de autenticação
SAML é enviada via HTTP POST para o endpoint de autenticação do IdP (/SSOService).
97
1 - Gera SAML AuthnRequest
IdPCliente Ativo
2 - HTTPS POST - /SSOService {SAML Authn Request + cookieSess + cookieMec + cookieAuth}
HTTPS Redirect {SP/resource + SAML Response}
3 – Extrai SAML Response
Figura 18. Fluxo de mensagens de autenticação única do cenário de autenticação de dispositivos
Junto com a requisição, são enviados o cookieSess, o cookieMec e o cookieAuth. O IdP
verifica o contexto de autenticação do cliente e percebe que este já está autenticado. Assim,
o IdP responderá com uma mensagem redirecionando o cliente para o endereço do recurso
no SP desejado, enviando no corpo desta uma mensagem SAML Response, a qual contém a
Asserção SAML que indica que o cliente foi autenticado e os atributos que este possui; e
• Passo 3: O Cliente Ativo extrai do corpo da resposta HTTP a mensagem SAML Response
enviada pelo IdP.
A diferença nas trocas de mensagens do cenário de autenticação de usuários para o cenário de
autenticação de dispositivos está no Passo 4, no qual o cliente escolhe o mecanismo de autenticação.
Neste passo da autenticação de usuários, o Cliente Ativo seleciona a autenticação via certificado
digital. A opção também é indicada em nova requisição HTTP GET (via Query String - na URL)
que o Cliente Ativo envia para o endpoint de escolha do mecanismo de autenticação do IdP. Ao
receber a requisição, o IdP solicita o certificado digital do cliente por meio do canal TLS estabelecido
entre ambos. O cliente envia o certificado e o IdP busca no diretório LDAP um cliente que possua
o campo uid igual ao campo CN do certificado X.509. Caso o cliente seja encontrado, o certificado
enviado é comparado com o certificado armazenado na base LDAP (cadastrado na etapa de registro)
98
e, caso o certificado seja o mesmo, o cliente está autenticado. O servidor então responde com uma
mensagem de redirecionamento, enviando no corpo desta uma mensagem SAML Response, a qual
contém a Asserção SAML que indica que o cliente autenticou-se e os atributos que este possui. Tanto
a SAML Response como a Asserção SAML são assinadas digitalmente pelo IdP. Ainda, a mensagem
HTTP do IdP contém um cookie que indica ao IdP o contexto de segurança do cliente (cookieAuth) e
outro que indica o mecanismo de autenticação escolhido (cookieMec). Todos os cookies devem ser
armazenados pelo Cliente e utilizados em requisições futuras, permitindo assim a autenticação única.
Após o recebimento da SAML Response, a troca de mensagens com o SP é a mesma para dispositivos
e usuários, ou seja, o fluxo é o mesmo a partir do Passo 10. De modo similar, o fluxo de autenticação
única para usuários é igual ao fluxo para dispositivos.
4.9.3 Aplicação de Monitoramento e Controle de Máquinas Industriais
A aplicação de WoT de monitoramento e controle de máquinas industriais, descrita em Silva
(2014a), visa obter os dados de monitoramento de uma máquina industrial, ou de um conjunto de
máquinas, tratar estes dados e disponibilizá-los de duas maneiras: (i) para uma aplicação hospedada
em um ambiente de Nuvem, a qual faz a persistência dos dados recebidos e os disponibiliza para
aplicações de monitoramento construídas em uma Plataforma como Serviço (Platform as a Service
- PaaS); e (ii) para usuários e dispositivos que queiram ter acesso às informações sobre a máquina
(ou conjunto de máquinas) monitorada. Vale ressaltar que tanto a aplicação que faz a persistência dos
dados quando a PaaS são contribuições descritas em Silva (2014b).
Conforme mostrado na Figura 19, a aplicação em questão funciona em conjunto com uma
máquina industrial, a qual possui um sistema SCADA (Supervisory Control and Data Acquisition)
instalado em um notebook que acompanha a máquina. O sistema SCADA é responsável por atuar sobre
a máquina e obter informações sobre o funcionamento desta, ou seja, sobre as operações que a máquina
está realizando e sinais provenientes de sensores. Tais informações de funcionamento da máquina
são gravadas em um arquivo de log. Como o sistema SCADA intermedia a troca de informações com
a máquina, este torna-se a interface com a qual a aplicação de WoT de monitoramento e controle
de máquinas industriais deve interagir para monitorar/atuar sobre a máquina. Neste trabalho, foram
utilizadas apenas as funções de monitoramento desta aplicação, haja vista que as funções de controle
ainda estão em desenvolvimento.
Para realizar o monitoramento, a aplicação precisa identificar quando novas informações de
funcionamento da máquina são incluídas no arquivo de log pelo sistema SCADA. Para isso, foi
99
Smart Gateway
Co
nta
ine
r W
eb
Aplicação Smart Gateway
Representação
Virtual da Máquina
Serviço Web
RESTful
Cliente Web
RESTful De
vic
e D
riv
er Máquina Industrial
{ SPI/I2C }
Monitor
Cliente Web RESTful
{ JSON }
Máquina Industrial
{ LOG }
Sistema SCADA
PaaS
Serviço Web de Recebimento
de Dados
{ JSON }
Dispositivo ClienteUsuário Cliente
{ JSON/XML }{ JSON/XML }
Infraestrutura de Computação em Nuvem
Figura 19. Aplicação de WoT para monitoramento e controle remoto de máquinas industriais
Fonte: Adaptada de Silva (2014a).
desenvolvida em Silva (2014a), uma aplicação chamada Monitor. O Monitor é uma aplicação Java
instalada no notebook em que o sistema SCADA grava o log e, a cada inclusão de uma nova informação
no log, o Monitor recupera esta informação e disponibiliza à aplicação de monitoramento, conforme
mostrado na Figura 19. A aplicação de monitoramento, que também é uma aplicação Java e está
implantada em um Container Web Apache Tomcat, está embarcada em um BeagleBone Black, ou
seja, fora do notebook no qual o sistema SCADA e o Monitor estão instalados. A aplicação de
monitoramento embarcada no BeagleBone Black será chamada de Smart Gateway.
O envio das informações recuperadas pelo Monitor para o Smart Gateway é feito por meio de
Serviços Web RESTful. Assim, o Monitor é um cliente de Serviço Web RESTful, enquanto que o
Smart Gateway é o servidor. Com base nas informações recebidas sobre os estados e operações da
máquina monitorada, o Smart Gateway cria uma imagem virtual desta. Assim, ao receber uma nova
informação, o Smart Gateway faz a interpretação desta e replica a alteração na imagem virtual da
máquina monitorada. As informações da máquina presentes nesta imagem virtual são disponibilizadas
aos clientes (usuários e dispositivos) por meio de Serviços Web RESTful, podendo ser acessadas
100
diretamente no Smart Gateway. Além disso, periodicamente, o Smart Gateway envia as alterações que
ocorreram na imagem virtual da máquina para a aplicação na Nuvem, a qual faz a persistência na base
de dados da PaaS. Neste trabalho, o envio foi configurado para ocorrer a cada 30s. Assim, a aplicação
na Nuvem faz o papel de servidor do Serviço Web RESTful de Recebimento de Dados, enquanto que
o Smart Gateway faz o papel de cliente.
A Figura 19 mostra a comunicação entre as aplicações de monitoramento de máquinas indus-
triais. Como é mostrado, é possível a comunicação direta entre o Smart Gateway e uma máquina
industrial, via Device Driver e um barramento como SPI ou I2C. Contudo, este cenário não é abordado
neste trabalho.
Em função de não haver uma máquina industrial e um sistema SCADA reais para execução
dos experimentos, foi criado, em Silva (2014a), um simulador do sistema SCADA, chamado aqui
de SIMSCADA. De posse de um arquivo de log gerado por um sistema SCADA de uma máquina
industrial real, o papel do SIMSCADA é simular a gravação de registros de log que é feita pelo
sistema SCADA. Assim, o SIMSCADA copia, linha a linha, o conteúdo do arquivo de log real para o
arquivo de log que o Monitor está monitorando. Desse modo, é possível suprir a falta de uma máquina
industrial real durante os experimentos. A Figura 20 mostra a tela da aplicação SIMSCADA, em
que o campo "Arquivo de Origem"indica o caminho para o arquivo com os logs reais e o campo
"Repositório SCADA"indica o caminho para o arquivo monitorado pelo Monitor. A marcação da caixa
"Manual"indica que uma nova linha será copiada de um arquivo para outro somente quando o usuário
pressionar o botão "Play". Este foi o modo utilizado nos experimentos.
Figura 20. Simulador do Sistema SCADA - SIMSCADA
101
Como prova de conceito, também foram desenvolvidas duas aplicações clientes, que consomem
recursos do Smart Gateway. A primeira aplicação, chamada de Cliente Desktop, foi desenvolvida em
Java, podendo ser portada, com algumas adaptações (principalmente de interface com o usuário), para
um dispositivo móvel como um smartphone ou tablet. A Figura 21 mostra a tela desta aplicação. O
usuário deve preencher o campo de texto com o recurso que deseja monitorar e, ao clicar no botão
"Monitorar Recurso", a aplicação envia uma solicitação HTTP GET ao recurso e exibe o retorno
no campo "Retorno do Provedor de Serviço". Durante os experimentos, foram utilizados recursos
representados em XML.
Figura 21. Aplicação Cliente Desktop
A segunda aplicação, chamada de Cliente Embarcado, também foi desenvolvida em Java e foi
embarcada em um BeagleBone Black. A aplicação funciona de maneira similar ao Cliente Desktop,
contudo sem a interface com usuário, uma vez que o Cliente Embarcado visa simular uma aplicação
autônoma que interage com o Smart Gateway. Ao iniciar a aplicação, o Cliente Embarcado faz uma
requisição HTTP GET ao recurso que será monitorado e exibe o retorno na console, sendo esse
processo executado 50 vezes em intervalos de 5 segundos. Do mesmo modo que no Cliente Desktop,
foram utilizados recursos representados em XML durante os experimentos.
102
4.9.4 Integração da Infraestrutura de Autenticação e de Autorização para a Web
das Coisas
A integração da aplicação de monitoramento de máquinas industriais à AAI4WoT foi realizada
por meio da inclusão de código fonte da AAI4WoT no Smart Gateway, no Serviço de Recebimento
de Dados da aplicação de Nuvem, no Cliente Desktop e no Cliente Embarcado. No caso do Smart
Gateway, este foi integrado tanto para atuar com o papel de cliente quanto com o papel de servidor.
Deve-se ressaltar que a comunicação da aplicação Monitor com o Smart Gateway não foi alterada.
Além da inclusão de código fonte, houve a integração das aplicações com os demais serviços, como o
de autenticação (alocado no Provedor de Identidades - IdP) e de solicitação de decisão de autorização
(alocado no PDP).
A integração ocorreu em três cenários distintos: (i) cenário em que o Smart Gateway é o cliente
de Serviço Web RESTful e envia informações de monitoramento para o Serviço Web RESTful de
recebimento de dados na Nuvem; (ii) cenário em que o Smart Gateway atua como servidor e provê as
informações de monitoramento para um cliente Desktop; e (iii) cenário em que o Smart Gateway atua
como servidor, mas o cliente é uma aplicação embarcada em um BeagleBone Black (dispositivo SP).
No primeiro cenário, o fluxo de mensagens é similar ao mostrado nas Figuras 16 e 17. Uma
das diferenças está no início do fluxo de mensagens, que ocorre antes da autenticação. Neste caso, o
Monitor envia para o Smart Gateway informações de monitoramento da máquina industrial, gravadas
pelo sistema SCADA no arquivo de log. Em seguida, inicia-se o Passo 1, descrito na Figura 16. Outra
diferença está no método HTTP utilizado neste cenário para solicitação do recurso ao SP: ao invés
do método HTTP GET utilizado no protótipo, o Smart Gateway envia os dados para o serviço de
recebimento de dados na Nuvem utilizando o método HTTP PUT. Por fim, no protótipo, o Passo 17
(Figura 17) consiste no fornecimento do recurso ao cliente, enquanto na aplicação de WoT corresponde
à persistência na Nuvem dos dados enviados pelo Smart Gateway.
Neste cenário, o SP (serviço de recebimento de dados da Nuvem) e o PDP estavam alocados
na mesma máquina virtual, contudo em Containers Web distintos (por questões de configurações
diferentes para cada Container). Desse modo, este cenário implementa o Modo de Operação SP Sem
Restrições, descrito na Seção 4.5.2, mas ainda assim permite que um PDP seja utilizado por múltiplos
SPs. Para usufruir da autenticação única, o fluxo de mensagens mostrado na Figura 18 é executado
pelo Cliente Ativo, enquanto o fluxo de mensagens com o SP mantem-se o mesmo.
Para o cenário 2 em que o Smart Gateway atua como servidor e provê recursos para a aplicação
103
Cliente Desktop, foi necessário alterar a aplicação para que esta disponibilizasse um campo para
inserção do endpoint de autenticação do IdP escolhido pelo usuário. A tela da aplicação é mostrada
na Figura 22. Apesar desta alteração, o fluxo de mensagens deste cenário é o mesmo descrito para o
protótipo da AAI4WoT para autenticação de usuários na Seção 4.9.2.
Figura 22. Tela da aplicação Cliente Desktop integrada à AAI4WoT
Neste cenário, o SP (Smart Gateway) e o PDP estavam alocados em diferentes infraestruturas:
o SP estava embarcado em um BeagleBone Black, enquanto que o PDP estava alocado em uma
infraestrutura de computação em Nuvem. Desse modo, verifica-se a implementação do Modo de
Operação SP Restrito, descrito na Seção 4.5.1. Do mesmo modo que no cenário anterior, é possível
que o cliente usufrua da autenticação única. Para usufruir da autenticação única, o fluxo de mensagens
mostrado na Figura 18 deverá ser executado pelo Cliente Desktop e o fluxo de mensagens com o SP se
manterá o mesmo.
O último cenário consiste no Smart Gateway como servidor e na aplicação Cliente Embarcado
como cliente. A aplicação Cliente Embarcado foi integrada à AAI4WoT por meio da inclusão de
código fonte da AAI4WoT à aplicação Cliente Embarcado. Não foi necessário realizar alterações no
fluxo de mensagens do protótipo para realizar a integração da AAI4WoT com a aplicação de WoT neste
104
cenário. Assim, o fluxo de mensagens mantem-se o mesmo descrito para o protótipo da AAI4WoT para
autenticação de dispositivos na Seção 4.9.2. Do mesmo modo que no cenário anterior, o SP (Smart
Gateway) estava embarcado em um BeagleBone Black e o PDP estava alocado em uma infraestrutura
de computação em Nuvem. Para usufruir da autenticação única, o fluxo de mensagens mostrado na
Figura 18 deverá ser executado pelo Cliente Embarcado e o fluxo de mensagens com o SP mantem-se
o mesmo.
4.10 CONSIDERAÇÕES DO CAPÍTULO
A AAI4WoT está alinhada com o conceito de operações sem estado (ZENG; GUO; CHENG,
2011) do REST. Na interação do Cliente Ativo SAML com o SP, primeiro o Cliente Ativo SAML
busca a política de qualidade de proteção do serviço desejado e, só num passo posterior, o cliente tenta
acessar o serviço, já de posse de uma Asserção SAML adequada ao consumo do respectivo recurso.
Desse modo, ao tentar acessar o serviço, o cliente já dispõe das informações que o SP precisa para
tomar a decisão de autorização, a qual independe de decisões anteriormente tomadas. Assim, o SP
não precisa manter um estado (sessão) do cliente para fornecer o serviço. Esse fluxo faz com que haja
uma otimização do uso de recursos do SP, quando comparado ao cenário em que o cliente faz uma
requisição sem possuir uma asserção SAML adequada ao consumo do respectivo serviço.
Uma das alterações que poderia ter impactos positivos no desempenho da AAI4WoT e no
tamanho das mensagens transmitidas na rede é a adição do suporte à conversão da representação
de dados XML para a representação JSON, e vice-versa, para as mensagens e asserções SAML,
requisições e respostas XACML e políticas WS-Policy. Assim, por exemplo, uma asserção SAML seria
representada em JSON ao invés de XML, herdando os benefícios dessa representação, já mencionados
anteriormente. Contudo, apesar dessa conversão estar disponível para os recursos oferecidos na
aplicação de WoT, o que torna tais recursos agnósticos à maneira como são representados (p.e. XML,
JSON e texto plano), a adição desse mesmo suporte para a parte de segurança deste trabalho mostrou-se
inviável. As bibliotecas utilizadas como implementação dos padrões de segurança (SAML, XACML
e WS-Policy) não suportam a representação JSON, o que implicaria na reimplementação destas
bibliotecas para que tal suporte fosse provido e para que estas pudessem ser tratadas de maneira
transparente (sem alterações) por frameworks como o Jersey, uma implementação de referência para
Serviços Web RESTful em Java. Para o caso do IdP SAML utilizado (SimpleSAMLphp), este também
precisaria de adaptações não triviais para que pudesse suportar a conversão de XML para JSON e
vice-versa. Assim, a complexidade de reimplementação destas bibliotecas e as adaptações necessárias
105
tornam o uso do JSON inviável para a parte de segurança deste trabalho. Contudo, deve-se ressaltar
que isto não limita os SPs a proverem recursos representados apenas em XML. O recurso provido pode
ser representado de qualquer maneira, sendo dependente apenas de um acordo entre SP e cliente, uma
vez que as mensagens SAML são transmitidas do cliente para o SP em um cabeçalho HTTP arbitrário.
Uma alteração necessária nos IdPs SAML foi a inclusão do suporte ao contexto de autenticação
que represente eventos de autenticação que utilizaram o mecanismo de autenticação de dispositivos
escolhido, não previstos na especificação original SAML. Uma extensão da especificação SAML,
neste sentido, foi apresentada no Apêndice C. Contudo, a decisão de quais contextos de autenticação
devem ser suportados depende de cada implementação.
106
5 RESULTADOS E AVALIAÇÃO
Esta seção apresenta os experimentos que foram realizados para avaliação do impacto da
integração da AAI4WoT à aplicação de WoT, bem como os resultados da execução de tais experimentos.
Também é apresentada uma análise a respeito dos resultados obtidos.
5.1 EXPERIMENTOS
Durante os experimentos, dois cenários foram comparados:
1. Aplicação de WoT sem uma solução de segurança;
2. Aplicação de WoT integrada à AAI4WoT.
Para ambos os cenários, três subcenários foram comparados:
1. O dispositivo Smart Gateway assume o papel de cliente e envia os dados monitorados da
máquina industrial para a aplicação hospedada na Nuvem, a qual assume o papel de SP.
Este caso implementa o Modo de Operação SP Sem Restrições, em que o SP e o PDP
estão no mesmo ambiente computacional (neste caso, na mesma máquina virtual). Com este
cenário, buscou-se avaliar os impactos do uso da AAI4WoT para um cliente com restrições
computacionais e para um SP com muitos recursos;
2. Uma aplicação desktop (Cliente Desktop) executada em um notebook atua como cliente e
envia requisições para um recurso de monitoramento do Smart Gateway, que neste cenário
atua como SP e está embarcado em um BeagleBone Black. Este cenário implementa o
Modo de Operação SP Restrito, em que o SP está embarcado em um dispositivo com
restrições computacionais e o PDP está em outro ambiente computacional (neste caso,
uma infraestrutura de Computação em Nuvem). Neste cenário, o objetivo foi avaliar os
impactos do uso da AAI4WoT em um SP embarcado em um dispositivo com restrições
computacionais e os impactos em um cliente com muitos recursos que funciona com a
intervenção de um usuário humano; e
3. Uma aplicação embarcada em um BeagleBone Black (Cliente Embarcado) assume o papel
107
de cliente e o Smart Gateway, embarcado em outro BeagleBone Black, assume o papel de
SP. O cliente envia requisições para o mesmo recurso de monitoramento do Smart Gateway
que no cenário anterior. Este caso também implementa o Modo de Operação SP Restrito.
O objetivo deste cenário foi avaliar os impactos do uso da AAI4WoT quando o SP e o
cliente são embarcados em dispositivos com restrições computacionais. No caso do cliente,
este difere do primeiro cenário, uma vez que a aplicação embarcada é mais simples e mais
modesta no uso de recursos (p.e. não faz uso de um servidor de aplicação/container Web) e
atua sem intervenção humana.
Para avaliar a AAI diante dos cenários descritos, foram utilizadas as seguintes métricas:
• Consumo de memória RAM;
• Consumo de espaço de memória flash/disco;
• Tempo de processamento;
• Uso de CPU;
• Vazão da rede (throughput);
• Tamanho das mensagens; e
• Consumo de potência elétrica.
Foram avaliadas diferentes etapas dos processos executados nos cenários mencionados, con-
forme detalhado nas seções a seguir.
5.2 RESULTADOS
Esta seção descreve os resultados obtidos com a execução dos experimentos, os quais foram
executados 50 vezes. A partir destas amostras, foram extraídos os dados que são detalhados a seguir.
5.2.1 Experimento de Footprint
Este experimento visou verificar o custo computacional das aplicações nos diferentes cenários.
Entretanto, não é feita troca de mensagens neste experimento. Os dados obtidos para o Cliente são
108
mostrados na Tabela 21. Para cada métrica, foram calculados a média e o desvio padrão. A memória
RAM e o uso de CPU foram calculados utilizando a ferramenta JMC, considerando o uso de CPU
e memória de todo o sistema (exceto para o Cliente Desktop, em que foi considerado apenas o
consumo da JVM - Java Virtual Machine). A porcentagem de memória RAM tem como referência a
memória RAM total do sistema. O espaço utilizado em flash/disco foi obtido por meio da execução do
comando df, no console do sistema operacional (SO) Linux (exceto para o Cliente Desktop, em que
foi mensurado apenas o tamanho do arquivo executável e das bibliotecas necessárias, visando evitar
interferências do SO do computador em que a aplicação foi executada).
Tabela 2. Footprint - Dados do Cliente
AAIMemória
RAM (MiB)Flash ou
Disco (MB)Uso de
CPU (%)Cenário/Métricas Méd. D. Pad. Méd. D. Pad. Méd. D. Pad.
181 0 1.561,4 0 8,12 5,31Cliente SG -SP Cloud X 255 0 1.580,6 0 4,59 4,54
15,33a 19,25
- 0,6 - 1,35 1,32Cliente Desktop
- SP SG X14,43a 26,1
- 14 - 0,79 0,47
114 0 1.513,9 0 10,28 4,63Cliente Embarc.- SP SG X 118 0 1.589,2 0 10,30 3,01
Com base na Tabela 2, percebe-se que os dados de consumo de memória RAM e de memória
secundária (flash ou disco) possuem desvio padrão nulo, o que ocorre pelo fato de que a aplicação
estava estática, sem troca de mensagens. O mesmo não ocorre quanto ao uso de CPU, o que é atribuído
a outras atividades do próprio SO e à manutenção da aplicação ativa pela JVM. Também é possível
perceber o aumento no consumo de memória RAM, quando se compara o cenário com e sem o uso
da AAI4WoT. Percebe-se o aumento de 40,88% no caso em que o Smart Gateway é o cliente. Esse
aumento diferenciado em relação aos demais cenários ocorre pelo fato de que o Smart Gateway é uma
aplicação implantada em um Container Web, o qual precisa alocar memória RAM para carregar a
aplicação e não libera a memória alocada após o carregamento. Apesar disso, o percentual de memória
RAM consumido com a AAI4WoT foi de 51%. Isto mostra que para este cenário, apesar do impacto,
incluir a AAI4WoT é viável para este dispositivo em termos de memória RAM.
Para os casos dos Clientes Desktop e Embarcado, a Tabela 2 mostra que o impacto na memória1 Nas Tabelas desta seção, "Média"foi abreviado como "Méd."e "Desvio Padrão"foi abreviado como "D. Pad.".
109
RAM ao incluir a AAI4WoT é menor do que no caso do cliente Smart Gateway (35,88% e 3,51%
respectivamente). No caso do Cliente Desktop, os experimentos foram realizados em um notebook
com 3GB de memória RAM. Ao se comparar o máximo de memória RAM consumido com e sem a
AAI em relação ao todo, o percentual de memória consumida passa de 0.64% para 0.87%. No caso
do Cliente Embarcado, o percentual de consumo de memória passa de 22,8% sem a AAI4WoT para
23,6% com a AAI4WoT. Assim, pode-se afirmar que, com base nesta métrica, é viável a inclusão da
AAI4WoT para este cenário.
Sobre o consumo de espaço de memória flash/disco, com base na Tabela 2, percebe-se um
aumento da ordem de 1,6% para o Cliente Smart Gateway e de 4,9% para o Cliente Embarcado, que
resultam, principalmente, das bibliotecas adicionais utilizadas. Para o Cliente Desktop, percebe-se um
aumento do consumo de espaço em disco pelo mesmo motivo, da ordem de 2.233,33%.
A respeito do consumo de CPU (Tabela 2), percebe-se uma pequena diferença no caso do
Cliente Embarcado, para os casos com e sem a AAI. Para os clientes Smart Gateway e Cliente Desktop,
os dados mostram que a aplicação sem AAI consome menos CPU do que com a AAI, o que é o
inverso do que se esperava. A causa para esta diferença não foi investigada, mas pode estar relacionada
a otimizações feitas pela JVM em tempo de execução. Contudo, com base nestes dados, pode-se
perceber que não há um impacto negativo no uso de CPU quando se utiliza a AAI4WoT, o que atesta
sua viabilidade neste aspecto.
Tabela 3. Footprint - Dados do SP
AAIMemória
RAM (MiB)Flash ou
Disco (MB)Uso de
CPU (%)Cenário/Métricas Méd. D. Pad. Méd. D. Pad. Méd. D. Pad.
1.170 0 1.875,6 0 0,46 0,75Cliente SG -SP Cloud X 1.234,5 0 1.907,7 0 0,34 0,35
181 0 1.561,4 0 10,58 2,37Cliente Embarcado eDesktop - SP SG X 250 0 1.580,6 0 6,14 2,11
Os dados obtidos para o SP são mostrados na Tabela 3. Os cenários de Cliente Desktop e
Embarcado foram agregados, uma vez que o SP é o mesmo para ambos. Para o caso do cliente Smart
Gateway, houve um aumento de 5,51% no consumo de memória RAM e de 1,71% no consumo de
memória secundária (disco) quando se compara o cenário com e sem a AAI4WoT. O consumo de CPU,
entretanto, manteve-se estável, abaixo de 0,5% e com desvio padrão abaixo de 0,5. Para o caso em que
110
o SP é o Smart Gateway2, ocorre um aumento no consumo de memória RAM e o consumo de CPU
mostra-se o inverso do esperado, como já mencionado.
Quanto à avaliação de consumo de potência elétrica, foram obtidas 50 amostras, com duração
de 1 segundo cada. De cada amostra, foi obtida uma faixa de consumo (mínimo e máximo). Desse
modo, a Tabela 43 apresenta três colunas principais: (i) Menor Consumo de Potência, que apresenta a
média dos valores de consumo mínimo medidos, o desvio padrão e a faixa de valores das amostras
obtidas; (ii) Maior Consumo de Potência, que apresenta a média dos valores de consumo máximo
medidos, o desvio padrão e a faixa de valores das amostras; e (iii) Faixa de Maior Ocorrência, que
apresenta o intervalo de consumo mais frequente e a representatividade deste valor em relação às
demais amostras.
Tabela 4. Footprint - Dados de Consumo de Potência do Cliente
AAIMenor Consumode Potência (W)
Maior Consumode Potência (W)
Faixa de MaiorOcorrência (W/%)Cenário/
Métrica Méd. D. Pad. Faixa Méd. D. Pad. Faixa Faixa Ocorrênc.
1,05 0 1,05 1,1 0 1,11,05a 1,1
100Cliente SG -
SP Cloud X 1,05 0 1,05 1,1 0 1,11,05a 1,1
100
1,01 0,04941 a
1,351,11 0,0749
1,1 a1,6
1 a1,1
96Cliente Emb.
- SP SG X 1,01 0,0841 a1,6
1,11 0,0841,1 a1,7
1 a1,1
98
As medições de consumo de potência do cliente são mostradas na Tabela 4. É possível perceber
que não houve alterações no consumo de potência para o caso em que o cliente é o Smart Gateway,
ao comparar o cenário com e sem a AAI4WoT. Já para o cenário do cliente embarcado, percebe-se
um aumento nas faixas de consumo mínimo e máximo ao se comparar os cenários com e sem a AAI.
Apesar disso, a faixa de consumo mais frequente mantem-se entre 1 e 1,1 Watts.
As medições de consumo de potência do SP, nos cenários em que o SP está embarcado no
BeagleBone Black, são mostrados na Tabela 5. Percebe-se que ao utilizar a AAI4WoT, o footprint
em termos de potência elétrica é o mesmo do que no cenário em que a AAI não é utilizada. Portanto,2 Este é o mesmo caso da Tabela 2, em que o Smart Gateway é o cliente, haja vista que o Smart Gateway faz papel de
cliente em um cenário e de SP nos outros dois.3 "Cliente Embarcado"foi abreviado como "Cliente Emb.".
111
Tabela 5. Footprint - Dados de Consumo de Potência do SP
AAIMenor Consumode Potência (W)
Maior Consumode Potência (W)
Faixa de MaiorOcorrência(W/%)Cenário/
Métrica Méd. D. Pad. Faixa Méd. D. Pad. Faixa Faixa Ocorrênc.
1,05 0 1,05 1,1 0 1,051,05a 1,1
100Cliente Desk./Emb. - SP SG X 1,05 0 1,05 1,1 0 1,1
1,05a 1,1
100
percebe-se que os impactos no consumo de potência elétrica são muito pequenos ao incluir a AAI4WoT,
tanto para os SPs como para os clientes. Assim, neste aspecto, é viável utilizar a AAI4WoT.
5.2.2 Experimento de Solicitação de Autenticação
O experimento de Solicitação de Autenticação considerou o processo de solicitação de autenti-
cação do cliente para o IdP, desde a montagem da requisição de autenticação até o recebimento da
asserção SAML pelo Cliente Ativo. O experimento foi dividido em 3 etapas, todas avaliadas apenas no
cliente e nos cenários que utilizaram a AAI4WoT: (i) Montagem da requisição autenticação SAML; (ii)
Solicitação de autenticação (com e sem a autenticação única); e (iii) Processo Completo. As métricas
de uso de CPU e de potência elétrica são consideradas apenas para o processo completo, uma vez que
a granularidade das ferramentas utilizadas nos experimentos não permite a separação das etapas com a
precisão adequada. Os resultados são descritos nas seções seguintes.
5.2.2.1 Experimento de Montagem da Requisição de Autenticação SAML
Esta etapa foi avaliada com as métricas de consumo de memória RAM, consumo de espaço
de memória flash/disco e tempo de processamento. Os dados da avaliação são mostrados na Tabela
6. Os dados de consumo de memória RAM do Cliente Desktop foram obtidos considerando apenas
o consumo da aplicação e não de todo o SO, sendo apresentada uma faixa de consumo de memória
em função da variação no consumo da memória do tipo Heap da JVM. Neste caso, o menor valor
representa a média do mínimo de memória consumido nas amostras, enquanto que o maior valor
apresenta a média do máximo de memória consumida. O mesmo ocorre com o desvio padrão para a
métrica de memória RAM. Sobre o consumo de memória de disco do Cliente Desktop, este não foi
medido, pois é estático e igual aos dados do experimento de footprint, pois é composto apenas do
112
arquivo executável e das bibliotecas utilizadas.
Tabela 6. Montagem da Requisição de Autenticação SAML - Dados do Cliente com a AAI
MemóriaRAM (MiB)
Flash ouDisco (MB)
Tempo deProcessamento (ms)Cenário/
Métrica Média Desvio Pad. Média Desvio Pad. Média Desvio Pad.Cliente SG -
SP Cloud284,76 2,7667 1.554,84 4,2299 265,98 607,5731
Cliente Desktop- SP SG
84,76 -85,63
29,2281 -30,1639
- - 366,92 625,6330
Cliente Embarcado- SP SG
153,1 2,2667 1.587,17 0,2068 378,44 2.406,0917
Ao comparar os dados apresentados na Tabela 6 com os dados do experimento de footprint do
cliente (Tabela 2), para o caso do cliente Smart Gateway com uso da AAI, percebe-se um aumento
de 11,67% no consumo de memória RAM e uma diminuição de 0,42% no consumo de espaço de
memória flash (que pode ser atribuído à fatores externos relacionados à JVM ou ao SO, e não à uma
diminuição decorrente de otimizações da aplicação). Para o cenário do Cliente Desktop, percebe-se um
aumento de, pelo menos, 228,08% no consumo de memória RAM. Já quanto ao Cliente Embarcado,
percebe-se um aumento de 29,75% no consumo de memória RAM e uma diminuição de 0,12% no
consumo de espaço de memória flash (que também não é atribuído à otimizações da aplicação, mas a
fatores externos).
O processo de montagem é composto de três etapas: (i) Carregamento da biblioteca OpenSAML;
(ii) Criação da SAML Authentication Request; e (iii) Preparação da SAML Authentication Request
para envio pela rede (conversões de objetos Java e codificação). Percebeu-se, durante os experimentos,
que o carregamento da biblioteca OpenSAML era a operação mais custosa computacionalmente e que
levava mais tempo para ser executada, tendo grande impacto no tempo de execução do processo e
no desvio padrão obtido (Tabela 6). Para o caso do Cliente Smart Gateway, a implementação teve 6
chamadas de carregamento da biblioteca durante as 50 amostras. Nestas amostras, o carregamento da
biblioteca foi responsável por 86% do tempo de processamento, em média. Para o caso do Cliente
Desktop, todas as amostras executaram o carregamento da biblioteca, que foi responsável por 62,97%
do tempo de processamento, em média. Para o Cliente Embarcado, o carregamento da biblioteca foi
feito apenas uma vez nas 50 amostras, sendo responsável por 91,16% do tempo de processamento para
esta amostra especificamente. Nos cenários em que o carregamento foi feito mais de uma vez para
o conjunto de amostras, percebeu-se que o primeiro carregamento da biblioteca durante o tempo de
113
execução da aplicação é o mais custoso e demorado.
Tabela 7. Tempo de processamento da Montagem da Requisição de Autenticação SAML semcarregamento do OpenSAML - com a AAI
Tempo de Processamento (ms)Cenário/Métrica Média Desvio Padrão
Cliente SG -SP Cloud
47,08 55,1076
Cliente Desktop -SP SG
100,16 55,6924
Cliente Embarcado- SP SG
34,71 7,5728
Deste modo, uma otimização para a aplicação seria carregar a biblioteca apenas uma vez,
no início da execução da aplicação. A Tabela 7 mostra os dados de tempo de processamento médio
e desvio padrão, desconsiderando o carregamento da biblioteca OpenSAML e desconsiderando a
primeira execução do processo de montagem da requisição de autenticação. Isso visa simular uma
situação de execução contínua da aplicação, em que a biblioteca é carregada apenas na inicialização.
Diante da comparação com os dados da Tabela 6, é possível perceber uma diminuição de 82,29%
no tempo médio de montagem da requisição para o cenário em que o Smart Gateway é o cliente.
Uma diminuição de 72,70% e de 90,83% são observadas nos cenários do Cliente Desktop e Cliente
Embarcado, respectivamente.
5.2.2.2 Experimento de Solicitação de Autenticação
Esta etapa foi avaliada com as métricas de consumo de memória RAM, consumo de espaço de
memória flash/disco, tempo de processamento e tamanho das mensagens, para os casos com e sem o
uso da autenticação única, apenas no cliente.
Os resultado de consumo de espaço de memória RAM e memória flash/disco são mostrados
na Tabela 8, para o caso sem autenticação única. Neste caso, os dados de memória RAM do Cliente
Desktop são apresentados em uma faixa, em que o primeiro valor representa a média/desvio padrão
dos valores mínimos obtidos e o segundo valor apresenta os valores máximos de média/desvio padrão
para a métrica. O desvio padrão elevado para o consumo de memória RAM do Cliente Desktop é
atribuído às variações do consumo da memória do tipo "Heap", a qual sofre a intervenção periódica da
JVM, via Garbage Collector, para desalocação de memória RAM que não é mais utilizada. Os demais
114
Tabela 8. Solicitação de Autenticação Sem Autenticação Única - com a AAI
Memória RAM (MiB) Flash/Disco (MB)Cenário/Métrica Média Desvio Padrão Média Desvio Padrão
Cliente SG -SP Cloud
303,64 16,8724 1.555,6 2,8023
Cliente Desktop -SP SG
110,16 - 138,25 43,6948 - 46,3343 - -
Cliente Embarcado- SP SG
155,88 3,6715 1.588,77 0,4994
clientes tiveram suas medições feitas considerando o consumo do sistema como um todo, e não apenas
da aplicação.
Tabela 9. Solicitação de Autenticação Com Autenticação Única - com a AAI
MemóriaRAM (MiB)
Flash ouDisco (MB)Cenário/
Métrica Média Desvio Padrão Média Desvio PadrãoCliente SG -
SP Cloud283,09 5,3413 1554,84 4,2299
Cliente Desktop -SP SG
78,33 - 81,83 26,7052 - 25,6443 - -
Cliente Embarcado- SP SG
153,13 2,2659 1587,21 0,2429
Para o caso com autenticação única, os dados obtidos são mostrados na Tabela 9. Ao se
comparar os resultados das Tabelas 8 e 9, percebe-se que o consumo de espaço de memória flash/disco
manteve-se muito próximo nos cenários com e sem autenticação única. O mesmo ocorre para o
consumo de memória RAM no caso do Cliente Embarcado. No caso do cliente Smart Gateway e do
Cliente Desktop, observa-se que, sem autenticação única, houve maior consumo de memória RAM e
também mais variações no consumo, uma vez que o desvio padrão foi mais elevado.
Vale ressaltar que, ao observar os dados das Tabelas 8 e 9, percebe-se que o consumo de
memória RAM sempre ficou dentro das capacidades computacionais do BeagleBone Black, nunca
chegando próximo de 100% de uso deste recurso (sem autenticação única, em média 60,73% e 31,17%
para os clientes Smart Gateway e Embarcado, respectivamente; com autenticação única, em média
56,62% e 30,63% para os clientes Smart Gateway e Embarcado, respectivamente).
115
Tabela 10. Solicitação de Autenticação com e sem Autenticação Única - Tamanho das Mensagens -com a AAI
Sem Autenticação ÚnicaTamanho das Mensagens
Cliente ->IdP (Bytes)Tamanho das Mensagens
IdP ->Cliente (Bytes)Cenário/Métrica Média Desvio Padrão Média Desvio Padrão
Cliente SG -SP Cloud
7.806 0 69.636 0
Cliente Desktop -SP SG
3.298 0 2.8408 0
Cliente Embarcado- SP SG
9.025,16 772,4 92.675,74 20.173,7469
Com Autenticação ÚnicaCliente SG -
SP Cloud1.594 0 2.951 0
Cliente Desktop -SP SG
1.761 0 12.751 0
Cliente Embarcado -SP SG
1.777 0 14.287 0
A Tabela 10 apresenta os dados obtidos para a métrica de tamanho das mensagens trocadas,
para os cenários com e sem autenticação única. O valor médio e desvio padrão foram calculados sobre
a soma de todas as mensagens trocadas entre cliente e IdP, para o caso de uma autenticação completa
(sem autenticação única) ou para a solicitação/resposta de uma Asserção SAML (com autenticação
única). São mostrados os tamanhos médios das mensagens enviadas do cliente para o IdP e vice-versa.
Os valores apresentados foram obtidos de um canal criptografado e são referentes a todos os segmentos
TCP (Transmission Control Protocol) trocados entre as partes em cada caso, incluindo as mensagens
necessárias à criação/manutenção do canal TLS.
Assim, os resultados da Tabela 10 mostram que, para o caso com autenticação única, a
quantidade de dados trocados entre as partes para a obtenção de uma asserção SAML é menor. Isso
ocorre em função do menor número de troca de mensagens para o respectivo caso, conforme descrito
na Seção 4.9.4. Observa-se também que, para o caso com autenticação única, o Cliente Desktop troca
menos dados com o IdP que nos demais casos, o que já era esperado em função do menor número de
troca de mensagens com o IdP, conforme descrito na Seção 4.9.4.
Em relação ao tamanho total das mensagens trocadas entre cliente e IdP durante o processo de
116
autenticação (Tabela 10), é possível perceber que o tamanho das mensagens enviadas pelo IdP para o
cliente, principalmente nos casos sem autenticação única, é bastante elevado. Para que isto possa ser
otimizado, são necessárias melhorias tanto no IdP quanto no fluxo de mensagens entre cliente e IdP.
Tabela 11. Solicitação de Autenticação com e sem Autenticação Única - Tempo de Processamento -com a AAI
Tempo deProcessamento sem
Autenticação Única (ms)
Tempo deProcessamento com
Autenticação Única (ms)Cenário/Métrica Média Desvio Padrão Média Desvio Padrão
Cliente SG - SP Cloud 5.222,08 1.012,5993 1.411,56 883,5856
Cliente Desktop - SP SG 1.400,26 276,8389 747,38 172,8207
Cliente Embarcado - SP SG 5.120,75 931,9628 832,22 124,911
A Tabela 11 apresenta os dados para o tempo total de processamento com e sem autenticação
única. Com a autenticação única, observa-se uma diminuição de 72,97% para o cliente Smart Gateway,
de 46,63% para o Cliente Desktop e de 83,75% para o Cliente Embarcado. Vale ressaltar que os dados
obtidos estão sujeitos à influências da rede de comunicação, mas foram obtidos no mesmo ambiente
de rede (de acordo com cada cenário).
É possível perceber que no processo de obtenção de uma asserção SAML, seja ele com ou sem
autenticação única, a etapa mais custosa é a troca de mensagens com o IdP. Com base nos dados das
Tabelas 7 e 11, pode-se perceber que a operação de montagem da requisição de autenticação possui
tempos de processamento aceitáveis, se (i) comparados com o processo de cálculo do response para
o challenge, que leva em média 485,38ms (desvio padrão de 67,9) para o cliente Smart Gateway e
482,42ms (desvio padrão de 69,55) para o Cliente Embarcado e (ii) ao calcular a participação deste
processo no tempo total de obtenção da SAML Response (os dados das Tabelas 7 e 11 foram somados
e a participação de cada um no todo é mostrada na Tabela 12). Percebe-se, assim, que a troca de
mensagens para autenticação precisa ser melhorada para tornar-se viável neste sentido, principalmente
para os casos em que há mais trocas de mensagens com o IdP (Clientes Smart Gateway e Embarcado).
5.2.2.3 Experimento de Processo de Autenticação Completo
Esta etapa corresponde ao processo completo que o cliente deve executar para se autenticar
(montagem da requisição de autenticação SAML e solicitação de autenticação, apresentadas nas Seções
5.2.2.1 e 5.2.2.2 respectivamente). Os experimentos foram realizados para os cenários com e sem a
117
Tabela 12. Participação dos subprocessos no processo de obtenção de uma asserção SAML - com aAAI
SSOMontagem da
Requisição de AutenticaçãoTroca de Mensagens
com o IdPCenário/Métrica Participação no Tempo Total de Processamento (%)
0,89 99,11Cliente SG -SP Cloud X 3,23 96,77
6,68 93,32Cliente Desktop- SP SG X 11,82 88,18
0,67 99,33Cliente Embarcado- SP SG X 4 96
autenticação única, apenas no cliente. As métricas utilizadas foram o tempo total de processamento, o
consumo de potência e o uso de CPU.
Tabela 13. Processo de Autenticação Completo com e sem Autenticação Única - com a AAI
Tempo deProcessamento sem
Autenticação Única (ms)
Tempo deProcessamento com
Autenticação Única (ms)Cenário/Métrica Média Desvio Padrão Média Desvio Padrão
Cliente SG - SP Cloud 7.174,66 1.804,38 1.422,22 817,9582
Cliente Desktop - SP SG 1.680,26 380,8508 1.027,38 231,1579
Cliente Embarcado - SP SG 5.175,45 941,425 866,91 125,0489
Os dados obtidos para o tempo total de processamento são mostrados na Tabela 13. É possível
perceber o elevado desvio padrão dos dados obtidos, o que justifica-se pelas interferências externas
aos experimentos, como aquelas da rede de comunicação. Percebe-se também, para o caso do cliente
Smart Gateway, uma diminuição de 80,18% do tempo de processamento, quando se compara o caso
sem e com autenticação única. Uma diminuição de 38,86% e de 83,25% é observada para os Clientes
Desktop e Embarcado, respectivamente.
A Tabela 14 mostra os dados referentes ao consumo de CPU do cliente para os cenários com e
sem autenticação única. Os processos sem autenticação única dos cenários do cliente Smart Gateway
e do Cliente Embarcado envolveram o carregamento da biblioteca OpenSAML a cada execução, o
que levou o uso de CPU a 100%. Assim, os dados da Tabela 14 são referentes aos processos que
ocorrem após o carregamento da biblioteca. É possível perceber que para o caso do cliente Smart
Gateway, apesar do uso de CPU chegar a 100% para o limiar máximo nos dois casos (com e sem
118
Tabela 14. Processo de Autenticação Completo com e sem Autenticação Única - Uso de CPU - com aAAI
Sem Autenticação ÚnicaMenor Uso de CPU (%) Maior Uso de CPU (%)Cenário/
Métrica Média D. Pad. Faixa Média D. Pad. FaixaCliente SG - SP Cloud 1,98 2,43 0 a 5,55 90,38 15,9062 50 a 100
Cliente Desktop - SP SG 0 0 0 62,16 12,5047 45 a 85
Cliente Embarcado - SP SG 0 0 0 100 0 100
Com Autenticação ÚnicaCliente SG - SP Cloud 5,27 4,6717 0 a 21,42 45,42 22,6108 8,33 a 100
Cliente Desktop - SP SG 0 0 0 64,95 13,7119 47,61 a 94
Cliente Embarcado - SP SG 0 0 0 68,35 19,1857 43,75 a 100
autenticação única), a média do valor máximo no caso com autenticação única e a faixa de valores
obtidos diminui, o que indica um menor uso de CPU ao longo do tempo. Para o Cliente Desktop, o
uso de CPU manteve-se similar para os dois casos, o que não ocorre com o Cliente Embarcado. Neste
último, a média de uso de CPU do limiar máximo fica abaixo de 100% para o caso com autenticação
única, assim como a faixa de valores máximos de uso de CPU, o que indica um menor uso do recurso
quando comparado ao caso sem autenticação única.
Ao se considerar o processo de autenticação e não apenas o footprint, observa-se que a
AAI4WoT precisa ser otimizada para tornar-se mais viável em termos do tempo de processamento, do
uso de CPU e do tamanho das mensagens. Um dos aspectos que precisa ser refatorado é o carregamento
da biblioteca OpenSAML. Observou-se que esse processo precisa ser executado apenas uma vez,
quando a aplicação é iniciada, o que não ocorre em muitos cenários da AAI4WoT. Os impactos diretos
do carregamento da biblioteca puderam ser observados nas Tabelas 6, 7) e 14.
A Tabela 15 apresenta os dados de consumo de potência elétrica para o processo de autenticação
do cliente, para os casos com e sem autenticação única do cliente Smart Gateway e Cliente Embarcado.
Observa-se que para ambos os clientes, tanto com como sem autenticação única, o consumo mínimo
de potência mantem-se estável. Entretanto, ao se comparar os cenários com e sem autenticação única
quanto ao consumo máximo de potência, há um aumento de 53,57% quando não se tem a autenticação
única, para o cliente Smart Gateway. Para o Cliente Embarcado, o aumento é de 54,05%. Tal aumento
está relacionado às trocas de mensagens que existem na autenticação completa e não existem no
cenário de autenticação única. Tais trocas foram realizadas em todas as amostras sem autenticação
única. Este aumento também está relacionado à carga da biblioteca OpenSAML para todas as amostras
119
Tabela 15. Processo de Autenticação Completo com e sem Autenticação Única - Consumo dePotência - com a AAI
Sem Autenticação ÚnicaMenor Consumode Potência (W)
Maior Consumode Potência (W)
Faixa de MaiorOcorrência (W/%)Cenário/
Métrica Méd. D. Pad. Faixa Méd. D. Pad. Faixa Faixa Ocorrênc.Cliente SG -
SP Cloud1,05 0 1,05 1,72 0,0318
1,65 -1,75
1,05 -1,75
50
Cliente Embarcado- SP SG
1,05 0 1,05 1,71 0,03471,65 -1,75
1,05 -1,7
50
Com Autenticação ÚnicaCliente SG -
SP Cloud1,05 0 1,05 1,12 0,0245
1,1 -1,15
1,05 -1,1
60
Cliente Embarcado- SP SG
1,003 0,0211 -
1,151,11 0,051
1,1 -1,45
1 -1,1
86
sem autenticação única, aspecto que pode ser otimizado, como já comentado anteriormente.
Ao se comparar o consumo de potência da etapa de autenticação (Tabela 15) com o consumo de
potência do experimento de footprint (Tabela 4), percebe-se que o consumo de footprint e do cenário
com autenticação única é similar. Já quanto ao cenário sem autenticação única comparado ao footprint,
percebe-se um aumento na média de consumo máximo da ordem de 53,78% para o cliente Smart
Gateway e de 53,78% para o Cliente Embarcado.
Sobre autenticação única na AAI4WoT, observa-se ao comparar as Tabelas 8 e 9, o benefício
de seu uso em termos de consumo de memória RAM. Em função do menor número de mensagens
trocadas com o IdP, o tamanho total das mensagens trocadas também diminui e torna o processo de
autenticação mais viável neste sentido. Em relação ao tempo de processamento, observa-se também
que o uso da autenticação única permite tornar o processo mais rápido, conforme mostrado nas Tabelas
11 e 13. Benefícios do uso da autenticação única neste cenário também podem ser percebidos no uso
de CPU, conforme a Tabela 14. Em relação ao consumo de potência, observa-se na Tabela 15 uma
redução da faixa de consumo de maior ocorrência, o que é importante ao se considerar a autonomia do
sistema.
120
5.2.3 Experimento de Solicitação de Serviço ao SP
Este experimento considerada o passo a partir do qual é realizada a solicitação do recurso ao
SP. O experimento foi executado para os três clientes, sem o uso da AAI4WoT e com o uso desta.
Tabela 16. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Memória RAM,Flash/Disco e Tempo de Processamento
Sem a AAI4WOTMemória
RAM (MiB)Flash ou
Disco (MB)Tempo de
Processamento (ms)Cenário/Métrica Média D. Pad. Média D. Pad. Média D. Pad.
Cliente SG- SP Cloud
195,08 1,2937 1.548,23 0,9775 4.558,92 2.446,8362
Cliente Desktop- SP SG
18,43-22,60
0,1827-0,1446
- - 49,08 103,0042
Cliente Embarcado- SP SG
118,11 0,4814 1.500,43 0,0012 139,06 488,0755
Com a AAI4WOTCliente SG- SP Cloud
285,07 2,0946 1.561,42 0,7954 8.978,8 3.320,8054
Cliente Desktop- SP SG
72,96-99,62
23,4085-27,9028
- - 3330,98 189,0984
Cliente Embarcado- SP SG
153,21 2,282 1.585,18 13,958 3.477,96 361,9373
A Tabela 16 apresenta os resultados obtidos para as métricas de consumo de espaço em memória
RAM, consumo de espaço de memória flash/disco e tempo de processamento para o cliente. Os dados
de memória RAM do Cliente Desktop são exibidos em uma faixa, composta pela média/desvio padrão
do mínimo mensurado e pela média/desvio padrão do máximo mensurado, em função da maneira como
os dados foram obtidos, como mencionado anteriormente. Também, estes dados sofrem interferência
do Garbage Collector, o que explica o desvio padrão mais elevado que nos demais casos. Observa-se,
ao se comparar os cenários com e sem o uso da AAI4WoT, que ao utilizar a AAI, o consumo médio
de memória RAM do cliente Smart Gateway é aproximadamente 46,13% maior, o que também pode
ser observado no Cliente Desktop (aumento de 295,88% para o mínimo consumido e de 340,8%
para o máximo) e no Cliente Embarcado (aumento de 29,72%). Sobre o consumo de espaço de
memória flash/disco, observa-se um aumento de 0,85% no cliente Smart Gateway e 5,65% no Cliente
Embarcado. O Cliente Desktop não teve dados para esta métrica, uma vez que esta refere-se somente
121
ao tamanho da própria aplicação e mantem-se igual aos resultados do experimento de Footprint.
Apesar dos impactos mostrados na Tabela 16, também observa-se que o consumo esteve dentro
das capacidades computacionais do dispositivo utilizado nos experimentos. Para o cliente Smart
Gateway, o consumo médio foi de 57.01%, para o Cliente Desktop foi de 3.32% e para o Cliente
Embarcado foi de 30.64% sendo, portanto, viável a utilização da AAI4WoT neste caso.
Tabela 17. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Tempo de Processamentocorrigido
AAI Tempo de Processamento (ms)Cenário/Métrica
Média Desvio Padrão4.210,18 168,3453Cliente SG - SP Cloud
X 8.515,08 707,8617
27,65 10,0255Cliente Desktop - SP SGX 3.330,98 189,0984
69,39 19,1895Cliente Embarcado - SP SGX 3.477,96 361,9373
Quanto aos dados de tempo de processamento (Tabela 16), observou-se nas amostras a presença
de outliers nos casos sem AAI4WoT e no caso em que o cliente Smart Gateway utiliza a AAI4WoT.
Tais dados ocorrem em função da inicialização dos frameworks utilizados, tanto no cliente como no
SP, o que ocorre apenas uma vez durante a execução. Ao retirar estes dados das amostras, observa-se
que a média de tempo de processamento e o desvio padrão das solicitações ao SP, por parte do cliente,
diminui. Isso mostra uma tendência de comportamento ao longo do tempo mais fiel à realidade e pode
ser observado na Tabela 17.
Tabela 18. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Tamanho das Mensagens
AAI Tamanho das Mensagens (Bytes)Cliente ->SP SP ->ClienteCenário/Métrica
Média Desvio Padrão Média Desvio PadrãoCliente SG - SP Cloud 423,34 9,1861 91 0
Cliente SG - SP Cloud X 13.193,22 16,9674 148,08 13,5644
Cliente Desktop - SP SG 211 0 213,78 2,9684
Cliente Desktop - SP SG X 11.644,22 37,38 375,33 194,74
Cliente Embarcado - SP SG 211 0 210 0
Cliente Embarcado - SP SG X 13.134,86 6,02 473,66 179,62
122
A Tabela 18 mostra os dados de tamanho das mensagens trocadas entre cliente e SP para este
experimento. O tamanho das mensagens corresponde a todas as trocas, tendo sido obtidas métricas
de todo o segmento TCP. Isso inclui, portanto, além dos dados de aplicação, as trocas necessárias
ao estabelecimento/manutenção do canal TLS. Isto explica o elevado desvio padrão das amostras de
mensagens do SP para os cliente Desktop e Embarcado quando se utiliza a AAI4WoT, uma vez que
há apenas uma mensagem fora do padrão das demais, referente ao envio do certificado digital do SP
para o cliente (apenas o SP é autenticado via certificado digital neste fluxo). Retirando esta amostra da
população, o tamanho médio das mensagens do SP para o Cliente Desktop é de 340 Bytes e do SP para
o Cliente Embarcado é de 448 Bytes, ambos com desvio padrão nulo. Ao se considerar estes dados,
observa-se um aumento de 3.016,46% no tamanho da solicitação enviada do cliente Smart Gateway
para o SP. Do mesmo modo, observa-se um aumento de 5.418,49% para as solicitações do Cliente
Desktop e de 6.125,05% para as solicitações do Cliente Embarcado. No fluxo inverso, as respostas do
SP aumentaram 62,73%, 72,06% e 125,55% para os clientes Smart Gateway, Desktop e Embarcado,
respectivamente. O aumento do tamanho das mensagens do SP para o cliente justifica-se pelo overhead
causado pelo canal TLS. Já o aumento das mensagens do cliente para o SP justifica-se também pelo
overhead do canal TLS mas, principalmente, pela inclusão de uma mensagem SAML no cabeçalho da
requisição HTTP.
Tabela 19. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Consumo de Potência
Menor Consumode Potência (W)
Maior Consumode Potência (W)
Faixa de MaiorOcorrência (W/%)Cenário/
Métrica Méd. D. Pad. Faixa Méd. D. Pad. Faixa Faixa Ocorrênc.Cliente SG -
SP Cloud - S/ AAI1,134 0,2082
1,05 -1,65
1,203 0,22241,1 -1,75
1,05- 1,1
66
Cliente SG -SP Cloud - C/ AAI
1,05 0 1,05 1,11 0,021,1 -1,15
1,05- 1,1
80
Cliente Embarcado- SP SG - S/ AAI
1,009 0,0631 -
1,451,112 0,084
1,1 -1,7
1 -1,1
98
Cliente Embarcado- SP SG - C/ AAI
1,028 0,0951 -
1,351,131 0,0953
1,1 -1,45
1 -1,1
88
A Tabela 19 mostra os dados obtidos para a métrica de consumo de potência nos clientes
Smart Gateway e Embarcado. É possível perceber uma diminuição de aproximadamente 0,1 Watt
no consumo do cliente Smart Gateway, quando este está utilizando a AAI4WoT, o que não era um
resultado esperado, haja vista que não foram feitas otimizações neste sentido. Outro valor que não
era esperado é a diminuição das faixas de consumo mínimo e máximo, quando compara-se o cenário
123
do Cliente Embarcado sem AAI4WoT com o cenário com AAI. Apesar disso, observa-se que para o
Cliente Embarcado, o consumo médio de potência é similar se a AAI4WoT for utilizada ou não.
Ao comparar os dados da Tabela 19 com os dados do experimento de Footprint (Tabela 4),
observa-se, para o cliente Smart Gateway sem AAI, um aumento de 8% no consumo mínimo e de 9,36%
para o consumo máximo. Para o cenário com AAI, o consumo mínimo foi igual ao do experimento de
Footprint, enquanto que o consumo máximo aumentou 0,91%. Para o Cliente Embarcado sem AAI, o
consumo mínimo aumento 0,1%, enquanto que o consumo máximo diminuiu 0,18%. Ao utilizar a AAI,
observa-se um aumento no consumo mínimo do Cliente Embarcado de 1,58% e do consumo máximo
de 1,71%. Contudo, pode-se dizer que não há grades impactos no consumo ao utilizar a AAI4WoT,
haja vista que a faixa de consumo mais frequente mantem-se a mesma, mesmo quando são comparados
os dados deste experimentos com os dados de Footprint (Tabela 4).
Tabela 20. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Uso de CPU
AAI Menor Uso de CPU (%) Maior Uso de CPU (%)Cenário/Métrica Média D. Pad. Faixa Média D. Pad. Faixa
7,36 2,69450 -
9,0954,98 25,4567
26,66- 100
Cliente SG - SP CloudX 1,3 2,0918
0 -4,76
45,15 24,495117,39- 100
0 0 0 2,18 1,34400,51
- 10,1Cliente Desktop - SP SG
X 0 0 0 44,02 16,571725 -85
0 0 0 14,55 13,38955 -100
Cliente Embarcado - SP SGX 0 0 0 63,53 18,4088
38,88- 100
Os dados de uso de CPU dos clientes são apresentados na Tabela 20. Ao comparar os cenários
com e sem a AAI4WoT para o cliente Smart Gateway, observa-se uma diminuição de 82,33% no
consumo médio mínimo de CPU e de 17,88% no consumo médio máximo de CPU. Ao contrário, nos
cenários com os Cliente Desktop e Embarcado, observa-se que o consumo médio mínimo mantem-se
igual, mas o consumo médio máximo aumenta 1.919,27% e 336,63%, respectivamente. Pelo fato de
que as bibliotecas utilizadas foram as mesmas em todos os clientes, essa diferença entre o cenário do
cliente Smart Gateway para os demais cenários pode estar relacionada com o uso do Container Web
124
pelo Smart Gateway, o qual pode realizar otimizações no carregamento/execução da aplicação que não
foram realizadas nos demais cenários, pela ausência de um Container Web nestes casos.
Tabela 21. Solicitação ao SP com e sem a AAI4WOT - Dados do SP
AAIMemória
RAM (MiB)Flash ou
Disco (MB)Tempo de
Processamento (ms)Cenário/Métrica Média D. Pad. Média D. Pad. Média D. Pad.
1.250 14,0712 1.875,96 0,0058 3.982,86 128,8023Cliente SG- SP Cloud X 1.461,06 7,1601 1.920,23 0,3415 7.836,18 1.089,9178
185,93 0,5789 1.550,52 0,0044 0,29 0,7948Cliente Embarcadoe Desktop - SP SG X 268,9 2,3169 1.565,33 0,1763 3.078,14 140,1422
Os dados de consumo de memória RAM, consumo de espaço de memória flash/disco e tempo de
processamento da solicitação para os SPs são mostrados na Tabela 21. Os cenários de Cliente Desktop
e Embarcado foram agregados, haja vista que o SP é o mesmo. Para o caso do cliente Smart Gateway,
quando se compara o cenário sem AAI4WoT com o cenário em que a AAI é utilizada, percebe-se
um aumento de 16,88% no consumo de memória RAM, 2,36% no consumo de espaço em disco e
de 96,75% no tempo de atendimento da requisição. Para o cenário do Cliente Embarcado/Desktop,
ao fazer a mesma comparação, observa-se um aumento de 44,62% no consumo de memória RAM,
de 0,96% no consumo de espaço da memória flash e de 1.061.327,59% no tempo de atendimento da
solicitação. O aumento no tempo de atendimento da solicitação para o caso da AAI4WOT deve-se,
principalmente, ao tempo adicional necessário à tomada de decisão de autorização, realizada fora do
SP.
Tabela 22. Solicitação ao SP com a AAI4WOT - Dados do SP - Tamanho das Mensagens
Tamanho das Mensagens SP ->PDP (Bytes)SP ->PDP PDP ->SPCenário/Métrica
Média Desvio Padrão Média Desvio PadrãoCliente SG - SP Cloud 5.580 0 14.393 0
Cliente Embarcado eDesktop - SP SG
3.099,1 175,7 803,56 1.928,92
Os dados de tamanho das mensagens trocadas entre SP e PDP, quando a aplicação de WoT
usa a AAI4WoT, são mostrados na Tabela 22. Os dados dos Clientes Embarcado e Desktop foram
novamente agregados. Para este último caso, observa-se um desvio padrão elevado, resultante de uma
das amostras que contém a troca de certificados digitais entre SP e PDP para estabelecimento do canal
125
TLS. Ao desconsiderar essa amostra, a média de tamanho da mensagem do SP para o PDP cai para
3074 Bytes e do PDP para o SP cai para 528 Bytes, com desvio padrão nulo para ambos.
Tabela 23. Solicitação ao SP com e sem a AAI4WOT - Dados do SP - Uso de CPU
AAIMenor Uso de
CPU (%)Maior Uso de
CPU (%)Cenário/Métrica Média D. Pad. Faixa Média D. Pad. Faixa
0,76 0,41090 -
1,569,1 17,603
0,72 -87,96
Cliente SG -SP Cloud X 62,79 23,1919
0 -87,11
90,61 11,0770,65 -
100
10,01 4,33735,15 -30,2
10,01 4,33735,15 -30,2Cliente Embarc. e Desk.
- SP SG X 0 0 0 100 0 100
A Tabela 23 mostra os dados de uso de CPU do SP para os casos com e sem o uso da AAI4WoT.
Para o caso do cliente Smart Gateway, em que o SP está na Nuvem, ocorre um aumento de 8.160,53%
no uso mínimo de CPU, enquanto que o uso máximo aumenta 895,71%. Para o caso sem o uso da
AAI dos Clientes Desktop e Embarcado, em que o SP está embarcado em um BeagleBoneBlack, o
tempo de processamento é muito curto para uma medição precisa de uma faixa de valores, conforme
mostrado na Tabela 21 e, por isso, os dados de consumo mínimo e máximo são iguais. Neste caso, ao
utilizar a AAI4WoT, percebeu-se que o uso de CPU variou em todas as amostras de 0% a 100%.
Tabela 24. Solicitação ao SP com e sem a AAI4WOT - Cenário Cliente Embarcado - Dados do SP
Menor Consumode Potência (W)
Maior Consumode Potência (W)
Faixa de MaiorOcorrência (W/%)Cenário/
Métrica Méd. D. Pad. Faixa Méd. D. Pad. Faixa Faixa Ocorrênc.
Sem a AAI4WoT 1,06 0,07751 -1,6
1,13 0,09911,1 -1,8
1,05- 1,1
74
Com a AAI4WoT 1,6 0,07471,45- 1,7
1,75 0,01581,7 -1,85
1,65 -1,75
62
A Tabela 24 apresenta os dados de consumo de potência para o caso em que o SP é embarcado
em um BeagleBone Black. É possível perceber que, quando o SP utiliza a AAI4WoT, ocorre um
aumento de 50,94% na média de consumo mínimo de potência e de 54,87% na média de consumo
máximo. Por meio dos dados da Tabela 24, pode-se inferir também que o impacto observado implica
126
em um maior consumo de potência elétrica no decorrer do tempo, uma vez que a faixa de consumo
mais frequente aumenta aproximadamente 59%.
Tabela 25. Solicitação ao SP com a AAI4WOT - Dados do PDP
MemóriaRAM (MiB)
Tempo deProcessamento (ms)Cenário/
Métrica Média Desvio Padrão Média Desvio PadrãoCliente SG - SP Cloud 1.461,06 7,1602 14,7 7,953
Cliente Embarcado/Desktop - SP SG 1.380,53 0,2671 16,72 7,4479
Os dados de consumo de memória RAM do PDP e do tempo de processamento das requisições
são apresentados na Tabela 25. No cenário em que o cliente é o Smart Gateway, o PDP está na mesma
máquina virtual do SP, alocada em uma infraestrutura de Nuvem. No cenário dos Clientes Desktop
e Embarcado, o PDP está alocado na Nuvem e o SP está embarcado em um BeagleBone Black. Ao
executar o SP e o PDP na mesma máquina virtual, é natural que exista um maior consumo de memória
RAM, como pode ser visto na Tabela 25.
Ao se observar os dados das Tabelas 17 e 21 em conjunto, percebe-se que a maior parte do
tempo de processamento da solicitação sem AAI reside no tempo para a mensagem ir do cliente ao
SP e do SP para o cliente. Para o cenário com AAI, observa-se que, além do tempo de envio das
mensagens, o tempo para envio da solicitação de decisão de autorização para o PDP compõe a maior
parte do tempo de processamento. Ao analisar estes dados junto com os dados da Tabela 25, percebe-se
que o tempo de tomada de decisão de autorização pelo PDP é pequeno. Portanto, pode-se inferir que a
maior parte do tempo de processamento da solicitação de serviço ao SP reside no envio/recebimento e
trânsito pela rede de mensagens trocadas entre os componentes. Com base nisso, pode ser inviável
utilizar a AAI4WoT em ambientes de rede em que a taxa de transferência do canal de comunicação
seja muito restrita.
5.2.4 Experimento do Processo Completo
O processo completo de obtenção do recurso desejado pelo cliente foi mensurado, para os
casos com e sem a AAI4WoT e para os casos com e sem autenticação única. Para isto, foram utilizadas
as métricas de consumo de memória RAM, consumo de espaço da memória flash/disco e tempo total
de processamento. A Tabela 26 apresenta os dados obtidos. Vale ressaltar que os dados dos cenários
sem AAI são os mesmos da Tabela 16, uma vez que sem o uso da AAI4WoT o processo de obtenção
127
do recurso é composto apenas pela solicitação do recurso ao SP e respectiva resposta.
Tabela 26. Processo Completo com e sem a AAI4WOT - com e sem Autenticação Única - Dados doCliente
AAI SSOMemória
RAM (MiB)Flash ou
Disco (MB)Tempo de
Processamento (ms)Cenário/Métrica Média D. Pad. Média D. Pad. Média D. Pad.Cli. SG -SP Cloud
195,08 1,2937 1.548,23 0,9775 4.558,92 2.446,8362
Cli. SG -SP Cloud
X 305,70 13,0084 1.556,54 3,4141 15.106,66 1.713,7693
Cli. SG -SP Cloud
X X 285,38 2,17065 1.561,05 1,7724 9.802,76 1.346,4
Cli. Desk.- SP SG
18,43-22,60
0,1827-0,1446
- - 49,08 103,0042
Cli. Desk.- SP SG
X59,22-97,65
10,37-18,78
- - 5.045,12 652,1111
Cli. Desk.- SP SG
X X66,99-109,83
21,7178-23,4493
- - 4.426,06 576,8967
Cli. Embarc.- SP SG
118,11 0,4814 1.500,43 0,0012 139,06 488,0755
Cli. Embarc.- SP SG
X 158,55 14,3691 1.586,77 14,0603 8.570,72 973,3065
Cli. Embarc.- SP SG
X X 153,22 2,276 1.587,21 0,2429 4.344,87 401,1636
Com base na Tabela 26, é possível perceber que ao utilizar a AAI4WoT no caso do cliente
Smart Gateway, há um aumento no consumo de memória RAM de, em média, 56,7% quando a
autenticação única não é utilizada, contra 46,9% quando se utiliza a autenticação única. O consumo
de espaço da memória flash do cliente aumenta 0,54%, em média, quando não se usa a autenticação
única, e 0,83% quando esta é utilizada. Quanto ao tempo para obter o recurso, ocorre um aumento de
231,36% sem autenticação única e de 115,02% com autenticação única.
Para o cenário do Cliente Desktop (Tabela 26), percebe-se que quando a AAI4WoT é utilizada
sem autenticação única, ocorre um aumento no consumo mínimo de memória RAM 221,32% e de
332,08% para o consumo máximo. Ao utilizar a autenticação única, o consumo mínimo de memória
RAM aumenta 263,48%, enquanto o consumo máximo aumenta 385,97%. Em relação ao tempo para
obter o recurso, ao utilizar a AAI4WoT sem autenticação única, o Cliente Desktop demora 10.179,38%
128
a mais para realizar todo o processo, enquanto que demora 8.918,05% a mais quando a autenticação
única é utilizada.
No cenário do Cliente Embarcado (Tabela 26), o consumo de memória RAM aumenta 34,24%
quando a AAI4WoT é utilizada sem autenticação única. Com autenticação única, há um acréscimo de
29,73% no consumo de memória RAM. O uso de espaço da memória flash também aumenta ao se
utilizar a AAI4WoT, em 5,75% sem autenticação única e 5,78% com autenticação única. Em relação
ao tempo para obter o recurso desejado, este aumenta 6.063,33% ao se utilizar a AAI4WoT sem
autenticação única e 3.024,46% quando esta é utilizada.
5.2.5 Experimento de Vazão da Rede
Figura 23. Experimento de Vazão da Rede - BeagleBone Black atua como SP
O último experimento realizado compreende a métrica de vazão da rede. Este experimento foi
realizado em dois cenários: (i) um cliente de Serviço Web RESTful implementado por meio de uma
129
aplicação Desktop Java, envia mensagens HTTPS para um Serviço Web RESTful embarcado em um
BeagleBone Black; e (ii) um cliente de Serviço Web RESTful embarcado em um BeagleBone Black
envia mensagens HTTPS para um Serviço Web RESTful hospedado em uma máquina virtual de um
ambiente de computação em Nuvem. Nos testes, são variados: (i) o tamanho do corpo das mensagens
HTTPS (os cabeçalhos HTTP não são manipulados); e (ii) um grupo contém uma mensagem SAML
Response arbitrária em um cabeçalho HTTP e outro não. Quando não é feito o uso da AAI4WoT,
o SP apenas atribui o conteúdo da mensagem à uma variável do tipo String e envia uma resposta
do tipo text/plain contendo a String "OK". Quando a AAI4WoT é utilizada, o SP também atribui o
conteúdo do cabeçalho HTTP que contém a mensagem SAML à uma variável do tipo String. Como
resultado, obteve-se o RTT (Round-Trip Time) para cada amostra. Foram obtidas 50 amostras, das quais
a primeira foi excluída por possuir sempre um RTT muito acima das demais, por ser a requisição em
que o canal TLS é estabelecido. Com este experimento, buscou-se avaliar qual o impacto do aumento
do tamanho das mensagens HTTP no desempenho do dispositivo que foi utilizado e qual o impacto da
inserção de uma mensagem SAML no cabeçalho HTTP na métrica de vazão da rede. Vale ressaltar que
as aplicações utilizadas para este experimento não são as mesmas utilizadas nos demais experimentos,
uma vez que buscou-se avaliar apenas o impacto de uma forma genérica.
O gráfico da Figura 23 mostra os resultados do teste de vazão para o cenário em que o
BeagleBone Black atua como SP. No eixo X está a variação de tamanho do vetor de bytes e no eixo Y
a média de RTT para cada variação. É possível perceber que a média de RTT para os casos com e sem
a mensagem SAML no cabeçalho HTTP (com e sem AAI) é similar.
O gráfico da Figura 24 mostra os resultados do experimento para o cenário em que o BeagleBone
Black atua como cliente. É possível perceber, pela análise do gráfico, que os tempos médios de RTT
para os casos com e sem a AAI são também similares.
Sobre o tamanho das mensagens trocadas entre cliente e SP (Tabela 18), observa-se que o uso
da AAI4WoT aumenta o tamanho das mensagens enviadas do cliente para o SP, em função da adição
de uma mensagem SAML ao cabeçalho HTTP da requisição. Contudo, ao se observar os resultados do
experimento de vazão da rede, percebe-se que, mesmo a mensagem sendo maior, o impacto no RTT é
pequeno e aceitável para o ambiente em que os experimentos foram realizados. O impacto ao utilizar a
AAI na métrica de vazão é, em média, de 16,06ms com desvio padrão de 25,18 quando o BeagleBone
é o SP e, em média, 28,83ms com desvio padrão de 22,23 quando o SP está alocado na Cloud. Se for
feita a comparação deste impacto com o tempo total do processo de solicitação/resposta de um recurso
ao SP (ver dados da Tabela 17 para o cenário com AAI4WoT), observa-se que este impacto representa
130
Figura 24. Experimento de Vazão da Rede - Aplicação na Nuvem atua como SP
0.34% do tempo de processamento do cliente Smart Gateway, enquanto representa 0.48% e 0.46% do
tempo de processamento dos Clientes Desktop e Embarcado, respectivamente. Para o fluxo contrário,
do SP para o cliente, observa-se o aumento no tamanho das mensagens em função do uso do TLS,
o qual é menor do que no caso das mensagens enviadas do cliente para o SP. Assim, este aumento
também é considerado aceitável para o ambiente dos experimentos.
5.3 COMPARAÇÃO COM OS TRABALHOS RELACIONADOS
Este trabalho apresentou uma infraestrutura de autenticação e de autorização para a Web das
Coisas (AAI4WoT). Dentre os trabalhos relacionados que apresentam infraestruturas que abordam a
autenticação e a autorização, apenas Akram e Hoffmann (2008b) e Conzon et al. (2012) abordaram
a interoperabilidade de mecanismos de autenticação, contudo apenas para usuários. Neste contexto,
apenas a AAI4WoT abordou a interoperabilidade de diferentes mecanismos de autenticação de usuários
131
e de dispositivos.
Dentre os trabalhos relacionados é possível identificar que apenas Gardel et al. (2013) e Akram
e Hoffmann (2008b) abordaram a autenticação única. Também neste caso, as duas soluções oferecem
esse serviço apenas para usuários. Neste sentido, a AAI4WoT diferencia-se ao permitir a autenticação
única tanto de usuários como de dispositivos.
Em relação às tecnologias utilizadas nas infraestruturas dos trabalhos relacionados, percebe-se
que o uso do SAML, XACML e WS-Policy não é uma inovação, uma vez que foi utilizado também
em Akram e Hoffmann (2008b) e Seitz, Selander e Gehrmann (2013). Entretanto, em Seitz, Selander
e Gehrmann (2013) são utilizadas apenas as asserções SAML e as XACML Obligations, ou seja,
apenas parte do padrão. Além disso, a autenticação não é abordada, apenas a autorização. Em Akram
e Hoffmann (2008b), estes padrões são utilizados para autenticação apenas de usuários. Assim, a
AAI4WoT diferencia-se ao utilizar estas tecnologias para permitir a autenticação de usuários e de
dispositivos.
De modo geral, dentre os trabalhos que abordaram a autenticação, nenhum abordou a auten-
ticação de usuários e de dispositivos na mesma infraestrutura. Assim, a AAI4WoT diferencia-se ao
permitir que usuários e dispositivos usem a mesma infraestrutura para se autenticar.
Quatro trabalhos relacionados abordaram a autenticação e autorização na IoT. Destes, apenas
três são soluções para a WoT (Akram e Hoffmann (2008b), Liu, Xiao e Chen (2012) e Gardel et al.
(2013)), mas nenhum abordou um cenário M2M, em que os dispositivos comunicam-se entre si de
maneira autônoma, sem intervenção humana. O diferencial da AAI4WoT neste aspecto, é abordar a
autenticação e autorização na WoT em um cenário M2M.
Por fim, apesar de todos os trabalhos relacionados abordarem a autorização, apenas em Alam,
Chowdhury e Noll (2011) é apresentada uma abordagem independente de modelo de controle de
acesso. Essa independência é importante na IoT, uma vez que permite que o modelo de controle
de acesso seja definido de acordo com requisitos da aplicação e não imposto pela infraestrutura de
segurança. Isso torna a infraestrutura mais flexível e permite que atenda mais facilmente aplicações
heterogêneas. A AAI4WoT provê essa flexibilidade por meio do uso do XACML. O diferencial, neste
caso, está em abordar, além da autorização, a autenticação de dispositivos e de usuários.
132
6 CONCLUSÃO
Um dos desafios de segurança da IoT é garantir a autenticidade de dispositivos e de usuários
em cenários com múltiplos domínios administrativos de segurança. O problema de pesquisa abordado
neste trabalho foi a autenticação e autorização de usuários e de dispositivos, em que o escopo foi
limitado à (i) garantia da autenticação única de usuários e de dispositivos que utilizam mecanismos de
autenticação heterogêneos em uma mesma infraestrutura, diante de múltiplos domínios de segurança e
(ii) a prover um mecanismo de autorização que permita a implementação de diferentes modelos de
controle de acesso e o uso de políticas de autorização flexíveis.
Para abordar o problema de pesquisa, o trabalho foi dividido em seis etapas. A primeira etapa
consistiu de uma pesquisa bibliográfica visando o conhecimento teórico dos conceitos relacionados,
que também permitiu definir com precisão as lacunas que haviam na literatura e, com isso, a definição
do escopo que seria abordado. A segunda etapa tratou da análise dos trabalhos relacionados que
foram encontrados por meio de uma revisão sistemática da literatura, realizada conforme o protocolo
de busca descrito no Apêndice A. A seleção de trabalhos permitiu identificar aqueles que proviam
infraestruturas de autenticação e/ou autorização para a IoT e não estavam limitados a uma determinada
tecnologia de comunicação ou a um mecanismo de autenticação específico.
A terceira etapa abordou a definição de como a AAI4WoT deveria ser composta para tratar
do problema de pesquisa, bem como permitiu identificar as tecnologias mais adequadas e quais eram
os modos de operação necessários. Em seguida, a quarta etapa tratou da modelagem da AAI4WoT.
A quinta etapa compreendeu a implementação de um protótipo da AAI4WoT e a integração deste à
uma aplicação industrial de WoT. A última etapa consistiu da avaliação dos impactos da inclusão da
AAI4WoT na aplicação industrial de WoT.
O objetivo deste trabalho foi prover autenticação e autorização de usuários e de dispositivos no
cenário de WoT para dispositivos e usuários em domínios de segurança diferentes, por meio de uma
AAI. Para atingir este objetivo, foram definidos quatro objetivos específicos.
O primeiro objetivo consistiu em verificar como diferentes mecanismos de autenticação de
dispositivos e diferentes modelos de controle de acesso podem ser utilizados em uma AAI baseada
nos padrões SAML e XACML. Este objetivo foi atingido por meio da definição da AAI4WoT e seus
componentes, bem como pela implementação do protótipo. Verificou-se que eventos de autenticação
133
de dispositivos que utilizam diferentes mecanismos podem ser representados pelo SAML por meio
de extensões ao padrão, já definidas na própria especificação. Também verificou-se que o SAML é
agnóstico ao mecanismo de autenticação utilizado, o que permitiu que esse objetivo fosse atingido.
Por meio do estudo da especificação XACML, definição da AAI4WoT e implementação do protótipo,
foi possível verificar que o padrão XACML é flexível o bastante para permitir a implementação de
diferentes modelos de controle de acesso.
O segundo objetivo específico tratava de prover, em uma única infraestrutura, a autenticação
única de usuários e de dispositivos diante de diferentes mecanismos de autenticação e diferentes
domínios administrativos. Este objetivo foi atingido por meio da implementação do protótipo da
AAI4WoT, em que foram utilizados dois mecanismos de autenticação no mesmo IdP: (i) via certificados
digitais no formato X.509 (para usuários) e (ii) por meio de um mecanismo desenvolvido com
base no acordo de chaves autenticado não-interativo Sakai-Ohgishi-Kasahara (SAKAI; OHGISHI;
KASAHARA, 2000), no algoritmo criptográfico AES_256 e no protocolo de challenge-response
Needham-Shroeder (NEEDHAM; SCHROEDER, 1978) (para dispositivos). Por meio do protótipo
desenvolvido e dos resultados apresentados, pode-se perceber que a autenticação única também foi
provida para usuários e dispositivos.
O terceiro objetivo específico referiu-se a prover um mecanismo de autorização flexível com
suporte a diferentes modelos de controle de acesso e diferentes políticas de autorização, adequados aos
requisitos de aplicações da IoT. O objetivo foi atingido por meio do desenvolvimento do protótipo
da AAI4WoT e uso do padrão XACML. O uso de atributos específicos de dispositivos na política de
autorização XACML (disponível no Apêndice B) permitiu implementar, como prova de conceito, o
modelo de controle de acesso ABAC, mostrando que o XACML permite representar características dos
dispositivos da IoT. Já o uso de um atributo que representa o papel de um usuário em uma instituição
permitiu a implementação do modelo de controle de acesso RBAC para autorização de usuários,
também como prova de conceito.
O último objetivo específico consistiu em avaliar os impactos do uso da AAI4WoT quando
utilizada em uma aplicação de WoT, em termos do uso de recursos computacionais dos dispositivos.
Este objetivo específico foi atingido por meio dos experimentos e resultados descritos no Capítulo 5.
Pode-se, assim, dizer que o objetivo geral deste trabalho foi alcançado.
O desenvolvimento da AAI4WoT e os resultados apresentados também permitiram confirmar
as hipóteses levantadas. Sobre a primeira hipótese, pode-se afirmar que o uso dos princípios REST e
do protocolo HTTP em uma AAI baseada no modelo de gestão de identidades federadas e no padrão
134
SAML, permite prover (i) a autenticação de usuários e de dispositivos e (ii) a autenticação única diante
de diferentes mecanismos de autenticação frente a múltiplos domínios de segurança, como foi possível
observar no protótipo desenvolvido e na etapa de avaliação.
A segunda hipótese era de que tomar as decisões de autorização fora do dispositivo SP, utili-
zando o padrão XACML e os princípios REST, torna possível o suporte a mecanismos de autorização
flexíveis que refletem as necessidades das aplicações de IoT. Diante do atendimento do objetivo
específico três, do desenvolvimento do protótipo da AAI4WoT e da integração desta a uma aplicação
real de WoT para ambientes industriais inteligentes, é possível afirmar que esta hipótese é verdadeira.
Por fim, a hipótese três consistia de que a inclusão da AAI4WoT em uma aplicação de
IoT implicaria na utilização de mais recursos computacionais dos dispositivos, mas que o uso da
autenticação única reduziria os impactos no consumo destes recursos. Esta hipótese é verdadeira,
conforme quantificado nos resultados apresentados no Capítulo 5.
6.1 CONTRIBUIÇÃO DA DISSERTAÇÃO
A principal contribuição deste trabalho está em prover uma AAI baseada no modelo de gestão
de identidades federadas capaz de prover, na mesma infraestrutura, a autenticação única de dispositivos
e de usuários diante de diferentes mecanismos de autenticação. Outra contribuição está em abordar,
para um cenário que envolve dispositivos autônomos (M2M) e WoT, tanto a autenticação como a
autorização de dispositivos e de usuários. Por fim, percebe-se também como contribuição o provimento
de uma AAI que trate tanto autenticação como autorização, mas que seja flexível quanto à escrita de
políticas de autorização e implementação do modelo de controle de acesso.
6.2 TRABALHOS FUTUROS
São propostos os seguintes trabalhos futuros:
• Concluir a implementação por meio da (i) inclusão dos componentes PIP e PAP e (ii)
implementação no Cliente Ativo da busca e interpretação da política de qualidade de
proteção do SP;
• Implementar o suporte à transformação de mensagens SAML e XACML representadas
em XML para representação JSON, por meio da refatoração das bibliotecas OpenSAML
135
e Balana. Junto com isso, avaliar os impactos do uso dos mecanismos JWT (JSON Web
Token), JWS (JSON Web Signature) e JWE (JSON Web Encryption).
• Avaliar o impacto da utilização de mecanismos que poderiam diminuir o tamanho das
mensagens enviadas, como a compressão gzip;
• Comparar a AAI4WoT com uma implementação do perfil SAML ECP, no mesmo cenário
da aplicação de WoT;
• Avaliar a viabilidade do uso do protocolo SAML Artifact Resolution Protocol em conjunto
com o HTTP Artifact Binding na AAI4WoT;
• Tornar a AAI4WoT compatível com o protocolo CoAP e avaliar a viabilidade de seu uso
com este protocolo;
• Avaliar o uso da AAI4WoT em dispositivos com mais restrições computacionais e de energia
do que o BeagleBone Black; e
• Investigar como operações criptográficas podem ser feitas com segurança em dispositivos
que não possuem um hardware seguro (TPM), uma vez que esta é uma das premissas de
funcionamento da AAI4WoT.
136
REFERÊNCIAS
AHSON SYED A; ILYAS, Mohammad. Near Field Communications Handbook. [S.l.]: CRC Press,2012.
AKRAM, Hasan; HOFFMANN, Mario. Laws of identity in ambient environments: The hydraapproach. In: THE SECOND INTERNATIONAL CONFERENCE ON MOBILE UBIQUITOUSCOMPUTING, SYSTEMS, SERVICES AND TECHNOLOGIES, 2008 – UBICOMM’08.Proceedings... [S.l.], 2008. p. 367–373.
. Supports for identity management in ambient environments-the hydra approach. In: 3RDINTERNATIONAL CONFERENCE ON SYSTEMS AND NETWORKS COMMUNICATIONS,2008. ICSNC’08. Proceedings... [S.l.], 2008. p. 371–377.
AKYILDIZ, I. F.; SU, W.; SANKARASUBRAMANIAM, Y.; CAYIRCI, E. Wireless sensor networks:a survey. Computer Networks, Elsevier North-Holland, Inc., New York, NY, USA, v. 38, n. 4, p.393–422, mar. 2002. ISSN 1389-1286.
ALAM, Sarfraz; CHOWDHURY, Mohammad MR; NOLL, Josef. Interoperability of security-enabledinternet of things. Wireless Personal Communications, Springer, v. 61, n. 3, p. 567–586, 2011.
ANDERSON, James P. Computer Security technology planning study. [S.l.], 1972. Disponível em:<http://csrc.nist.gov/publications/history/ande72.pdf>.
ARANHA, D. F.; GOUVEA, C. P. L. RELIC is an Efficient LIbrary for Cryptography. 2009.<https://github.com/relic-toolkit/relic>.
ATZORI, Luigi; IERA, Antonio; MORABITO, Giacomo. The internet of things: A survey. ComputerNetworks, Elsevier, v. 54, n. 15, p. 2787–2805, 2010.
BABAR, Sachin; MAHALLE, Parikshit; STANGO, Antonietta; PRASAD, Neeli R.; PRASAD,Ramjee. Proposed security model and threat taxonomy for the internet of things (iot). In:MEGHANATHAN, Natarajan; BOUMERDASSI, Selma; CHAKI, Nabendu; NAGAMALAI,Dhinaharan (Ed.). CNSA. [S.l.]: Springer, 2010. (Communications in Computer and InformationScience, v. 89), p. 420–429.
BABAR, Sachin; STANGO, Antonietta; PRASAD, Neeli; SEN, Jaydip; PRASAD, Ramjee. Proposedembedded security framework for internet of things (iot). In: 2ND INTERNATIONAL CONFERENCEON WIRELESS COMMUNICATION, VEHICULAR TECHNOLOGY, INFORMATION THEORYAND AEROSPACE & ELECTRONIC SYSTEMS TECHNOLOGY (WIRELESS VITAE), 2011.Proceedings... [S.l.], 2011. p. 1–5.
BHARGAV-SPANTZEL, Abhilasha; CAMENISCH, Jan; GROSS, Thomas; SOMMER, Dieter. Usercentricity: a taxonomy and open issues. Journal of Computer Security, IOS Press, v. 15, n. 5, p.493–527, 2007.
BONETTO, Riccardo; BUI, Nicola; LAKKUNDI, Vishwas; OLIVEREAU, Alexis; SERBANATI,Alexandru; ROSSI, Michele. Secure communication for smart iot objects: Protocol stacks, use casesand practical examples. In: IEEE INTERNATIONAL SYMPOSIUM ON A WORLD OF WIRELESS,MOBILE AND MULTIMEDIA NETWORKS (WOWMOM), 2012. Proceedings... [S.l.], 2012.p. 1–7.
BUETTNER, Michael; GREENSTEIN, Ben; SAMPLE, Alanson; SMITH, Joshua R.; WETHERALL,David. Revisiting smart dust with rfid sensor networks. In: 7TH ACM WORKSHOP ON HOTTOPICS IN NETWORKS (HOTNETS-VII), 2008. Proceedings. [S.l.]: ACM, 2008.
137
CABARCOS, Patricia Arias; MENDOZA, Florina Almenárez; MARíN-LóPEZ, Andrés;DíAZ-SáNCHEZ, Daniel. Enabling saml for dynamic identity federation management. In:WOZNIAK, Jozef; KONORSKI, Jerzy; KATULSKI, Ryszard; PACH, AndrzejR. (Ed.). Wirelessand Mobile Networking. Springer Berlin Heidelberg, 2009. v. 308, p. 173–184. Disponível em:<http://dx.doi.org/10.1007/978-3-642-03841-9_16>.
CAVOUKIAN, Ann. Mobile near field communications: Keep it secure and private. InformationSystems Security Association Journal, v. 10, n. 8, p. 12–17, 2012.
CERP-IOT. Vision and challenges for realising the Internet of Things. 2010. Disponível em:<http://www.theinternetofthings.eu/sites/default/files/Rob%20van%20Kranenburg/Clusterbook%202009_0.pdf>.
CHADWICK, David W. Federated identity management. In: ALDINI, Alessandro; BARTHE,Gilles; GORRIERI, Roberto (Ed.). Foundations of Security Analysis and Design V. SpringerBerlin Heidelberg, 2009, (Lecture Notes in Computer Science, v. 5705). p. 96–120. Disponível em:<http://dx.doi.org/10.1007/978-3-642-03829-7_3>.
COMMUNITIES, CTEC COMMISSION OF THE EUROPEAN. Future networks and the internet:Early Challenges regarding the Internet of Things. [S.l.], 2008.
CONZON, Davide; BOLOGNESI, Thomas; BRIZZI, Paolo; LOTITO, Antonio; TOMASI,Riccardo; SPIRITO, Maurizio A. The virtus middleware: An xmpp based architecture forsecure iot communications. In: 21ST INTERNATIONAL CONFERENCE ON COMPUTERCOMMUNICATIONS AND NETWORKS (ICCCN), 2012. Proceedings... [S.l.], 2012. p. 1–6.
COUNCIL, National Intelligence. Disruptive Civil Technologies: Six Technologies with PotentialImpacts on US Interests Out to 2025. [S.l.], 2008.
COVINGTON, M. J.; CARSKADDEN, R. Threat implications of the internet of things. In: 5THINTERNATIONAL CONFERENCE ON CYBER CONFLICT. Proceedings... [S.l.]: NATO CCDCOE Publications, 2013.
DIERKS, T.; ALLEN, C. The TLS Protocol. 1999. Disponível em: <https://www.ietf.org/rfc/rfc2246.txt>.
EASTLAKE, D.; REAGLE, J.; SOLO, D.; HIRSCH, F.; ROESSLER, T.; BARTEL, M.; BOYER, J.;FOX, B.; LAMACCHIA, B.; SIMON, E. XML Signature Syntax and Processing (Second Edition).2008. Disponível em: <http://www.w3.org/TR/xmldsig-core>.
FIELDING, Roy T.; TAYLOR, Richard N. Principled design of the modern web architecture. ACMTrans. Internet Technol., ACM, New York, NY, USA, v. 2, n. 2, p. 115–150, maio 2002. Disponívelem: <http://doi.acm.org/10.1145/514183.514185>.
FONGEN, Anders. Identity management and integrity protection in the internet of things. In: THIRDINTERNATIONAL CONFERENCE ON EMERGING SECURITY TECHNOLOGIES (EST), 2012.Proceedings... [S.l.], 2012. p. 111–114.
FU, Zhonglin; JING, Xiaojun; SUN, Songlin. Application-based identity management in m2m system.In: INTERNATIONAL CONFERENCE ON ADVANCED INTELLIGENCE AND AWARENESSINTERNET (AIAI 2011), 2011. Proceedings... [S.l.], 2011. p. 211–215.
GARDEL, Tito; ANDRADE, Nailton; FARIAS, Felix; PRAZERES, Cássio. Autenticação eautorização para acesso a aplicações em um barramento de serviços para a web das coisas.In: 13 SIMPóSIO BRASILEIRO EM SEGURANçA DA INFORMAçãO E DE SISTEMASCOMPUTACIONAIS (SBSEG), 2013. Anais do. [S.l.]: SBC, 2013.
138
GARZOGLIO, G; BESTER, J; CHADWICK, K; DYKSTRA, D; GROEP, D; GU, J; HESSELROTH,T; KOEROO, O; LEVSHINA, T; MARTIN, S; SALLE, M; SHARMA, N; SIM, A; TIMM, S;VERSTEGEN, A. Adoption of a saml-xacml profile for authorization interoperability across gridmiddleware in osg and egee. Journal of Physics: Conference Series, v. 331, n. 6, 2011.
GORLATOVA, M.; SHARMA, T.; SHRESTHA, D.; XU, E.; CHEN, Jiasi; SKOLNIK, A.;PIAO, Dongzhen; KINGET, P.; KYMISSIS, J.; RUBENSTEIN, D.; ZUSSMAN, G. Prototypingenergy harvesting active networked tags (enhants) with mica2 motes. In: 7TH ANNUALIEEE COMMUNICATIONS SOCIETY CONFERENCE ON SENSOR MESH AND AD HOCCOMMUNICATIONS AND NETWORKS (SECON), 2010. Proceedings... [S.l.], 2010. p. 1–3.
GRAF, Sebastian; ZHOLUDEV, Vyacheslav; LEWANDOWSKI, Lukas; WALDVOGEL, Marcel.Hecate, managing authorization with restful xml. In: SECOND INTERNATIONAL WORKSHOP ONRESTFUL DESIGN. Proceedings of. [S.l.]: ACM, 2011. p. 51–58.
GUBBI, Jayavardhana; BUYYA, Rajkumar; MARUSIC, Slaven; PALANISWAMI, Marimuthu.Internet of things (iot): A vision, architectural elements, and future directions. Future GenerationComputer Systems, Elsevier, v. 29, n. 7, p. 1645–1660, 2013.
GUINARD, D.; FISCHER, M.; TRIFA, V. Sharing using social networks in a composable web ofthings. In: 8TH IEEE INTERNATIONAL CONFERENCE ON PERVASIVE COMPUTING ANDCOMMUNICATIONS WORKSHOPS (PERCOM WORKSHOPS), 2010. Proceedings... [S.l.], 2010.p. 702–707.
GUINARD, Dominique; TRIFA, Vlad. Towards the web of things: Web mashups for embeddeddevices. In: WORKSHOP ON MASHUPS, ENTERPRISE MASHUPS AND LIGHTWEIGHTCOMPOSITION ON THE WEB (MEM 2009). Proceedings... [S.l.], 2009.
GUINARD, Dominique; TRIFA, Vlad; MATTERN, Friedemann; WILDE, Erik. From the internet ofthings to the web of things: Resource-oriented architecture and best practices. In: UCKELMANN,Dieter; HARRISON, Mark; MICHAHELLES, Florian (Ed.). Architecting the Internet of Things.[S.l.]: Springer Berlin Heidelberg, 2011. p. 97–129.
GUINARD, Dominique; TRIFA, Vlad; PHAM, Thomas; LIECHTI, Olivier. Towards physicalmashups in the web of things. In: SIXTH INTERNATIONAL CONFERENCE ON NETWORKEDSENSING SYSTEMS (INSS), 2009. Proceedings... [S.l.], 2009. p. 1–4.
GUSMEROLI, Sergio; PICCIONE, Salvatore; ROTONDI, Domenico. A capability-basedsecurity approach to manage access control in the internet of things. Mathematicaland Computer Modelling, v. 58, n. 5–6, p. 1189 – 1205, 2013. Disponível em: <http://www.sciencedirect.com/science/article/pii/S089571771300054X>.
HAMESEDER, Katrin; FOWLER, Scott; PETERSON, Anders. Performance analysis of ubiquitousweb systems for smartphones. In: INTERNATIONAL SYMPOSIUM ON PERFORMANCEEVALUATION OF COMPUTER & TELECOMMUNICATION SYSTEMS (SPECTS), 2011.Proceedings... [S.l.], 2011. p. 84–89.
HAN, Qiyun; LI, Jing. An authorization management approach in the internet of things. Journal ofInformation & Computational Science, v. 9, n. 6, p. 1705–1713, 2012.
HANUMANTHAPPA, Pradeep; SINGH, Sanjay. Privacy preserving and ownership authenticationin ubiquitous computing devices using secure three way authentication. In: INTERNATIONALCONFERENCE ON INNOVATIONS IN INFORMATION TECHNOLOGY (IIT), 2012. Proceedings.[S.l.], 2012. p. 107–112.
HOFFMANN, Mario; BADII, Atta; ENGBERG, Stephen; NAIR, Renjith; THIEMERT, Daniel;MATTHESS, Manuel. Security, trust and privacy supported by context-aware middleware. In: 18thWireless World Research Forum Meeting: Multimedia Goes Mobile (WWRF). [S.l.: s.n.], 2010.p. 1–4.
139
HORROW, Susmita; SARDANA, Anjali. Identity management framework for cloud based internet ofthings. In: FIRST INTERNATIONAL CONFERENCE ON SECURITY OF INTERNET OF THINGS.Proceedings of. [S.l.]: ACM, 2012. p. 200–203.
HU, Vincent C.; FERRAIOLO, David; KUHN, Rick; SCHNITZER, Adam; SANDLIN,Kenneth; MILLER, Robert; SCARFONE, Karen. Guide to Attribute Based AccessControl (ABAC) Definition and Considerations. [S.l.], 2014. Disponível em: <http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf>.
HUMMEN, René; ZIEGELDORF, Jan H; SHAFAGH, Hossein; RAZA, Shahid; WEHRLE, Klaus.Towards viable certificate-based authentication for the internet of things. In: 2ND ACM WORKSHOPON HOT TOPICS ON WIRELESS NETWORK SECURITY AND PRIVACY. Proceedings of. [S.l.],2013. p. 37–42.
ITU. ITU Internet Reports 2005: The internet of things. [S.l.]: International TelecommunicationUnion (ITU), 2005.
. NGN identity management framework. [S.l.]: International Telecommunication Union (ITU),2009. Recommendation Y.2720.
JARA, Antonio J; MARIN, Leandro; SKARMETA, Antonio FG; SINGH, Dhananjay; BAKUL,Gohel; KIM, Daeyeoul. Secure mobility management scheme for 6lowpan id/locator split architecture.In: FIFTH INTERNATIONAL CONFERENCE ON INNOVATIVE MOBILE AND INTERNETSERVICES IN UBIQUITOUS COMPUTING (IMIS), 2011. Proceedings... [S.l.], 2011. p. 310–315.
JINDOU, Jia; XIAOFENG, Qiu; CHENG, Cheng. Access control method for web of things basedon role and sns. In: IEEE 12TH INTERNATIONAL CONFERENCE ON COMPUTER ANDINFORMATION TECHNOLOGY (CIT), 2012. Proceedings... [S.l.], 2012. p. 316–321.
JØSANG, Audun; FABRE, John; HAY, Brian; DALZIEL, James; POPE, Simon. Trust requirements inidentity management. In: 2005 AUSTRALASIAN WORKSHOP ON GRID COMPUTING ANDE-RESEARCH. Proceedings of. [S.l.], 2005. v. 44, p. 99–108.
JØSANG, Audun; POPE, Simon. User centric identity management. In: AUSCERT ASIA PACIFICINFORMATION TECHNOLOGY SECURITY CONFERENCE 2005. Proceedings... [S.l.], 2005.
JUELS, A. Rfid security and privacy: a research survey. Selected Areas in Communications, IEEEJournal on, v. 24, n. 2, p. 381–394, 2006.
KONIDALA, Divyan M; DUC, Dang Nguyen; LEE, Dongman; KIM, Kwangjo. A capability-based privacy-preserving scheme for pervasive computing environments. In: THIRD IEEEINTERNATIONAL CONFERENCE ON PERVASIVE COMPUTING AND COMMUNICATIONSWORKSHOPS, 2005. PERCOM 2005 WORKSHOPS. Proceedings... [S.l.], 2005. p. 136–140.
KOTHMAYR, Thomas; SCHMITT, Corinna; HU, Wen; BRUNIG, Michael; CARLE, Georg. Adtls based end-to-end security architecture for the internet of things with two-way authentication.In: IEEE 37TH CONFERENCE ON LOCAL COMPUTER NETWORKS WORKSHOPS (LCNWORKSHOPS), 2012. Proceedings... [S.l.], 2012. p. 956–963.
LANDWEHR, Carl E. Computer security. International Journal of Information Security, Springer,v. 1, n. 1, p. 3–13, 2001.
LENTO, Luiz Otávio Botelho; FRAGA, Joni da Silva; LUNG, Lau Cheuk. A nova geração de modelosde controle de acesso em sistemas computacionais. In: SIMPOSIO BRASILEIRO EM SEGURANÇADA INFORMAÇAO E DE SISTEMAS COMPUTACIONAIS. Anais do. [S.l.], 2006. p. 152–201.
LI, Ning; WANG, Qing; DENG, Zhongliang. Authentication framework of iiedns based on ldap &kerberos. In: 3RD IEEE INTERNATIONAL CONFERENCE ON BROADBAND NETWORK ANDMULTIMEDIA TECHNOLOGY (IC-BNMT), 2010. Proceedings... [S.l.], 2010. p. 695–699.
140
LIU, Jing; XIAO, Yang; CHEN, CL Philip. Authentication and access control in the internet of things.In: 32ND INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTING SYSTEMSWORKSHOPS (ICDCSW), 2012. Proceedings... [S.l.], 2012. p. 588–592.
LOPEZ, Javier; OPPLIGER, Rolf; PERNUL, Günther. Authentication and authorization infrastructures(aais): a comparative survey. Computers & Security, Elsevier, v. 23, n. 7, p. 578–590, 2004.
MAHALLE, Parikshit; BABAR, Sachin; PRASAD, Neeli R; PRASAD, Ramjee. Identity managementframework towards internet of things (iot): Roadmap and key challenges. In: Recent Trends inNetwork Security and Applications. [S.l.]: Springer, 2010. p. 430–439.
MAHALLE, Parikshit N; ANGGOROJATI, Bayu; PRASAD, Neeli R; PRASAD, Ramjee. Identityauthentication and capability based access control (iacac) for the internet of things. Journal of CyberSecurity and Mobility, v. 1, n. 4, p. 309–348, 2013.
MAHALLE, Parikshit N; ANGGOROJATI, Bayu; PRASAD, Neeli Rashmi; PRASAD, Ramjee.Identity establishment and capability based access control (iecac) scheme for internet of things.In: 15TH INTERNATIONAL SYMPOSIUM ON WIRELESS PERSONAL MULTIMEDIACOMMUNICATIONS (WPMC), 2012. Proceedings... [S.l.], 2012. p. 187–191.
MAHALLE, Parikshit N; PRASAD, Neeli Rashmi; PRASAD, Ramjee. Object classification basedcontext management for identity management in internet of things. International Journal ofComputer Applications, v. 63, n. 12, 2013.
MARTINEZ, D.; BLANES, F.; SIMO, J.; CRESPO, A. Wireless sensor and actuator networks:Charecterization and case study for confined spaces healthcare applications. In: INTERNATIONALMULTICONFERENCE ON COMPUTER SCIENCE AND INFORMATION TECHNOLOGY(IMCSIT 2008), 2008. Proceedings... [S.l.], 2008. p. 687–693.
MAçANEIRO, Marcondes. Um Mecanismo Agregador de Atributos Mediado pelo ClienteAlinhado ao Programa de EGOV.BR. Dissertação (Mestrado) — Universidade do Vale do Itajaí,aug 2013.
MELNIKOV, Ed. A.; ZEILENGA, Ed. K. Simple Authentication and Security Layer (SASL).2006. Disponível em: <http://tools.ietf.org/rfc/rfc4422.txt>.
MINAYO, M. C. de S.; DESLANDES, S. F. Pesquisa social: teoria, método e criatividade. [S.l.]:Vozes, 1994.
MIORANDI, Daniele; SICARI, Sabrina; PELLEGRINI, Francesco De; CHLAMTAC, Imrich. Internetof things: Vision, applications and research challenges. Ad Hoc Networks, Elsevier, v. 10, n. 7, p.1497–1516, 2012.
MOORE, B.; ELLESSON, E.; STRASSNER, J.; WESTERINEN, A. Policy Core InformationModel – Version 1 Specification. 2001. Disponível em: <http://www.ietf.org/rfc/rfc3060.txt>.
NEEDHAM, Roger M; SCHROEDER, Michael D. Using encryption for authentication in largenetworks of computers. Communications of the ACM, ACM, v. 21, n. 12, p. 993–999, 1978.
NGUYEN, Tien-Dung; AL-SAFFAR, Aymen; HUH, Eui-Nam. A dynamic id-based authenticationscheme. In: SIXTH INTERNATIONAL CONFERENCE ON NETWORKED COMPUTING ANDADVANCED INFORMATION MANAGEMENT (NCM), 2010. Proceedings... [S.l.], 2010. p.248–253.
NIST. A SURVEY OF ACCESS CONTROL MODELS (WORKING DRAFT). [S.l.],2009. Disponível em: <http://csrc.nist.gov/news_events/privilege-management-workshop/PvM-Model-Survey-Aug26-2009.pdf>.
OASIS. A Brief Introduction to XACML. 2003. Disponível em: <https://www.oasis-open.org/committees/download.php/2713/Brief_Introduction_to_XACML.html>.
141
. Authentication Context for the OASIS Security Assertion Markup Language (SAML)V2.0. 2005.
. Security and Privacy Considerations for the OASIS Security Assertion MarkupLanguage (SAML) V2.0. 2005.
. Security Assertion Markup Language (SAML) V2.0 - Technical Overview. 2008. Disponí-vel em: <https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf>.
. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML)V2.0 - Errata Composite - Working Draft 06. 2009.
. Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0 - ErrataComposite - Working Draft 05. 2009.
. Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 - ErrataComposite - Working Draft 04. 2009.
. Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 - ErrataComposite - Working Draft 06. 2009.
. eXtensible Access Control Markup Language (XACML) Version 3.0. 2013. Disponível em:<http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.pdf>.
. REST Profile of XACML v3.0 Version 1.0. 2013. Disponível em: <http://docs.oasis-open.org/xacml/xacml-rest/v1.0/xacml-rest-v1.0.pdf>.
RESCORLA, E.; KORVER, B. Guidelines for Writing RFC Text on Security Considerations.2003. Disponível em: <http://www.ietf.org/rfc/rfc3552.txt>.
ROMAN, Rodrigo; NAJERA, Pablo; LOPEZ, Javier. Securing the internet of things. Computer,IEEE Computer Society, v. 44, n. 9, p. 51–58, 2011.
ROTONDI, Domenico; SECCIA, Cristoforo; PICCIONE, Salvatore. Access control & iot: Capabilitybased authorization access control system. In: 1ST IOT INTERNATIONAL FORUM. Proceedings...[S.l.], 2011.
SAINT-ANDRE, Ed. P. Extensible Messaging and Presence Protocol (XMPP): Core. 2004.Disponível em: <http://www.ietf.org/rfc/rfc3920.txt>.
SAKAI, Ryuichi; OHGISHI, Kiyoshi; KASAHARA, Masao. Cryptosystems based on pairing. In:The 2000 Symposium on Cryptography and Information Security, Okinawa, Japan. [S.l.: s.n.],2000. p. 135–148.
SEITZ, Ludwig; SELANDER, Goran; GEHRMANN, Christian. Authorization framework forthe internet-of-things. In: IEEE 14TH INTERNATIONAL SYMPOSIUM AND WORKSHOPSON A WORLD OF WIRELESS, MOBILE AND MULTIMEDIA NETWORKS (WOWMOM).Proceedings... [S.l.], 2013. p. 1–6.
SILVA, Edna Lúcia da; MENEZES, Estera Muszkat. Metodologia da Pesquisa e Elaboração deDissertação. [S.l.]: Editora da UFSC, 2005.
SILVA, Paulo Henrique da. Desenvolvimento de um Smart Gateway para o Monitoramento deMáquinas Industriais. 85 p. Monografia (Trabalho de Conclusão de Curso) — Curso de Ciência daComputação, Universidade do Vale do Itajaí, São José, 2014.
SILVA, Rodrigo Cândido da. Uma Plataforma como um Serviço (PaaS) para o Desenvolvimentode Aplicações de Monitoramento e Controle Industrial. 117 p. Monografia (Trabalho de Conclusãode Curso) — Curso de Ciência da Computação, Universidade do Vale do Itajaí, São José, 2014.
142
SOUZA, Luciana Moreira Sá De; SPIESS, Patrik; GUINARD, Dominique; KÖHLER, Moritz;KARNOUSKOS, Stamatis; SAVIO, Domnic. Socrades: A web service based shop floor integrationinfrastructure. In: The internet of things. [S.l.]: Springer, 2008. p. 50–67.
STALLINGS, W. Criptografia e segurança de redes: princípios e práticas. [S.l.]: Pearson PrenticeHall, 2008.
TORMO, Ginés Dólera; MILLáN, Gabriel López; PéREZ, Gregorio Martínez. Definition of anadvanced identity management infrastructure. International Journal of Information Security,Springer-Verlag, v. 12, n. 3, p. 173–200, 2013. Disponível em: <http://dx.doi.org/10.1007/s10207-012-0189-y>.
TRIFA, Vlad; WIELAND, Samuel; GUINARD, Dominique; BOHNERT, Thomas M. Design andimplementation of a gateway for web-based interaction and management of embedded devices. In:2ND INTERNATIONAL WORKSHOP ON SENSOR NETWORK ENGINEERING (IWSNE 09).Proceedings of. [S.l.], 2009.
ULLTVEIT-MOE, Nils; OLESHCHUK, Vladimir. Mobile security with location-aware role-basedaccess control. In: PRASAD, Ramjee; FARKAS, Károly; SCHMIDT, AndreasU.; LIOY, Antonio;RUSSELLO, Giovanni; LUCCIO, FlaminiaL. (Ed.). Security and Privacy in Mobile Informationand Communication Systems. Springer Berlin Heidelberg, 2012, (Lecture Notes of the Institute forComputer Sciences, Social Informatics and Telecommunications Engineering, v. 94). p. 172–183.Disponível em: <http://dx.doi.org/10.1007/978-3-642-30244-2_15>.
UNIVALI. Produção Acadêmico-Científica: A pesquisa e o ensaio. [S.l.]: Universidade do Vale doItajaí, 2011.
W3C. Web Services Architecture. 2004. Disponível em: <http://www.w3.org/TR/ws-arch/>.
. Web Services Policy 1.5 - Framework. 2007. Disponível em: <http://www.w3.org/TR/ws-policy/>.
WANGHAM, Michelle S; DOMENECH, Marlon C; MELLO, Emerson R de. Infraestruturas deautenticação e de autorização para internet das coisas. In: Minicursos do XIII Simpósio Brasileiroem Segurança da Informação e de Sistemas Computacionais - SBSeg 2013. [S.l.: s.n.], 2013.
WANGHAM, Michelle S; MELLO, Emerson Ribeiro de; BÖGER, Davi da Silva; GUERIOS, Marlon;FRAGA, Joni da Silva. Gerenciamento de identidades federadas. In: Minicurso – SBSeg 2010. [S.l.:s.n.], 2010.
WEBER, Rolf H. Internet of things - new security and privacy challenges. Computer Law &Security Review, v. 26, n. 1, p. 23 – 30, 2010. Disponível em: <http://www.sciencedirect.com/science/article/pii/S0267364909001939>.
XIANG, Chenhui; LI, Xinran. General analysis on architecture and key technologies about internet ofthings. In: IEEE 3RD INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING ANDSERVICE SCIENCE (ICSESS), 2012. Proceedings... [S.l.], 2012. p. 325–328.
XIAOHUI, Xu. Research on safety certification and control technology in internet of things. In:FOURTH INTERNATIONAL CONFERENCE ON COMPUTATIONAL AND INFORMATIONSCIENCES (ICCIS), 2012. Proceedings... [S.l.], 2012. p. 518–521.
YAN, Lu; ZHANG, Yan; YANG, Laurence; NING, Huansheng. The Internet of Things: from rfid tothe next-generation pervasive networked systems. [S.l.]: Auerbach Publications, 2008.
ZENG, Deze; GUO, Song; CHENG, Zixue. The web of things: A survey. Journal ofCommunications, v. 6, n. 6, 2011. Disponível em: <http://ojs.academypublisher.com/index.php/jcm/article/view/jcm0606424438>.
143
ZHANG, Guoping; LIU, Jing. A model of workflow-oriented attributed based access control.International Journal of Computer Network and Information Security (IJCNIS), v. 3, n. 1, p.47–53, 2011.
144
APÊNDICE A – PROTOCOLO DE BUSCA E RESULTADOS DA
REVISÃO SISTEMÁTICA DA LITERATURA
Este apêndice apresenta o protocolo de busca com base no qual foi conduzida a revisão
sistemática da literatura, que possibilitou uma visão do estado da arte sobre o tema dessa dissertação.
Ao final, são apresentados os resultados da revisão sistemática.
A.1 PROTOCOLO DE BUSCA
Esta seção apresenta o protocolo de busca que embasou a revisão sistemática da literatura.
A.1.1 Objeto do Estudo
Levantamento do estado da arte de gestão de identidades em Internet das Coisas (IoT).
A.1.2 Perguntas de Pesquisa
• Questão: Quais mecanismos de gestão de identidades são atualmente empregados em IoT?
• Questão de pesquisa adicional: Quais mecanismos de gestão de identidades abordam a
autenticação ou autorização em IoT?
A.1.3 População
• Mecanismos de gestão de identidades;
• Mecanismos de autenticação ou autorização.
A.1.4 Resultados
• Mecanismos de autenticação em IoT;
• Mecanismos de autorização em IoT;
145
• Mecanismos de gestão de identidades em IoT.
A.1.5 Estratégia Utilizada para Pesquisa dos Estudos Primários
• String de busca:
– Em português: (Internet das Coisas OR IoT OR Dispositivos Inteligentes OR Objetos
Inteligentes) AND (Autenticação OR Autorização OR Gestão de Identidade)
– Em inglês: (Internet of Things OR IoT OR Smart Devices OR Smart Objects OR Ma-
chine to Machine) AND (Authentication OR Authorization OR Identity Management)
• Fontes:
– IEEExplore: http://ieeexplore.ieee.org
– Springer Link: http://link.springer.com/
– Google Acadêmico: http://scholar.google.com.br
– BDBComp: http://www.lbd.dcc.ufmg.br/bdbcomp/bdbcomp.jsp
– ACM Digital Library: http://portal.acm.org
– Periódicos da CAPES: http://www.periodicos.capes.gov.br
– Science Direct: http://www.sciencedirect.com/
A.1.6 Critérios e Procedimentos para a Seleção de Estudos
Os trabalhos serão filtrados a partir dos seguintes critérios:
• Pela análise do título do trabalho;
• Pela análise do resumo e das conclusões do trabalho;
• Pela data de publicação do trabalho (entre 2005 e 2014).
Critérios para inclusão de estudo:
146
• Para a questão primária: Incluir no estudo trabalhos cujos títulos e resumos contenham
informações sobre mecanismos de gestão de identidades em IoT. A conclusão será analisada
para verificar a contribuição do trabalho;
• Para a questão secundária: Os mesmos critérios da questão primária, porém o título e re-
sumo devem conter também a informação sobre autenticação ou autorização em IoT.
Critérios para exclusão de estudo:
• Para a questão primária: Serão excluídos do estudo trabalhos cujos títulos e resumos sejam
conflitantes, ou seja, o título remete a um assunto enquanto o resumo remete a outro;
• Para a questão secundária: Os mesmos critérios da questão primária além de que o título e
resumo que não estejam informando sobre gestão de identidades, autenticação ou autoriza-
ção em IoT.
A.1.7 Lista de Verificação e Procedimentos para Avaliação da Qualidade dos
Estudos
Os estudos serão avaliados em sua qualidade abordando os seguintes aspectos:
• Objetivos: Os objetivos do trabalho devem ser no sentido de estabelecer ou aplicar meca-
nismos de gestão de identidades em Internet das Coisas, abordando mais especificamente
autenticação ou autorização nesse contexto;
• Condução: O projeto deve estar bem referenciado e possuir, preferencialmente, uma etapa
experimental, com a validação das hipóteses. Eventos negativos ocorridos durante o estudo,
como por exemplo, dificuldades quanto à população e os equipamentos, tornarão o trabalho
elegível a ter uma atribuição de menor qualidade.
A.1.8 Reunião de Dados
Os dados a serem extraídos de cada artigo são:
• Título;
147
• Fonte;
• Ano de Publicação;
• Autores;
• Conceito do periódico (Qualis);
• Resumo do Artigo;
• Palavras-chave;
• Tipo do artigo: teórico, experimental ou ambos;
• Principal problema abordado;
• Propriedades de segurança asseguradas;
• Mecanismos de gestão de identidades;
• Interoperabilidade entre tecnologias de autenticação;
• Interoperabilidade entre tecnologias de comunicação;
• Solução proposta;
• Existência de implementação;
• Metodologia ou materiais utilizados;
• Resultados obtidos;
• Métricas de avaliação; e
• Problemas em aberto.
A.2 RESULTADOS DA REVISÃO SISTEMÁTICA DA LITERATURA
A revisão sistemática da literatura conduzida neste trabalho, feita com base no protocolo
descrito na Seção A.1, permitiu a identificação dos trabalhos relacionados. Além da busca conduzida
conforme este protocolo, foi feita uma pesquisa arbitrária sobre o tema Web das Coisas (uma “sub-
área” de Internet das Coisas), a fim de verificar se algum trabalho relevante havia ficado de fora dos
resultados. Por fim, também foi feita uma pesquisa arbitrária nos artigos publicados pela equipe do
148
Hydra Middleware, no site do próprio projeto 1, uma vez que era sabido do autor que este era um
projeto que tratava de gestão de identidades na Internet das Coisas, e que não havia retornado nos
resultados da busca.
A Tabela 27 mostra os resultados dessa etapa do estudo. A coluna “Num. Artigos” mostra a
quantidade de artigos retornados em cada base, sendo que pode haver duplicação de artigos entre as
bases. Foi lido o título de todos os artigos dessa coluna. Os artigos que não foram eliminados pelo
título, tiveram o resumo lido. A coluna “Restrições da Busca” mostra as adaptações que precisaram
ser feitas ao utilizar cada base de pesquisa, para que a busca pudesse ser realizada. Essa adaptações
ocorreram em função das diferenças entre os mecanismos de pesquisa de cada base de busca. Por
exemplo, alguns mecanismos não permitiam a pesquisa de palavras no abstract do artigo, apenas no
título. A coluna “Num. Artigos Lidos” apresenta quantos artigos de uma determinada base foram lidos
por completo. Dos artigos que foram lidos por completo foi retirada a lista de trabalhos relacionados.
Tabela 27. Resultados da Revisão Sistemática da Literatura
Fonte Num. Artigos Restrições da Busca Num. Artigos LidosBDBComp 59 Título 0
IEEExplore 137 – 23
Springer Link 319 Ciência da Computação ou Engenharia 4
Google Acadêmico 89 Título, exceto patentes e citações 13
ACM Digital Library 73 Título e Abstract 3
Periódicos da CAPES 16 Título 1
Science Direct 29 Título, Abstract e Keywords 3
Web das Coisas 3 Título, Abstract e Keywords 2
Hydra Middleware 4 Título, Abstract e Keywords 3
TOTAL – – 52
1 http://www.hydramiddleware.eu/
149
APÊNDICE B – POLÍTICA DE CONTROLE DE ACESSO
UTILIZADA NOS EXPERIMENTOS
Este apêndice descreve em detalhes a política de controle de acesso escrita em linguagem
XACML (mostrada ao final do Apêndice), utilizada na etapa de experimentos. A tag <Policy inicia a
descrição da política em XACML, seguida do atributo xmlns que indica o XML Schema Definition
(XSD) que define a sintaxe do documento XML da política, neste caso o XSD da especificação
XACML. O atributo PolicyId indica o identificador único (no contexto do mesmo PDP) da política.
Uma política em XACML é composta de regras (Rules). As rules servem para avaliar uma
requisição XACML e emitir uma decisão de autorização, caso apliquem-se à requisição em questão.
Assim, o atributo RuleCombiningAlgId define o algoritmo que irá combinar resultados de diferentes
rules, caso mais de uma rule seja aplicável a mesma requisição. Neste caso, o algoritmo escolhido
(deny-overrides) define que se uma rule emitir uma decisão de autorização de negação (deny), não
importa o valor das outras rules, o resultado final de avaliação da policy será deny. Em seguida, o
atributo Version define a versão da política que está sendo descrita.
O elemento XML <Target/>, aberto e fechado na mesma tag, indica que a política é aplicável
a qualquer tipo de requisição. Isso foi adotado pois esta é a única política do sistema, logo esta precisa
ser aplicável a qualquer requisição.
Em seguida, é iniciada a descrição da primeira rule, com a tag <Rule. É descrito seu identi-
ficador com o atributo RuleId e o efeito da regra caso haja um matching desta com a requisição de
decisão de autorização que está sendo avaliada. Neste caso, o efeito é Permit, que indica que a decisão
desta Rule irá permitir o acesso solicitado. A tag Description apresenta uma descrição informal da
Rule. O elemento Target indica a quais requisições esta Rule será aplicada, as quais são indicadas pelos
elementos <Match subsequentes. Para que esta Rule seja aplicável a esta requisição de decisão de
autorização, a requisição deverá possuir os seguintes atributos:
• O atributo urn:aai:subject:subject-device-type, da categoria urn:oasis:names:tc:xacml:1.0:
subject-category:access-subject, do tipo string, com valor igual (em função do atributo Mat-
chId com valor urn:oasis:names:tc:xacml:1.0:function:string-equal) a SmartGatewayAuda-
ces;
• O atributo urn:oasis:names:tc:xacml:1.0:action:action-id, da categoria urn:oasis:names:tc:
xacml:3.0:attribute-category:action, do tipo string, com valor igual a put; e
150
• O atributo urn:oasis:names:tc:xacml:1.0:resource:resource-id, da categoria urn:oasis:names:tc:
xacml:3.0:attribute-category:resource, do tipo string, com valor igual a /product/neocut/de-
vice/machine/property;
Assim, esta Rule aplica-se às requisições do tipo HTTP PUT, em que o subject que requer o
acesso possui um atributo device-type com valor SmartGatewayAudaces e a requisição foi feita ao
recurso /product/neocut/device/machine/property. Esta Rule aplica-se, portanto, ao cenário em que o
Smart Gateway realiza o envio de informações de monitoramento para o serviço de recebimento de
dados na Nuvem.
A segunda Rule, que inicia com outra tag <Rule, também possui o efeito de Permit caso haja
um matching desta com a requisição que está sendo avaliada. Nesta Rule, há duas tags <AllOf> dentro
da tag <AnyOf>. A tag AnyOf tem o efeito de OU dentre os elementos <AllOf> presentes nesta
(qualquer um dos elementos <AllOf> deve ser verdadeiro para que a Rule seja verdadeira), enquanto
que a tag <AllOf> tem o efeito de E entre os elementos Match que a compõe. Assim, para que esta
Rule seja verdadeira, a requisição deve atender um dos dois casos, pelo menos:
1. Em que o Subject é humano, possuir:
• O atributo urn:aai:subject:subject-affiliation, da categoria urn:oasis:names:tc:xacml:1.0:
subject-category:access-subject, do tipo string, com valor igual a Manager; e
• O atributo urn:oasis:names:tc:xacml:1.0:action:action-id, da categoria urn:oasis:names:tc:
xacml:3.0:attribute-category:action, do tipo string, com valor igual a get;
2. Em que o Subject é um dispositivo, possuir:
• O atributo urn:aai:subject:subject-device-type, da categoria urn:oasis:names:tc:xacml:1.0:
subject-category:access-subject, do tipo string, com valor igual a MonitorDevice; e
• O atributo urn:oasis:names:tc:xacml:1.0:action:action-id, da categoria urn:oasis:names:tc:
xacml:3.0:attribute-category:action, do tipo string, com valor igual a get
Assim, esta Rule aplica-se às requisições do tipo HTTP GET destinadas a umSmart Gateway,
em que o cliente é ou um humano (que faz uso da aplicação Cliente Desktop) ou um dispositivo
(que faz uso da aplicação Cliente Embarcado). Se for um humano, este deve possuir um atributo que
representa seu papel (subject-affiliation) com valor Manager. Caso seja um dispositivo, deve possuir
151
um atributo que representa o tipo do dispositivo (device-type) com valor MonitorDevice. Para ambos
os casos, a operação solicitada deve ser do tipo HTTP GET.
Caso nenhuma Rule seja atendida, a política não é aplicável à requisição e o comportamento
padrão do PEP será de negar o acesso ao recurso solicitado.
1 <Policy
2 xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
3 PolicyId="urn:aai:policy:1"
4 RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides"
5 Version="1.0">
6 <Target/>
7 <Rule RuleId="urn:aai:ruleid:1" Effect="Permit">
8 <Description> Para que uma operacao de put no servico de recebimento de dados da Cloud
da Neocut possa ser realizada, o subject deve ser do tipo (deviceType)
SmartGatewayAudaces. </Description>
9 <Target>
10 <AnyOf>
11 <AllOf>
12 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
13 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
SmartGatewayAudaces</AttributeValue>
14 <AttributeDesignator MustBePresent="false" Category="
urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
AttributeId="urn:aai:subject:subject-device-type" DataType="http://
www.w3.org/2001/XMLSchema#string"/>
15 </Match>
16 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
17 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">put</
AttributeValue>
18 <AttributeDesignator MustBePresent="false" Category="
urn:oasis:names:tc:xacml:3.0:attribute-category:action" AttributeId="
urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.
w3.org/2001/XMLSchema#string"/>
19 </Match>
20 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
21 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/
product/neocut/device/machine/property</AttributeValue>
22 <AttributeDesignator MustBePresent="false" Category="
urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId
="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://
152
www.w3.org/2001/XMLSchema#string"/>
23 </Match>
24 </AllOf>
25 </AnyOf>
26 </Target>
27 </Rule>
28 <Rule RuleId="urn:aai:ruleid:2" Effect="Permit">
29 <Description> Para que uma operacao de get em algum recurso da Neocut possa ser
realizada, o subject deve ter papel (subject-affiliation) Manager ou ser um
dispositivo do tipo (subject-device-type) MonitorDevice. </Description>
30 <Target>
31 <AnyOf>
32 <AllOf>
33 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
34 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Manager
</AttributeValue>
35 <AttributeDesignator MustBePresent="false" Category="
urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
AttributeId="urn:aai:subject:subject-affiliation" DataType="http://
www.w3.org/2001/XMLSchema#string"/>
36 </Match>
37 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
38 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">get</
AttributeValue>
39 <AttributeDesignator MustBePresent="false" Category="
urn:oasis:names:tc:xacml:3.0:attribute-category:action" AttributeId="
urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.
w3.org/2001/XMLSchema#string"/>
40 </Match>
41 </AllOf>
42 <AllOf>
43 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
44 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
MonitorDevice</AttributeValue>
45 <AttributeDesignator MustBePresent="false" Category="
urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
AttributeId="urn:aai:subject:subject-device-type" DataType="http://
www.w3.org/2001/XMLSchema#string"/>
46 </Match>
47 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
48 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">get</
153
AttributeValue>
49 <AttributeDesignator MustBePresent="false" Category="
urn:oasis:names:tc:xacml:3.0:attribute-category:action" AttributeId="
urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.
w3.org/2001/XMLSchema#string"/>
50 </Match>
51 </AllOf>
52 </AnyOf>
53 </Target>
54 </Rule>
55 </Policy
154
APÊNDICE C – AUTENTICATION CONTEXT CLASS PARA O
MECANISMO DE AUTENTICAÇÃO UTILIZADO NOS
EXPERIMENTOS
As Figuras 25, 26, 27 e 28 descrevem como o método de autenticação utilizado neste trabalho
foi representado usando a especificação SAML, considerando apenas o caso em que o cliente é o Smart
Gateway. Na Figura 25, as linhas 1 a 7 tratam da definição do Schema XML, definindo um namespace
XML diferente do namespace da especificação SAML. A linha 9 define qual XSD está sendo redefinido.
A linha 12 inicia a redefinição do tipo <AuthnContextDeclarationBaseType>, exigindo a presença dos
elementos <Identification>, <TechnicalProtection> e <AuthnMethod>.
Figura 25. XSD para o contexto de autenticação utilizado nos experimentos - Parte 1
O tipo <IdentificationType>, tipo do elemento <Identification>, é redefinido na linha 28 e
limita, na linha 35, que o atributo nym tenha o valor anonimity. O atributo nym serve para que seja
155
indicado se as ações do subject identificado na asserção SAML correspondente podem ou não ser
vinculadas a um usuário final humano. No caso da aplicação Smart Gateway, isso não é possível, uma
vez que esta é uma aplicação autônoma vinculada apenas à máquina industrial monitorada. Entretanto,
esta não é a semântica adequada. O ideal seria ter a possibilidade de indicar a ausência do usuário
por trás da transação, através de uma extensão do tipo <IdentificationType>, mas isso não é possível.
Desse modo, esse é um dos aspectos inadequados para a IoT, haja vista que é comum ter cenários em
que não há um usuário humano participando da transação.
Figura 26. XSD para o contexto de autenticação utilizado nos experimentos - Parte 2
Na Figura 26, na linha 44, o tipo <TechnicalProtectionBaseType> é redefinido e exige a
presença do elemento <PrivateKeyProtection>. Na sequência, o tipo <PrivateKeyProtectionType>,
156
que é o tipo do elemento <PrivateKeyProtection>, é redefinido e exige a presença dos elementos
<KeyStorage> e <KeySharing>, os quais tem seus tipos redefinidos nas linhas 69 e 83, respectivamente.
A redefinição do tipo <KeyStorageType> na linha 69 exige a presença do atributo medium, sendo o
valor memory (linha 75) o único possível. Essa restrição existe em função da premissa de que o cliente,
para realizar operações criptográficas, deve ter um hardware TPM (Tamper-Proof Module).
Na Figura 27, a redefinição do tipo <KeySharingType> define que este elemento deve ter
um atributo chamado sharing com valor fixo true. Este valor indica que a chave privada é compar-
tilhada/conhecida pela autoridade de autenticação, uma vez que é o IdP que gera a chave privada
do dispositivo. Na linha 91, o tipo <AuthnMethodBaseType> é redefinido e exige a presença dos
elementos <Authenticator> e <AuthenticatorTransportProtocol>. O tipo <AuthenticatorBaseType>,
que é o tipo do elemento <Authenticator>, é redefinido na linha 104 e exige a presença de um elemento
<ComplexAuthenticator>, que tem seu tipo redefinido na linha 117. A redefinição do tipo <Comple-
xAuthenticatorType>, por sua vez, exige a presença dos elementos <SharedSecretChallengeResponse>
e <AsymmetricKeyAgreement>, que tem seus tipos redefinidos nas linhas 128 e 137, respectivamente
(ver Figura 28).
A redefinição do tipo <SharedSecretChallengeResponseType> na linha 128 da Figura 28, exige
a presença do atributo method com valor urn:marlon:SAML:2.0:ac:challengeresponse:Needham_Schroeder,
o qual serve para indicar que foi utilizado um mecanismo de challenge-response para autenticação
e que este mecanismo foi aquele definido por Needham e Schroeder (1978). Esta semântica é espe-
cífica para esta federação, uma vez que só é conhecida pelas entidades que conhecem o namespace
urn:marlon:SAML:2.0:ac. Na linha 137, o tipo <PublicKeyType>, que é o tipo do elemento <Asymme-
tricKeyAgreement> é redefinido. Este elemento indica que o cliente possui uma chave privada e a utili-
zou em um acordo de chave compartilhada com o IdP. A redefinição do tipo <PublicKeyType> obriga
a presença do atributo keyValidation com valor fixo urn:marlon:SAML:2.0:ac:keyAgreement:sakai-
ohgishi-kasahara, o qual indica que o acordo de chave utilizado foi o acordo descrito em Sakai,
Ohgishi e Kasahara (2000). De modo similar ao tipo anterior, esta semântica é específica para esta
federação.
Por fim, a redefinição do tipo <AuthenticatorTransportProtocolType> na linha 146, que é o tipo
do elemento <AuthenticatorTransportProtocol>, exige a presença de um elemento chamado <SSL>, o
qual indica que a troca das informações utilizadas para autenticação, entre cliente e IdP, deu-se sobre
um canal seguro, estabelecido por meio do protocolo SSL. Desse modo, foi possível verificar que o
mecanismo de autenticação de dispositivos utilizado neste trabalho pode ser representado usando a
157
Figura 27. XSD para o contexto de autenticação utilizado nos experimentos - Parte 3
158
especificação SAML.
Figura 28. XSD para o contexto de autenticação utilizado nos experimentos - Parte 4
159
APÊNDICE D – MODELAGEM DO PROTÓTIPO
Para avaliar a AAI4WoT, um protótipo da AAI foi desenvolvido. Este apêndice apresenta a
modelagem da solução proposta, sendo composto por uma descrição dos requisitos funcionais e não-
funcionais dos componentes da AAI4WoT e por diagramas de sequência que mostram o funcionamento
desta. Vale ressaltar que a etapa de registro de dispositivos SP e dispositivos e usuários clientes não foi
modelada.
D.1 REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS DO CLIENTE ATIVO
SAML
A seguir são descritos os requisitos funcionais do Cliente Ativo SAML:
• RF 01: O Cliente Ativo SAML deve ser capaz de buscar a política de qualidade de proteção
do serviço que o cliente deseja acessar;
• RF 02: O Cliente Ativo SAML deve ser capaz de montar uma requisição de autenticação
conforme o protocolo SAML Authentication Request Protocol e a política de qualidade de
proteção recebida do SP, no formato WS-Policy, e enviar essa requisição ao IdP; e
• RF 03: O Cliente Ativo SAML deve ser capaz de requisitar o serviço desejado pelo cliente,
apresentando ao SP, junto com a requisição do serviço, a asserção SAML recebida do IdP.
Os requisitos não-funcionais do Cliente Ativo SAML são:
• RNF 01: O Cliente Ativo SAML só deve se comunicar com IdPs e SPs através de um canal
seguro SSL/TLS; e
• RNF 02: O Cliente Ativo SAML deve estar alinhado aos princípios REST ao solicitar
serviços de SPs e IdPs.
D.2 REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS DO PEP
A seguir, são descritos os requisitos funcionais do dispositivo SP e do PEP:
160
• RF 01: O PEP deve ser capaz de gerar uma requisição de autorização no formato XACML,
com base na requisição do cliente e na asserção SAML recebida, e enviá-la ao PDP;
• RF 02: O PEP deve ser capaz de prover o recurso solicitado pelo cliente caso a autorização
seja concedida pelo PDP;
• RF 03: O PEP deve ser capaz de apresentar ao cliente uma mensagem de erro caso a
autorização de acesso ao recurso seja negada pelo PDP; e
• RF 04: O PEP deve enviar a asserção SAML ao IdP para que esta seja validada e confirmada
a autenticação do dispositivo.
Os requisitos não-funcionais do PEP são:
• RNF 01: O PEP deve ser capaz de estabelecer um canal seguro SSL/TLS com o cliente;
• RNF 02: O PEP deve estar alinhado aos princípios REST ao solicitar serviços ao IdP e ao
PDP; e
• RNF 03: O PEP deve se comunicar com os outros elementos da AAI utilizando canais
seguros mutuamente autenticados estabelecidos por meio do protocolo SSL/TLS.
D.3 REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS DO PAP
A seguir, são descritos os requisitos funcionais do PAP:
• RF 01: O PAP deve prover uma interface para que um usuário administrador gerencie
políticas de controle de acesso no formato XACML; e
• RF 02: O PAP deve ser capaz de recuperar uma política de controle de acesso mediante
solicitação do PDP.
Os requisitos não-funcionais do PAP são:
• RNF 01: O PAP deve estar alinhado aos princípios REST ao interagir com outros compo-
nentes da AAI; e
161
• RNF 02: O PAP deve se comunicar utilizando canais seguros mutuamente autenticados
estabelecidos por meio do protocolo SSL/TLS.
D.4 REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS DO PIP
A seguir, são descritos os requisitos funcionais do PIP:
• RF 01: O PIP, mediante solicitação de informações adicionais para tomada de decisão de
autorização por parte do PDP, deve ser capaz de recuperar tais informações.
Os requisitos não-funcionais do PIP são:
• RNF 01: O PIP deve estar alinhado aos princípios REST ao interagir com outros compo-
nentes da AAI; e
• RNF 02: O PIP deve se comunicar utilizando canais seguros mutuamente autenticados
estabelecidos por meio do protocolo SSL/TLS.
D.5 REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS DO PDP
A seguir são descritos os requisitos funcionais do PDP:
• RF 01: O PDP deve ser capaz de solicitar ao PAP uma política de controle de acesso
adequada a requisição que está sendo avaliada;
• RF 02: O PDP deve ser capaz de avaliar se precisa de informações adicionais, além daquelas
presentes na requisição de decisão de autorização enviada pelo PEP, para tomar uma decisão
de autorização;
• RF 03: O PDP deve ser capaz de solicitar ao PIP por informações adicionais necessárias
para tomar uma decisão de autorização;
• RF 04: O PDP deve ser capaz de tomar uma decisão de autorização; e
• RF 05: O PDP deve ser capaz de enviar a decisão de autorização tomada ao PEP.
Os requisitos não-funcionais do PDP são:
162
• RNF 01: O PDP deve estar alinhado aos princípios REST ao interagir com outros compo-
nentes da AAI; e
• RNF 02: O PDP deve se comunicar utilizando canais seguros mutuamente autenticados
estabelecidos por meio do protocolo SSL/TLS.
D.6 REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS DO IDP
A seguir são descritos os requisitos funcionais do IdP:
• RF 01: O IdP deve ser capaz de autenticar clientes dispositivos ou usuários;
• RF 02: O IdP deve ser capaz de gerar asserções SAML diante de eventos de autenticação
bem-sucedidos;
• RF 03: O IdP deve ser capaz de gerar erros para o cliente diante de eventos de autenticação
mal-sucedidos; e
• RF 04: O IdP deve ser capaz de validar a assinatura digital presente em uma asserção SAML
gerada por um IdP da federação.
Os requisitos não-funcionais do IdP são:
• RNF 01: O IdP deve estar alinhado aos princípios REST ao interagir com outros componen-
tes da AAI e com os clientes;
• RNF 02: O IdP deve se comunicar com outros elementos da AAI utilizando canais seguros
mutuamente autenticados estabelecidos por meio do protocolo SSL/TLS; e
• RNF 03: O IdP deve poder se comunicar com um cliente (dispositivo ou usuário) que não
possui certificado digital, utilizando um canal seguro estabelecido por meio do protocolo
SSL/TLS.
D.7 DIAGRAMAS DE SEQUÊNCIA
O diagrama de sequência da Figura 29 mostra como é realizado o acesso de um cliente a um
recurso quando este não possui uma asserção SAML, necessária para que o cliente possa acessar o
163
recurso protegido no dispositivo SP da federação. Inicialmente, o Cliente Ativo SAML solicita ao
dispositivo SP a política de qualidade de proteção do serviço que o cliente deseja acessar, por meio de
uma requisição HTTP GET direcionada à sp111.dominioa.com/recurso/politica. A política é enviada
pelo dispositivo SP ao Cliente Ativo SAML por meio de uma mensagem HTTP 200 OK. O Cliente
Ativo SAML interpreta a política (escrita no padrão WS-Policy) e gera uma requisição de autenticação
SAML (SAMLAuthnRequest) para o IdP.
Dispositivo SP Cliente Ativo
HTTP GETsp111.dominioa.com/recurso/politica
HTTP 200 OKPolítica WS-Policy
Gera SAMLAuthn
Request
IdP do ClienteIdP do SP
HTTP POSTidp.dominiob.com/authn
SAMLAuthnRequest
Verifica Contexto de Segurança
opt
Caso não exista contexto de segurança Finaliza Autenticação
HTTP 200 OKAsserção SAML
Monta requisição
para SPHTTP GET/POST/PUT/DELETEsp111.dominioa.com/recurso
Asserção SAML
HTTP 200 OKRecurso
HTTP POSTidp.aai.dominioa.com/validaassercao
Asserção SAML
HTTP 200 OKAsserção Válida
PDP
HTTP POST - pdp.aai.dominioa.com/decisaoRequisição do Cliente
HTTP 200 OKDecisão de Autorização
Inicia Autenticação
Figura 29. Diagrama de Sequência do Cliente Ativo SAML quando o cliente não possui uma asserçãoSAML
Ao receber a requisição de autenticação, o IdP verifica se o cliente já possui um contexto de
segurança válido no IdP. Se este contexto não existir, o IdP inicia o processo de autenticação do cliente
usando um mecanismo suportado por ambos e aceito pelo SP. Após estabelecer o contexto de segurança
para o cliente, o IdP responde ao Cliente Ativo SAML com uma mensagem SAML Response contendo
uma asserção SAML. De posse da asserção, o Cliente Ativo SAML monta a requisição de serviço para
envio ao dispositivo SP contendo a asserção SAML. Essa requisição é enviada ao recurso desejado
(sp111.dominioa.com/recurso) por meio de algum método HTTP (GET, POST, PUT ou DELETE). O
SP (PEP) solicita ao IdP a validação da asserção SAML apresentada e, após a confirmação da validade
desta, solicita ao PDP uma decisão de autorização acerca da solicitação do cliente. Essa decisão é
164
tomada pelo PDP e encaminhada ao dispositivo SP. Com base nisso, o dispositivo SP responde ao
Cliente Ativo SAML com o recurso solicitado ou com um erro HTTP.
A Figura 30 mostra o diagrama de sequência que modela o processo de tomada de decisão
de autorização de acesso a um determinado recurso, o qual é feito pela AAI4WoT. O processo inicia
quando o PEP encaminha ao IdP a solicitação de validação da asserção SAML recebida e recebe
como resposta que a asserção é válida. O PEP então encaminha ao PDP uma requisição de decisão de
autorização. O PDP solicita ao PAP uma política de controle de acesso adequada para a solicitação.
Após receber a política do PAP, caso necessário, o PDP solicita ao PIP informações adicionais para
que a decisão de autorização possa ser tomada. Diante da resposta do PIP, o PDP toma a decisão de
autorização e a envia ao PEP, o qual aplica a decisão tomada.
PEP IdP
HTTP POSTidp.aai.dominioa.com/validaassercao
Asserção SAML
PDP
opt
Caso faltem informações ao PDP para tomada de decisão
PAP PIP
HTTP POST - pdp.aai.dominioa.com/decisaoRequisição do Cliente
HTTP POSTpap.aai.dominioa.com/buscapolitica
Infos. RequisiçãoBusca
Política
HTTP 200 OK - Informações Solicitadas
HTTP POST - pip.aai.dominioa.com/maisinfoInformações Necessárias
Busca Informações
Toma decisão de autorizaçãoHTTP 200 OK - Decisão de Autorização
HTTP 200 OK - Asserção Válida
HTTP 200 OKPolítica de Controle de Acesso
Figura 30. Diagrama de Sequência da tomada de decisão de autorização