Implementação de Sticky Policies em um provedor OpenID Connect

(1)

Universidade Federal de Santa Catarina

Implementac

¸˜

ao de Sticky Policies em um

provedor OpenID Connect

Lucas Maltempi Monfardine

Thiago de Andrade ´

Avila

(2)

Universidade Federal de Santa Catarina

Centro Tecnol´

ogico

Departamento de Inform´

atica e Estat´ıstica

Curso de Sistemas de Informac¸˜

ao

Implementac

¸˜

ao de Sticky Policies em um

provedor OpenID Connect

Lucas Maltempi Monfardine

Thiago de Andrade ´

Avila

Florian´

opolis - SC

2017/1

(3)

Lucas Maltempi Monfardine

Thiago de Andrade ´

Avila

Implementac

¸˜

ao de Sticky Policies em um provedor

OpenID Connect

Trabalho de Conclus˜

ao de Curso apresentado

como parte dos requisitos para obten¸c˜

ao do

grau de Bacharel em Sistemas de Informa¸c˜

ao.

Carla Merkle Westphall

Universidade Federal de Santa Catarina

Banca Examinadora:

Gabriel Beims Br¨

ascher

Universidade Federal de Santa Catarina

Gerson Luiz Camillo

Universidade Federal de Santa Catarina

Jorge Werner

(4)

Sum´

ario

Lista de ilustra¸

c˜

oes

. . . .

5

1 INTRODUC

¸ ˜

AO

. . . .

8

1.1 OBJETIVO GERAL

. . . .

9

1.2 OBJETIVOS ESPEC´IFICOS . . . .

9

1.3 TRABALHOS RELACIONADOS . . . .

9

2 FUNDAMENTAC

¸ ˜

AO TE ´

ORICA . . . 10

2.1 IDENTIDADE . . . 10

2.1.1 _{PERSONALLY IDENTIFIABLE INFORMATION - PII . . . 10}

2.1.2 Autenticac

¸˜

ao . . . .

11

2.1.3 Autorizac

¸˜

ao . . . .

11

2.1.4 Provedor de Identidade . . . .

12

2.1.5 Provedor de Servic

¸o . . . .

12

2.2 GERENCIAMENTO DE IDENTIDADES . . . 12

2.2.1 _{OpenID Connect . . . .}

13

2.2.1.1 CLAIMS

. . . .

17

2.3 POL´ITICAS DE PRIVACIDADE . . . 17

2.3.1 _{Sticky Policies . . . .}

20

2.4 FERRAMENTAS DE DESENVOLVIMENTO . . . 20

2.4.1 JavaScript . . . .

20

2.4.1.1 Node.js

. . . .

21

2.4.2 NoSQL

. . . .

22

2.4.2.1 MongoDB

. . . .

22

3 PROPOSTA: POL´ITICAS DE PRIVACIDADE NO OPENID

CON-NECT . . . 24

3.1 Problema

. . . 25

3.2 Modelo Inicial . . . 25

3.3 Desenvolvimento . . . 26

3.4 Recursos de Software

. . . 26

3.4.1 _{Servidor MongoDB . . . .}

27

3.4.2 _{Cliente OpenID Connect}

. . . .

27

3.4.3 _{Provedor de Identidades OpenID Connect . . . .}

30

(5)

5 CONSIDERAC

¸ ˜

OES FINAIS . . . 42

5.1 Trabalhos Futuros

. . . 42

6 REFERˆ

ENCIAS

. . . 44

Apˆ

endice

. . . 48

A

CLASSES MODIFICADAS NO NODE-OPENID-CLIENT . . . 49

A.1 index.js . . . 49

A.2 app.js . . . 50

A.3 client.js . . . 57

B

CLASSES MODIFICADAS NO NODE-OIDC-PROVIDER . . . 79

B.1 index.js . . . 79

B.2 express.js

. . . 83

B.3 default.js . . . 84

B.4 settings.js . . . 94

B.5 account.js . . . 98

C

ARTIGO

. . . 104

(6)

Lista de ilustrac¸˜

oes

Figura 1 – Diagrama de especifica¸c˜

oes e guia de implementa¸c˜

ao (OpenID) . . . . .

14 Figura 2 – Fluxo de autentica¸c˜

ao atrav´

es do protocolo OpenID Connect (OpenID)

15 Figura 3 – Exemplo de Token ID no formato JWT (Connect2ID)

. . . .

16 Figura 4 – Representa¸c˜

ao de esquema de Sticky Policy

. . . .

20 Figura 5 – Modelo de combina¸c˜

oes de pol´ıticas de privacidade do usu´

ario . . . . .

24 Figura 6 – Tecnologias utilizadas no desenvolvimento do trabalho

. . . .

27 Figura 7 – Defini¸c˜

ao de endere¸co do OP e porta (Fonte: os autores) . . . .

28 Figura 8 – Adi¸c˜

ao das reivindica¸c˜

oes suportadas pelo cliente (Fonte: os autores) .

29 Figura 9 – Informa¸c˜

oes que ser˜

ao utilizadas na requisi¸c˜

ao (Fonte: os autores) . . .

30 Figura 10 – Defini¸c˜

ao de Vari´

avel de Caminho na IDE InteliJ (Os autores) . . . . .

30 Figura 11 – Defini¸c˜

oes para utiliza¸c˜

ao do banco de dados MongDB (Fonte: os autores) 31

Figura 12 – Defini¸c˜

oes de configura¸c˜

ao do provedor de identidades (Fonte: os autores) 32

Figura 13 – (Claims habilitadas no provedor de identidades (Fonte: os autores) . .

32 Figura 14 – Valores do escopo para o provedor de identidades (Fonte: os autores) .

33 Figura 15 – Pol´ıticas definidas no perfil do usu´

ario (Fonte: os autores) . . . .

35 Figura 16 – Configura¸c˜

ao de um novo cliente (Tela apresentada no cliente) (Fonte:

os autores)

. . . .

36 Figura 17 – Registro do emissor definido para o novo cliente (Tela apresentada no

cliente) (Fonte: os autores)

. . . .

37 Figura 18 – Tela de login de usu´

ario (Tela apresentada no cliente) (Fonte: os autores) 38

Figura 19 – Tela de autoriza¸c˜

ao para acesso de mesmo usu´

ario em diferente cliente

(Tela apresentada no cliente) (Fonte: os autores) . . . .

39 Figura 20 – Tela de autoriza¸c˜

ao para acesso de mesmo usu´

ario em um cliente

diferente (Tela apresentada no cliente) (Fonte: os autores) . . . .

39 Figura 21 – Tokens de Acesso e Token ID (Tela apresentada no cliente) (Fonte: os

autores) . . . .

40 Figura 22 – UserInfo Response e Access Token Response (Tela apresentada no cliente)

(Fonte: os autores) . . . .

41

(7)

Resumo

Com o crescente mercado de sistemas web, deve crescer tamb´

em o cuidado das organiza¸c˜

oes

com os dados sens´ıveis dos usu´

arios de seus servi¸cos, em especial dados de identifica¸c˜

ao,

tamb´

em chamados de PII (personally identifiable information), enviados pelos usu´

arios

para as suas aplica¸c˜

oes. Quando usu´

arios compartilham seus dados com um servi¸co, devem

ter controle sobre o uso destes e certeza que o destino destes dados ser´

a cumprido, al´

em

das regras quanto ao seu uso ou divulga¸c˜

ao a terceiros. As pol´ıticas de privacidade s˜

ao os

documentos que destinam-se a ajudar o usu´

ario a entender sobre o tratamento dos dados

ap´

os a coleta. Atrav´

es delas, o usu´

ario ´

e questionado ou informado sobre as informa¸c˜

oes

coletadas, o uso dessas informa¸c˜

oes, o tempo de reten¸c˜

ao ou da divulga¸c˜

ao das mesmas.

O OpenID Connect, que conta com diversas implementa¸c˜

oes Open Source e baseado no

protocolo OAuth 2.0, visa garantir autentica¸c˜

ao e autoriza¸c˜

ao entre um usu´

ario e o servi¸co

desejado. Para tanto, fornece as informa¸c˜

oes sobre o usu´

ario final na forma de um token,

que cont´

em as informa¸c˜

oes b´

asicas de perfil sobre o usu´

ario. Atrav´

es deste trabalho, foi

realizada a implementa¸c˜

ao de uma extens˜

ao em um provedor de identidades que utiliza o

protocolo OpenID Connect, permitindo o envio de pol´ıticas de privacidade no contexto

da utiliza¸c˜

ao do servi¸co, juntamente com as informa¸c˜

oes b´

asicas contidas no token. Para

tal, ´

e utilizado o contexto de Sticky Policies, que agrega as pol´ıticas de privacidade aos

dados do usu´

ario normalmente enviados pelo protocolo OpenID Connect, permitindo que

o usu´

ario de um servi¸co tenha controle sobre a aplica¸c˜

ao e divulga¸c˜

ao de seus dados.

(8)

Abstract

As the web systems market grows up, organizations concern with services classified users

data must grow as well, especially identification data, also called PII - Personally

Identifi-able Information, which is sent from the users to companies applications. When users share

their data with a service, they must have control upon it’s destination and make sure it’s

purpose will be fulfilled, beyond third party usage and disclosure rules. Privacy policy are

documents intended to help final users understand the handling given to their data after

they’ve been collected. Through them the user is questioned or informed about collected

information, it’s usage, retention time or even dissemination. The OpenID Connect, which

has some Open Source implementations and is based on OAuth 2.0, aims on guarantee

authentication and authorization between a user and the desired service. For such, it

provides end-user information in form of a token containing basic information about the

user’s profile. Through this paper an extension to a OpenID Connect identity provider was

implemented, allowing the transmission of privacy policies on service utilization context,

together with basic user information incorporated on token. By that, the context of Sticky

Policies is used, which adds the privacy policies to the user data normally sent by the

OpenID protocol, allowing a user to have control upon application and propagation of it’s

data while using a service.

(9)

1 Introduc

¸˜

ao

Visando mais praticidade na administra¸c˜

ao de ferramentas e seguran¸ca na

delega¸c˜

ao de permiss˜

oes, cresce a utiliza¸c˜

ao de ferramentas de autentica¸c˜

ao (WANGHAM;

DOMENECH; MELO, 2013).

Para gerenciar identidades em ambientes de computa¸c˜

ao podem ser usados os

sistemas de gerenciamento de identidades ou (Identity Management - IdM). Os sistemas de

IdM s˜

ao respons´

aveis pela cria¸c˜

ao, gerenciamento, uso das identidades e pela infraestrutura

que suporta esse conjunto de processos (BERTINO; TAKAHASHI, 2011).

A principal vantagem na utiliza¸c˜

ao desses sistemas de gerenciamento de

identi-dades ´

e a diminui¸c˜

ao da complexidade aos usu´

arios, mitigando a administra¸c˜

ao de uma

quantidade grande de identifica¸c˜

oes e senhas para acesso aos mais diversos servi¸cos e

sistemas (SOUZA; WANGHAM; MELLO, 2014).

Na ´

area de gerˆ

encia de identidades existem atualmente duas ferramentas que

s˜

ao mais conhecidas e vem sendo bastante utilizadas: Shibboleth e OpenID Connect. O

Shibboleth utiliza o padr˜

ao Security Assertion Markup Language (SAML) para trocar

informa¸c˜

oes de seguran¸ca (SWITCH, 2016). O OpenID Connect (OPENID CONNECT,

2016), por sua vez, ´

e constru´ıdo sobre o protocolo OAuth 2.0 (OAUTH, 2016) para prover

uma camada de identidade entre o usu´

ario e a aplica¸c˜

ao desejada.

Dentre as organiza¸c˜

oes que utilizam OpenID Connect est˜

ao o Google e o

Mas-sachusetts Institute of Technology - MIT (OPENID CONNECT, 2016). Mesmo tendo o

mesmo prop´

osito, garantir o acesso de um usu´

ario a um recurso ou servi¸co, o SAML e o

OpenID Connect trabalham de forma diferente. Enquanto o protocolo SAML ´

e baseado

em XML, o OpenID Connect utiliza o formato de dados JSON. Dessa forma, o OpenID

Connect se torna mais adapt´

avel a sistemas embarcados, aplicativos para dispositivos

m´

oveis e aplica¸c˜

oes web, enquanto o SAML se limita apenas a aplica¸c˜

oes web. As limita¸c˜

oes

da tecnologia SAML no suporte a dispositivos m´

oveis e sistemas embarcados, como de

Smart-TVs por exemplo, est´

a garantindo ao OpenID Connect maior aplica¸c˜

ao na ´

area de

servi¸cos de autentica¸c˜

ao (SCHWARTZ, 2016; SALDANHA, 2013).

Existem situa¸c˜

oes que os usu´

arios necessitam expor seus dados pessoais para

que possam ter acesso a um servi¸co espec´ıfico. Por exemplo, um usu´

ario de um plano de

sa´

ude deve apresentar suas informa¸c˜

oes pessoais para efetuar seu cadastro. O plano de

sa´

ude necessita compartilhar os dados deste usu´

ario com especialistas m´

edicos, profissionais

de sa´

ude e empresas farmacˆ

euticas que s˜

ao aceitas pela rede do plano de sa´

ude. A forma

como os dados s˜

ao compartilhados e as poss´ıveis utiliza¸c˜

oes dos mesmos pelas terceiras

partes, devem ser devidamente descritas e aceitas pelo usu´

ario. Os documentos que definem

estas escolhas s˜

ao chamados pol´ıticas de privacidade, pol´ıticas de uso ou pol´ıticas de acesso,

(10)

dependendo do contexto em que s˜

ao utilizados (PEARSON, MONT, 2011).

1.1 _{OBJETIVO GERAL}

O objetivo geral deste trabalho consiste na utiliza¸c˜

ao de uma adapta¸c˜

ao do

conceito de Sticky Policies afim de permitir a transferˆ

encia de pol´ıticas de privacidade do

usu´

ario em um modelo estendido de token ID, vinculadas aos dados deste usu´

ario em um

provedor de identidades baseado no protocolo OpenID Connect.

1.2 _{OBJETIVOS ESPEC´}

_IFICOS

S˜

ao objetivos espec´ıficos deste trabalho:

• Garantir que o provedor de identidade OpenID Connect fa¸ca o envio do Token ID

com as pol´ıticas de privacidade do usu´

ario junto de seus dados;

• Garantir que o provedor de servi¸co receba o Token ID enviado pelo provedor de

identidade contendo, al´

em das informa¸c˜

oes pessoais do usu´

ario, as pol´ıticas de

privacidade, e fa¸ca o reconhecimento das mesmas;

• Apresentar das pol´ıticas definidas pelo usu´

ario na aplica¸c˜

ao cliente.

1.3 _{TRABALHOS RELACIONADOS}

Existem diversos trabalhos que tratam da utiliza¸c˜

ao de pol´ıticas de privacidade

e Sticky Policies. Villarreal et. al. (2017) define regras para padroniza¸c˜

ao e apresenta¸c˜

ao

das pol´ıticas de privacidade, descrevendo categorias e estruturas para facilitar o uso das

pol´ıticas. Pearson e Mont (2011) descrevem e exemplificam o conceito e a utiliza¸c˜

ao de

Sticky Policies, demonstrando seu uso em estudo de caso do Projeto Encore. O projeto

provˆ

e mecanismos para os usu´

arios definirem e alterarem pol´ıticas de consentimento. Al´

em

disso, utiliza o conceito de Sticky Policies para representar e garantir o consentimento e

revoca¸c˜

ao de preferˆ

encias do usu´

ario final.

(11)

2 Fundamentac

¸˜

ao Te´

orica

Neste cap´ıtulo ser˜

ao apresentados conceitos relevantes ao desenvolvimento

deste trabalho como Identidade, Gerenciamento de Identidade, Sticky Policies, al´

em dos

principais objetos de estudo, as pol´ıticas de privacidade e o protocolo OpenID Connect.

2.1 _IDENTIDADE

A identidade de uma organiza¸c˜

ao ou pessoa consiste em caracter´ısticas

indi-viduais, atrav´

es das quais essa pessoa ou organiza¸c˜

ao s˜

ao conhecidas. Esses elementos

podem ser adquiridos, tais como nome, endere¸co, n´

umeros de registros diversos; ou podem

ser inerentes, tal como a biometria (JØSANG; POPE, 2005).

O RFC 2828 (2000) define credencial como o conjunto de dados que s˜

ao

transfe-ridos ou apresentados para demonstrar uma identidade ou as autoriza¸c˜

oes de uma entidade

nos sistemas. Pela defini¸c˜

ao da ISO/IEC 24760 (2011), credencial ´

e a representa¸c˜

ao de

uma identidade.

Ainda de acordo com a ISO/IEC 24760 (2011), atributos s˜

ao caracter´ısticas

ou propriedades que podem ser utilizadas para descrever o estado, aparˆ

encia ou outros

aspectos das entidades. O conjunto dos valores de atributos em uma identidade descrevem

a entidade em um dom´ınio.

Al´

em da possibilidade do usu´

ario criar atributos para associar `

a sua

identi-dade digital, administradores tamb´

em podem associar atributos `

a esta, como fun¸c˜

oes,

permiss˜

oes de acesso e dados de funcion´

arios mantidos por provedores de identidade e

atributos, sendo estes frequentemente utilizados no suporte `

a decis˜

oes de autoriza¸c˜

ao e

para coletar informa¸c˜

oes de auditoria (STALLINGS, 2011).

Qualquer elemento caracter´ıstico do usu´

ario ou organiza¸c˜

ao pode ser chamado

de identificador quando ´

e usado para fins de identifica¸c˜

ao. Sup˜

oe-se que as identidades

s˜

ao ´

unicas, isto ´

e, n˜

ao h´

a dois seres humanos ou organiza¸c˜

oes com a mesma identidade.

No entanto, a mesma pessoa ou a mesma organiza¸c˜

ao pode ter diferentes identidades em

contextos diferentes (JØSANG et al, 2005).

2.1.1 _{PERSONALLY IDENTIFIABLE INFORMATION - PII}

Personally identifiable information (PIIs) s˜

ao dados que podem ser rastreados

para um determinado indiv´ıduo como nome, endere¸co, n´

umero de telefone, n´

umero do

cart˜

ao de cr´

edito, data de nascimento, entre outros. Devido `

a sua sensibilidade e

(12)

necessi-dade de seguran¸ca, deve-se ter cuidado no manuseio destes dados, principalmente quando

incluem dados financeiros ou m´

edicos.

Em contextos comerciais, consumidores exigem prote¸c˜

ao e o uso cuidadoso dos

PIIs. Para as organiza¸c˜

oes, a privacidade destes dados inclui leis, pol´ıticas, padr˜

oes e

processos para gerenciar as PII de um indiv´ıduo (PEARSON; MONT, 2011).

De acordo com Rouse (2014), um PII ´

e considerado sens´ıvel quando pode

resultar em dano ao indiv´ıduo se a privacidade for violada, ou n˜

ao sens´ıvel, se pode ser

transmitido sem criptografia sem causar dano ao indiv´ıduo. Os PII sens´ıveis, incluem

dados m´

edicos, biom´

etricos, informa¸c˜

oes financeiras e documentos identificadores (CPF e

RG, por exemplo). Os PII n˜

ao sens´ıveis, por outro lado, s˜

ao comumente encontrados em

registros p´

ublicos, abertos em websites e listas telefˆ

onicas.

2.1.2 _Autenticac

_¸˜

_ao

A autentica¸c˜

ao ´

e o processo formalizado de verifica¸c˜

ao de uma identidade

reivindicada por ou para uma entidade (RFC 2828, 2000). Uma entidade ´

e definida pela

RFC 2828 (2000) como um elemento ativo de um sistema, um processo automatizado, um

subsistema, uma pessoa ou um grupo de pessoas, que incorporam um conjunto espec´ıfico de

recursos. De acordo com a ISO/IEC 24760 (2011) uma entidade tamb´

em pode ser definida

como um item dentro ou fora de um sistema de informa¸c˜

ao, como uma pessoa, organiza¸c˜

ao,

um dispositivo, um subsistema, ou um grupo de pessoas que tˆ

em caracter´ısticas distintas.

Os sistemas de inform´

atica em geral utilizam um conjunto de mecanismos

para identificar entidades (elementos ativos, como usu´

arios) que buscam acesso a objetos

(arquivos ou capacidades computacionais, elementos passivos). No ˆ

ambito da verifica¸c˜

ao de

identidade, a maioria dos m´

etodos de autentica¸c˜

ao baseiam-se em um dos trˆ

es princ´ıpios

gerais de identifica¸c˜

ao (TANENBAUM, 2009):

• Algo que o usu´

ario sabe (na utiliza¸c˜

ao de senhas, por exemplo);

• Algo que o usu´

ario tem (por exemplo, posse de um documento que o identifique) e;

• Alguma coisa que o usu´

ario ´

e, ou alguma caracter´ıstica do usu´

ario (autentica¸c˜

ao

biom´

etrica).

Esses princ´ıpios levam a esquemas de autentica¸c˜

ao diversos com diferentes

propriedades e complexidades.

2.1.3 _Autorizac

_¸˜

_ao

Segundo Stallings (2011) , o prop´

osito de autoriza¸c˜

ao ´

e garantir acesso a

servi¸cos ou recursos espec´ıficos baseado na autentica¸c˜

ao. Os mecanismos de autoriza¸c˜

ao

(13)

s˜

ao utilizados para determinar o n´ıvel de acesso que determinada entidade autenticada

deve ter ao servi¸co ou recurso.

Ainda de acordo com Stallings (2011), autoriza¸c˜

ao contribui para reduzir o

risco de exposi¸c˜

ao a acessos maliciosos.

2.1.4 _{Provedor de Identidade}

Provedores de identidade s˜

ao normalmente respons´

aveis pela autentica¸c˜

ao e

delega¸c˜

ao das identidades aos provedores de servi¸co. S˜

ao respons´

aveis pela manuten¸c˜

ao e

distribui¸c˜

ao de atributos para os provedores de servi¸co e a manuten¸c˜

ao de informa¸c˜

oes

atualizadas e fidedignas sobre os usu´

arios.

Um provedor de identidade pode vincular aos atributos de identidade por ele

armazenados e providos o valor de atributos de identidade fornecidos por outros provedores

de identidade. As credenciais geradas por um provedor podem conter n˜

ao s´

o atributos

deste provedor, mas tamb´

em fornecidos por outros provedores (BERTINO; TAKAHASHI,

2011).

2.1.5 _{Provedor de Servic}

_¸o

´

E o respons´

avel por prover o servi¸co aos usu´

arios ou aos agentes que

represen-tam os usu´

arios. Uma quest˜

ao importante que concerne aos provedores de servi¸co refere-se

aos n´ıveis de confian¸ca que estes tˆ

em com os provedores de identidade e `

as credenciais

recebidas destes. Em outras palavras, ´

e atrav´

es da rela¸c˜

ao entre o provedor de servi¸co e o

provedor de identidade que as informa¸c˜

oes e permiss˜

oes de acesso a dados e/ou servi¸cos

s˜

ao atribu´ıdos para cada usu´

ario (BERTINO; TAKAHASHI, 2011).

Jøsang et al (2005) tamb´

em denominam provedores de servi¸co como Relying

Parties (RP), ou Terceiras Partes Confi´

aveis. Para eles, RPs s˜

ao as entidades que utilizam

os provedores de identidade para verificar a identidade dos usu´

arios em seu processo de

autentica¸c˜

ao.

2.2 _{GERENCIAMENTO DE IDENTIDADES}

Para Stallings (2011), gerenciamento de identidades ´

e uma abordagem

centrali-zada e automaticentrali-zada para prover acesso a recursos para usu´

arios autorizados. O objetivo

do gerenciamento de identidade ´

e definir uma identidade para cada usu´

ario (humano ou

processo), associando atributos `

a identidade e refor¸cando a forma que a identidade de um

usu´

ario pode ser verificada. Outro conceito importante de um sistema de gerenciamento

de identidades ´

e o uso do Single Sign-On (SSO), que permite a um usu´

ario acessar todos

(14)

os recursos da rede depois de uma ´

unica autentica¸c˜

ao. Os elementos listados a seguir s˜

ao

considerados os principais em um sistema de gerenciamento de identidades:

• Autentica¸c˜

ao: Confirma¸c˜

ao que um usu´

ario corresponde ao nome de usu´

ario fornecido.

• Autoriza¸c˜

ao: Garantir acesso a servi¸cos ou recursos espec´ıficos baseado na

auten-tica¸c˜

ao.

• Accounting: processo do registro das atividades do acesso e da autoriza¸c˜

ao, para fins

de responsabiliza¸c˜

ao.

• Provisionamento: o registro de usu´

arios no sistema.

• Automa¸c˜

ao do fluxo de trabalho: movimento de dados em um processo do neg´

ocio.

• Administra¸c˜

ao delegada: O uso de controle de acesso baseado em pap´

eis para garantir

permiss˜

oes.

• Sincroniza¸c˜

ao de senhas: Cria¸c˜

ao de um processo para SSO ou Reduced Sign-On

(RSO). Enquanto o SSO permite ao usu´

ario acessar todos os recursos da rede ap´

os

uma ´

unica autentica¸c˜

ao, o RSO pode envolver m´

ultiplos logins, mas requer menos

esfor¸co por parte do usu´

ario do que se cada recurso e servi¸co mantivesse seu pr´

oprio

mecanismo de autentica¸c˜

ao.

• Auto-servi¸co de redefini¸c˜

ao de senha: permite ao usu´

ario modificar a pr´

opria senha.

• Federa¸c˜

ao: processo onde a autentica¸c˜

ao e a permiss˜

ao s˜

ao passadas de um sistema

para outro - geralmente entre m´

ultiplas empresas, reduzindo assim o n´

umero de

autentica¸c˜

oes necess´

arias por parte do usu´

ario.

Um sistema de gerenciamento de identidades tamb´

em pode incorporar `

as

identi-dades digitais atributos al´

em das informa¸c˜

oes de identifica¸c˜

ao e autoriza¸c˜

ao. Um servi¸co de

atributos gerencia a cria¸c˜

ao e manuten¸c˜

ao destes atributos, como por exemplo o endere¸co

residencial de um usu´

ario. O gerenciamento de identidades permite que o usu´

ario informe

este dado apenas uma vez, sendo este mantido em um ´

unico lugar e liberado aos recursos

que solicitam esta informa¸c˜

ao de acordo com a autoriza¸c˜

ao do usu´

ario e de pol´ıticas de

privacidade.

2.2.1 _{OpenID Connect}

De acordo com a documenta¸c˜

ao da ferramenta, o OpenID Connect 1.0 ´

e definido

como uma camada de identidade implementada sobre o protocolo OAuth 2.0. Ela permite

que provedores de servi¸co, na condi¸c˜

ao de clientes, verifiquem a identidade de um usu´

ario

(15)

final baseando-se na autentica¸c˜

ao executada por um servidor de autoriza¸c˜

ao, bem como

obter informa¸c˜

oes b´

asicas sobre o perfil do usu´

ario que est´

a se autenticando no sistema

de uma forma interoper´

avel utilizando o conceito de REpresentational State Transfer

(REST), tecnologia que abstrai detalhes da linguagem utilizada, focando na fun¸c˜

ao dos

componentes (OPENID CONNECT, 2016). Sua implementa¸c˜

ao ´

e dividida em m´

odulos,

cada um com uma finalidade espec´ıfica. A Figura 1 mostra como s˜

ao divididos os m´

odulos

do protocolo OpenID Connect, divididos em M´ınimo, Dinˆ

amico e Completo.

Figura 1 – Diagrama de especifica¸c˜

oes e guia de implementa¸c˜

ao (OpenID)

As especifica¸c˜

oes do m´

odulo Core do protocolo OpenID Connect 1.0 definem as

funcionalidades principais do protocolo: autentica¸c˜

ao constru´ıda sobre o protocolo OAuth

2.0 e o uso de requisi¸c˜

oes para a troca de informa¸c˜

oes sobre o usu´

ario final. Al´

em disso,

nesse m´

odulo s˜

ao descritas as considera¸c˜

oes sobre seguran¸ca e privacidade na utiliza¸c˜

ao do

protocolo OpenID Connect 1.0.

(16)

de autoriza¸c˜

ao do protocolo OAuth 2.0. O uso dessa extens˜

ao deve ser requisitado pelo

cliente, incluindo informa¸c˜

oes openid na requisi¸c˜

ao da autoriza¸c˜

ao. As informa¸c˜

oes sobre a

autentica¸c˜

ao realizada s˜

ao retornadas na forma de uma estrutura JSON Web Token (JWT)

chamada de Token ID. Servidores de autentica¸c˜

ao que implementam o protocolo OpenID

Connect s˜

ao tamb´

em chamados de OpenID Providers (OPs) ou provedores de identidade.

Clientes OAuth 2.0 utilizando OpenID Connect s˜

ao chamados de Relying Parties (RPs) ou

provedores de servi¸co.

O JSON Web Token (JWT) ´

e definido pelo RFC 7523 (2015) como um token

de seguran¸ca codificado que possibilita o compartilhamento da identidade e de informa¸c˜

oes

de seguran¸ca entre dom´ınios de seguran¸ca. Um token de seguran¸ca ´

e geralmente emitido

por um provedor de identidade e consumido por uma Relying Party (RP), que se baseia

em seu conte´

udo para identificar o sujeito do token para fins relacionados com a seguran¸ca.

O protocolo OpenID Connect segue o fluxo detalhado na Figura 2:

Figura 2 – Fluxo de autentica¸c˜

ao atrav´

es do protocolo OpenID Connect (OpenID)

1. A RP envia uma solicita¸c˜

ao de autentica¸c˜

ao para o OP;

2. O OP autentica o usu´

ario final e obt´

em informa¸c˜

oes de autoriza¸c˜

ao, de acordo com

seu consentimento;

(17)

4. A RP pode requisitar ao OP informa¸c˜

oes sobre o usu´

ario;

5. O OP retorna informa¸c˜

oes sobre o usu´

ario.

O Token ID se assemelha em conceito com uma cart˜

ao de identifica¸c˜

ao no

formato JWT. Para a obten¸c˜

ao de um Token ID o cliente deve solicitar autentica¸c˜

ao ao

OP informando o usu´

ario (CONNECT2ID, 2014). Algumas caracter´ısticas do usu´

ario

est˜

ao presentes no Token ID e s˜

ao transmitidas atrav´

es do JWT, conforme a Figura 3:

Figura 3 – Exemplo de Token ID no formato JWT (Connect2ID)

• sub - Identificador ´

unico do usu´

ario final cadastrado no provedor de identidade;

• iss - Especifica a autoridade de emiss˜

ao;

• aud - ´

E gerado para um determinado p´

ublico alvo, ou seja, o cliente;

• nonce - Pode conter um nonce;

• auth_time - Pode especificar quando o usu´

ario foi autenticado;

• acr - Pode especificar o n´ıvel de autoriza¸c˜

ao com que o usu´

ario foi autenticado;

• iat - Cont´em a data em que o JWT foi emitido;

• exp - Cont´em a data de expira¸c˜

ao do JWT;

• Pode incluir dados adicionais solicitados sobre o usu´

ario, tais como nome e endere¸co

de e-mail;

(18)

• ´

E assinado digitalmente, para que possa ser verificado pelos destinat´

arios;

• Pode ser opcionalmente criptografado para confidencialidade.

O OAuth foi concebido inicialmente como um mecanismo de autoriza¸c˜

ao para

recursos protegidos ou APIs web. Existem maneiras diferentes de um RP solicitar um

Token ID ao OP. Os fluxos para obten¸c˜

ao dos tokens s˜

ao variados e projetados para os

diversos tipos de aplicativos, como aplicativos m´

oveis, aplicativos tradicionais baseados

em servidores web, entre outros. Os fluxos utilizados no OpenID Connect para adquirir os

Tokens ID s˜

ao classificados em Authorization Code Flow, Implicit Flow e Hybrid Flow:

Authorization Code Flow - No fluxo de c´

odigo de autoriza¸c˜

ao, o OP envia um

c´

odigo ao RP, que o utiliza para receber um Token ID. ´

E adequado para clientes que

possam manter seguran¸ca entre eles e o servidor de autoriza¸c˜

ao.

Implicit Flow - Ideal para aplicativos baseados em navegador, usando

lingua-gem de script que s˜

ao executados diretamente pelo navegador. O Token ID ´

e recebido

diretamente com o redirecionamento do provedor.

Hybrid Flow - raramente utilizado, permite que os aplicativos executados

diretamente pelo navegador (scripts) ou que s˜

ao executadas por aplicativos web tradicionais

e aplicativos para dispositivos m´

oveis recebam os Tokens separadamente um do outro.

Essencialmente uma combina¸c˜

ao dos fluxos anteriores.

2.2.1.1 CLAIMS

Uma claim (ou reivindica¸c˜

ao) ´

e uma afirma¸c˜

ao de que um sujeito, pessoa

ou organiza¸c˜

ao, faz sobre si mesmo ou sobre outro assunto. Por exemplo, a declara¸c˜

ao

pode ser sobre um nome, grupo, preferˆ

encia de compra, etnia, privil´

egio, associa¸c˜

ao ou

capacidade. O sujeito que faz a reivindica¸c˜

ao ou reivindica¸c˜

oes ´

e o provedor.

As especifica¸c˜

oes do OpenID Connect definem um pequeno conjunto de claims

como padr˜

ao. Outras claims podem ser usadas em conjunto com as reivindica¸c˜

oes padr˜

ao.

Ao usar tais claims, ´

e recomendado que os nomes utilizados sejam resistentes a colis˜

ao

(OPENID CONNECT, 2016).

2.3 _POL´

_{ITICAS DE PRIVACIDADE}

De acordo com Caramujo e Silva (2015), pol´ıticas de privacidade representam

os termos que um usu´

ario precisa aceitar para utilizar os servi¸cos providos por uma

orga-niza¸c˜

ao. ´

E definido por um conjunto de atributos e composto por um ou mais elementos

chamados Statements, que s˜

ao as afirma¸c˜

oes que detalham as escolhas do usu´

ario sobre

o destino e tratamento dos dados. Este documento deve identificar quais os tipos de

informa¸c˜

oes dos usu´

arios ser˜

ao gerenciadas e podem ser expostas.

(19)

Os Statements, segundo Caramujo e Silva (2015) e Basso et. al. (2015), s˜

ao os

elementos centrais da pol´ıtica de privacidade, pois descrevem as regras e a¸c˜

oes especificadas

na pol´ıtica e podem ser divididos em 4 elementos especializados:

Collection, que define qual informa¸c˜

ao pessoal ser´

a coletada pelo provedor de

servi¸co;

Disclosure, que trata sobre a divulga¸c˜

ao dos dados e o destino dessa divulga¸c˜

ao;

Retention, que identifica o tempo que a informa¸c˜

ao ser´

a mantida;

Usage, que especifica como os dados privados ser˜

ao utilizados;

O trabalho de Caramujo e Silva (2015), ainda apresenta o conceito de

Informa-tive, que descreve statements gen´

ericos e informativos.

Villarreal et. al. (2017) estabelecem as regras de pol´ıtica de privacidade,

definindo inicialmente tuplas contendo os itens: Tipo de Dados (dT), prop´

osito de uso

para o dado (pR), tempo em horas de conserva¸c˜

ao dos dados (tM), o contexto da utiliza¸c˜

ao

dos atributos (cN), informa¸c˜

ao sobre a notifica¸c˜

ao do usu´

ario quanto ao uso do dado (nT),

informa¸c˜

ao sobre criptografia dos dados (cP). Esta tupla ´

e montada tendo como destino

um Provedor de Servi¸co espec´ıfico. Para tanto, apresenta-se da seguinte forma:

SP.Regra = [dT, pR, tM, cN.nT, cP ]

onde:

• dT - tipo de dados (nome, CPF, endere¸co)

• pR - prop´

osito (melhoria de servi¸co, cient´ıfico, comercial, governamental)

• tM - tempo de conserva¸c˜

ao dos dados

• cN - contexto (Financeiro, Compras online, Sa´

ude, Militar)

• nT - notifica¸c˜

ao (1 para notificar, 0 para n˜

ao)

• cP - criptografia(1 para cifrar, 0 para n˜

ao)

Exemplo 1:

Loja1.Regra = [nome, cpf ; pagamento; 48; compras; 1; 1]

No exemplo 1, os tipos de dados (nome e CPF) devem ser utilizados apenas

para fins de pagamento, pela Loja1 (Prestador do Servi¸co), mantendo esses dados por 48

(20)

horas, sendo utilizados apenas para compras online, notificando o usu´

ario quanto ao uso e

transmitindo-os de forma cifrada.

Para uma melhor apresenta¸c˜

ao e padroniza¸c˜

ao, VILLARREAL et. al. (2017)

definem categorias e valores padr˜

ao para cada uma delas. Al´

em disso, estende a estrutura,

para o refinamento das preferˆ

encias pessoais dos usu´

arios, adicionando benefici´

arios.

Tipo de Dados s˜

ao divididos em:

• Informa¸c˜

ao Pessoal (PI)

• Preferˆencias e Caracter´ısticas Pessoais (PCP)

• Localiza¸c˜

ao (LO)

• Atividades e H´

abitos (AH)

• Rela¸c˜

oes (RS)

Os prop´

ositos de uso s˜

ao divididos em:

• Melhoria de Servi¸co (SI)

• Cient´ıfico (SC)

• Comercial (CO)

Os benefici´

arios s˜

ao divididos em:

• PII Principal (PP)

• Provedor de Servi¸co (SP)

• Terceira Parte (TP)

Contexto, dividido em:

• Financeiro (FI)

• Compras Online (CO)

• Sa´

ude (SA)

• Militar (MI)

Dissemina¸c˜

ao de dados: 0 ou 1

Criptografia: 0 ou 1

(21)

2.3.1 _{Sticky Policies}

As Sticky Policies, em seu contexto original, s˜

ao as pol´ıticas de privacidade que

s˜

ao compartilhadas, quando estas s˜

ao anexadas juntamente com os dados e que descrevem

como estes devem ser tratados. Ou seja, s˜

ao as restri¸c˜

oes ou condi¸c˜

oes que definem a

autoriza¸c˜

ao dos usu´

arios quanto `

a utiliza¸c˜

ao destes dados (PEARSON, MONT, 2011).

Em Privacy Patterns (2017), tem-se que as Sticky Policies permitem a

pro-paga¸c˜

ao das pol´ıticas entre organiza¸c˜

oes de confian¸ca, mantendo a correta aplica¸c˜

ao das

mesmas, al´

em de prover rastreabilidade. Por outro lado, Privacy Patterns (2017) declara

como problem´

atico o aumento no tamanho dos dados e como principal obst´

aculo para a

implementa¸c˜

ao, a dificuldade na atualiza¸c˜

ao das pol´ıticas.

A 4, mostra a propaga¸c˜

ao de pol´ıticas, juntamente com os dados, configurando

o conceito de Sticky Policy (TANG, 2008).

Figura 4 – Representa¸c˜

ao de esquema de Sticky Policy

2.4 _{FERRAMENTAS DE DESENVOLVIMENTO}

Neste se¸c˜

ao ser˜

ao apresentadas informa¸c˜

oes e caracter´ısticas sobre as

ferramen-tas e tecnologias utilizadas durante a etapa de desenvolvimento do projeto.

2.4.1 _JavaScript

De acordo com Flanagan (2006), JavaScript ´

e uma linguagem de programa¸c˜

ao

interpretada com capacidade de orienta¸c˜

ao `

a objetos. O n´

ucleo da linguagem JavaScript

se assemelha a C, C++ e Java, com arquiteturas de programa¸c˜

ao como as declara¸c˜

oes

de if, while e operadores como o &&. Contudo, a similaridade se limita `

a sintaxe.

(22)

Ja-vaScript ´

e uma linguagem de tipagem fraca, ou seja, suas vari´

aveis n˜

ao precisam de um

tipo declarado. Objetos em JavaScript mapeiam o nome das propriedades para valores

propriet´

arios arbitr´

arios. Dessa forma, esses objetos se assemelham mais a tabelas hash ou

arrays associativos do que structs, como ´

e o caso da linguagem C, ou objetos, como em

C++ ou Java. O mecanismo de heran¸ca de orienta¸c˜

ao a objetos do JavaScript ´

e baseado

em um modelo de prot´

otipo. Esse modelo ´

e bastante diferente da heran¸ca em C++ ou

Java. Assim como a linguagem Perl, o JavaScript ´

e interpretado e se assemelha bastante `

a

essa linguagem em diversas ´

areas, como o tratamento de express˜

oes regulares e manuseio

de arrays. O n´

ucleo do JavaScript suporta n´

umeros, strings e valores booleanos como

tipos primitivos de dados, al´

em do suporte para arrays, datas, e objetos de express˜

ao

regular.

O JavaScript ´

e mais comumente utilizado em navegadores, e nesse contexto,

seu n´

ucleo ´

e estendido com objetos que permitem `

a scripts interagirem com o usu´

ario,

controlar o navegador e alterar o conte´

udo do documento exibido na janela do navegador.

2.4.1.1 Node.js

De acordo com Dayley (2014), Node.js ´

e uma plataforma de desenvolvimento

baseada no mecanismo Google V8 JavaScript. O c´

odigo Node.js ´

e escrito em JavaScript

e ent˜

ao o mecanismo V8 o compila em linguagem de m´

aquina para ser executado. A

maioria - se n˜

ao todo - o c´

odigo de um servi¸co pode ser escrita em Node.js, desde o servidor

web, scripts do lado do servidor e qualquer funcionalidade de aplica¸c˜

ao web. Uma das

caracter´ısticas do Node.js ´

e a grande integra¸c˜

ao entre aplica¸c˜

oes web e scripts, devido ao

fato de estes serem executados no mesmo ambiente.

Algumas caracter´ısticas da plataforma Node.js:

• JavaScript de ponta a ponta: uma das maiores vantagens do Node.js ´e a

possibilidade de escrever scripts tanto para o servidor quanto para o cliente em

JavaScript. Isso elimina a dificuldade de alocar parte da l´

ogica de um sistema no

cliente e parte no servidor, considerando que os scripts do cliente s˜

ao totalmente

compat´ıveis com o servidor, j´

a que ambos utilizam a mesma linguagem.

• Escalabilidade orientada em eventos: O Node.js aplica uma l´

ogica ´

unica no

tratamento de requisi¸c˜

oes. Ao inv´

es de ter m´

ultiplas threads aguardando por

re-quisi¸c˜

oes web, o Node.js processa todas as requisi¸c˜

oes na mesma thread, usando um

modelo de eventos b´

asicos. Isso permite que webservers Node.js sejam ampliados de

forma que modelos tradicionais de webserver n˜

ao conseguem.

(23)

• Extensibilidade: O Node.js possui uma grande e ativa comunidade de

desenvolvi-mento, contando com novos m´

odulos que permitem estender suas funcionalidades

com frequˆ

encia. Tamb´

em ´

e de f´

acil instala¸c˜

ao e inclus˜

ao de m´

odulos, passos que

podem ser feitos rapidamente.

• R´

apida implementa¸

c˜

ao: Configurar e iniciar o desenvolvimento em Node.js s˜

ao

atividades simples, como ter um servidor web pronto para desenvolvimento de forma

instantˆ

anea.

2.4.2 _NoSQL

NoSQL ´

e um modelo de banco de dados n˜

ao relacional de alto desempenho.

Um banco de dados NoSQL utiliza diversos modelos de dados, como documentos, gr´

aficos,

e elementos chave-valor colunares e tem grande reconhecimento pela facilidade de

desenvol-vimento, desempenho escal´

avel, alta disponibilidade e resiliˆ

encia. Geralmente um banco

de dados NoSQL n˜

ao faz a utiliza¸c˜

ao de um schema, tendo seus dados armazenados de

forma semiestruturada, em modelos JSON, XML ou similares que fa¸cam a rela¸c˜

ao entre

atributo e valor (Amazon AWS, 2017).

2.4.2.1 _MongoDB

Segundo Dayley (2014), o MongoDB ´

e um sistema ´

agil e altamente escal´

avel

de base de dados NoSQL. Seu nome ´

e derivado de “humongous”, (humilde), enfatizando

a escalabilidade e performance que este provˆ

e. O MongoDB provˆ

e um grande backend

de armazenamento para sites com alto tr´

afego e que precisam armazenar dados como

coment´

arios de usu´

arios, blogs ou outros itens, devido ao fato de ser rapidamente escal´

avel

e f´

acil de implementar.

Algumas caracter´ısticas do MongoDB, que garantem boa combina¸c˜

ao com

Node.js:

• Orientado a documentos: Como o MongoDB ´e orientado `

a documentos, os dados

s˜

ao armazenados na base de dados em um formato muito pr´

oximo do que ´

e utilizado

tanto nos scripts do cliente quando do servidor. Isso elimina a necessidade de

transferir os dados de linhas para objetos e vice-versa.

• Alta performance: MongoDB ´e uma das bases de dados com mais alta performance

dispon´ıveis atualmente, e se destaca no cen´

ario atual, onde h´

a cada vez mais intera¸c˜

ao

com sites e tr´

afego de dados pesado.

(24)

• Alta disponibilidade: Seu modelo de dados torna f´

acil manter a escalabilidade

enquanto mant´

em a alta performance.

• Alta escalabilidade: Sua estrutura simplifica a atividade escalar horizontalmente

o servi¸co, fragmentando os dados entre v´

arios servidores.

• Sem risco de inje¸

c˜

ao SQL: Devido ao fato de os objetos serem armazenados como

documentos ao inv´

es de utilizar strings SQL, n˜

ao h´

a risco de haver inje¸c˜

oes SQL na

aplica¸c˜

ao.

(25)

3 Proposta: Pol´ıticas de

Privaci-dade no OpenID Connect

O avan¸co de tecnologias de redes de computadores resultou em um crescimento

na disponibilidade de aplica¸c˜

oes e servi¸cos remotos. Como decorrˆ

encia, administradores

de sistemas necessitam uma base de usu´

arios pr´

opria, disponibilizando acesso aos servi¸cos

atrav´

es de informa¸c˜

oes e n´ıveis de privil´

egio (MOREIRA et al., 2011).

De acordo com Stallings (2011), o gerenciamento de identidades usa padr˜

oes

que s˜

ao essenciais para uma troca segura de identidades atrav´

es de diferentes dom´ınios e

sistemas heterogˆ

eneos. Um dos desafios do gerenciamento de identidades ´

e garantir aos

usu´

arios que os dados providos por eles a um servi¸co ser˜

ao corretamente tratados pelo

servi¸co e pelas outras partes.

Para que isso ocorra, utilizaremos o conceito de pol´ıticas de privacidade e as

defini¸c˜

oes que dela decorram para determinar padr˜

oes a servi¸cos a fim de prover um servi¸co

seguro.

A cria¸c˜

ao das pol´ıticas de privacidade ´

e poss´ıvel atrav´

es da combina¸c˜

ao de

todos os tipos de dados, todos os prop´

ositos de uso, todos os benefici´

arios e todos os

contextos descritos anteriormente. Assim s˜

ao definidas as permiss˜

oes para a utiliza¸c˜

ao do

dado em quest˜

ao. Utilizando o exemplo descrito anteriormente:

Loja1.Regra = [nome, cpf ; pagamento; 48; compras; 1; 1]

Temos que:

Figura 5 – Modelo de combina¸c˜

oes de pol´ıticas de privacidade do usu´

ario

(26)

prop´

osito da utiliza¸c˜

ao deste dado ´

e Comercial (CO), o benefici´

ario ´

e a Loja1 (TP), o

contexto ´

e Compras Online (CO). O valor dessa combina¸c˜

ao ´

e 1, pela escolha de autorizar

a utiliza¸c˜

ao pelo usu´

ario. Se esse ´

e o ´

unico objeto de que trata a pol´ıtica, todas as outras

combina¸c˜

oes poss´ıveis ficariam com o valor 0. Os valores de Dissemina¸c˜

ao e Criptografia

ter˜

ao valores ´

unicos (1) para todas as combina¸c˜

oes das pol´ıticas, pois sua aplica¸c˜

ao n˜

ao

est´

a no escopo deste trabalho.

A proposta deste trabalho trata da utiliza¸c˜

ao da organiza¸c˜

ao descrita

anterior-mente para cria¸c˜

ao de pol´ıticas de privacidade, permitindo ao usu´

ario definir a utiliza¸c˜

ao

dos seus dados para diversos contextos diferentes. Ap´

os isso, utilizar do conceito de

Sticky Policies para envio destas mesmas pol´ıticas de um provedor de identidades OpenID

Connect a um provedor de servi¸co, atrav´

es da adi¸c˜

ao de claims contendo as pol´ıticas

definidas pelo usu´

ario.

3.1 _Problema

As informa¸c˜

oes sobre a autentica¸c˜

ao realizada utilizando o protocolo OpenID

Connect s˜

ao enviadas pelo OpenID Provider, na forma de uma estrutura JSON Web Token

(JWT) chamada de Token ID. Este token carrega informa¸c˜

oes da identidade e de seguran¸ca,

mas n˜

ao cont´

em dados sobre as pol´ıticas de privacidade escolhidas pelo usu´

ario.

3.2 _{Modelo Inicial}

A proposta inicial deste trabalho compreende os seguintes pontos:

• Cria¸c˜

ao de um perfil de usu´

ario e suas pol´ıticas de privacidade, compreendendo

todos os tipos de dados, prop´

ositos, contextos de uso, benefici´

arios, defini¸c˜

ao sobre a

dissemina¸c˜

ao e criptografia dos dados;

• Defini¸c˜

ao e cria¸c˜

ao da estrutura para envio das pol´ıticas de privacidade do usu´

ario

definidas previamente para os provedores de servi¸co, juntamente com os dados de

identifica¸c˜

ao;

• Implementa¸c˜

ao dessa estrutura em um provedor de dados baseado no protocolo

OpenID Connect, permitindo o envio das pol´ıticas com o Token ID;

• Implementa¸c˜

ao de modifica¸c˜

oes em um modelo de cliente baseado em OpenID

Connect, permitindo que este receba um token contendo, al´

em das informa¸c˜

oes da

estrutura original, as pol´ıticas de privacidade definidas pelo usu´

ario.

(27)

3.3 _{Desenvolvimento}

A modalidade da pesquisa ´

e experimental, pois atrav´

es de altera¸c˜

oes de c´

odigo

e execu¸c˜

oes do sistema, pretende-se realizar altera¸c˜

oes em uma implementa¸c˜

ao existente

do provedor de identidades OpenID Connect para o envio de pol´ıticas de privacidade

juntamente com o Token ID e altera¸c˜

oes em uma implementa¸c˜

ao existente de cliente

OpenID Connect para o recebimento e exibi¸c˜

ao das mesmas pol´ıticas.

3.4 _{Recursos de Software}

Foram utilizadas como base para o provedor de identidades e do cliente OpenID

Connect as implementa¸c˜

oes de Skokan (2017) em Node.js. O provedor de identidades

OpenID Connect implementado ´

e certificado como um provedor de identidades oficial

OpenID desde 02 de Janeiro de 2017. O cliente tamb´

em ´

e certificado como Relying Party

pelo OpenID CERTIFICATION (2017) desde 15 de Dezembro de 2016.

O provedor de identidades fornece uma implementa¸c˜

ao das especifica¸c˜

oes do

OpenID, sem determinar o modelo de persistˆ

encia a ser utilizado. Oferece, no entanto,

uma implementa¸c˜

ao de praticamente todo o modelo em um modelo de banco de dados

de mem´

oria que ´

e instanciado com a execu¸c˜

ao do provedor, guardando usu´

arios, tokens,

clientes cadastrados, chaves criptogr´

aficas, c´

odigos de autoriza¸c˜

ao (para o fluxo de c´

odigo

de autoriza¸c˜

ao) e informa¸c˜

oes de sess˜

ao.

Para a implementa¸c˜

ao da persistˆ

encia destes itens, foi utilizado o MongoDB

(MONGODB, 2017), sistema ´

agil e altamente escal´

avel de base de dados NoSQL. Apenas

os usu´

arios continuaram sendo persistidos em mem´

oria, atrav´

es da classe account.js.

Como ferramentas de apoio ao desenvolvimento em Node.js, foram utilizados

o IntelliJ IDEA (JETBRAINS, 2017), IDE para v´

arias linguagens de programa¸c˜

ao e o

Sublime Text 3 (SUBLIME TEXT, 2017), editor de texto com diversos recursos de grande

utilidade para o desenvolvimento.

No ˆ

ambito do Node.js, foram utilizadas bibliotecas diversas para a execu¸c˜

ao

das implementa¸c˜

oes e o desenvolvimento, como os frameworks express e koa.

Como mecanismo das telas apresentadas, foi utilizado o EJS, linguagem de

modelos client-side JavaScript, que faz a produ¸c˜

ao do HTML.

(28)

Figura 6 – Tecnologias utilizadas no desenvolvimento do trabalho

3.4.1 _{Servidor MongoDB}

Para suporte `

a persistˆ

encia de dados do trabalho foi utilizado o software

Mon-goDB Server em sua vers˜

ao 3.4.4 para sistema operacional Microsoft

Windows

R

de

R

64 bits, executado diretamente no sistema local. Tamb´

em foi utilizado para apoio ao

desenvolvimento e consultas de testes o cliente de linha de comando do pr´

oprio pacote

MongoDB que acompanha os arquivos do servidor.

Foram criadas na base mydb, utilizada para o desenvolvimento, as collections

access token, authorization code, client, client credentials, refresh token, registration access token

e session para a persistˆ

encia destes objetos, necess´

arios `

a execu¸c˜

ao do cliente e do provedor

de identidades.

3.4.2 _{Cliente OpenID Connect}

Como citado na se¸c˜

ao 3.4 - Recursos de Software, o cliente OpenID Connect

utilizado foi desenvolvido em Node.js por Skokan (2017) e dispon´ıvel em seu reposit´

orio

no GitHub.

(29)

a defini¸c˜

ao da porta que o sistema passa a escutar (linha 7). Al´

em disso, ´

e definido o

endere¸co do Issuer, emissor das identidades que ser˜

ao utilizadas pelo cliente. No escopo do

desenvolvimento deste trabalho, temos o Issuer como o Provedor de Identidade OpenID

Connect. Na linha 6 ´

e realizada esta defini¸c˜

ao, alocando no mesmo servidor (localhost) a

porta 3100 para o provedor de identidades OpenID Estas modifica¸c˜

oes s˜

ao feitas na classe

node-openid-client\example\index.js.

Figura 7 – Defini¸c˜

ao de endere¸co do OP e porta (Fonte: os autores)

Na classe node-openid-client\example\app.js, ´

e definida a requisi¸c˜

ao de

au-toriza¸c˜

ao que ser´

a enviada ao provedor de identidades. Esta requisi¸c˜

ao est´

a descrita

na Figura 2, como o passo (1). Nela, s˜

ao adicionadas as reivindica¸c˜

oes ou Claims que

ser˜

ao tratadas pelo cliente quando este receber a resposta ou Token ID, o endere¸co de

redirecionamento (para onde o sistema ser´

a redirecionado ap´

os a resposta do provedor de

identidades), o estado, o nonce e demais parˆ

ametros de sess˜

ao necess´

arios para a requisi¸c˜

ao.

A composi¸c˜

ao da requisi¸c˜

ao ´

e definida na Figura 8, entre as linhas 158 e 167. Uma das

adapta¸c˜

oes desenvolvidas neste trabalho consiste na adi¸c˜

ao de um objeto Claim “pol´ıticas”,

visto na linha 161, como um dos Claims constantes nas informa¸c˜

oes de usu´

ario (UserInfo).

(30)

Figura 8 – Adi¸c˜

ao das reivindica¸c˜

oes suportadas pelo cliente (Fonte: os autores)

Retratada na Figura 9 a classe node-openid-client\lib\client.js, est´

a o trecho

de c´

odigo que define o passo (4) da Figura 2. Nesta etapa ´

e montada a requisi¸c˜

ao para

UserInfo ou informa¸c˜

oes sobre o usu´

ario. Uma das atividades no desenvolvimento deste

trabalho foi a adi¸c˜

ao de c´

odigo para incluir na requisi¸c˜

ao a claim de pol´ıticas, necess´

arias

para que o cliente solicite ao provedor de identidades OpenID informa¸c˜

oes sobre este

campo.

(31)

Figura 9 – Informa¸c˜

oes que ser˜

ao utilizadas na requisi¸c˜

ao (Fonte: os autores)

3.4.3 _{Provedor de Identidades OpenID Connect}

No processo de implanta¸c˜

ao do provedor de identidades deve-se definir uma

vari´

avel de ambiente com nome MONGODB URI e endere¸co do servidor MongoDB. A

Figura 10 descreve o endere¸co definido no IntelliJ IDE para o MongoDB.

Figura 10 – Defini¸c˜

ao de Vari´

avel de Caminho na IDE InteliJ (Os autores)

(32)

que trata da existˆ

encia da vari´

avel de ambiente e implementa a utiliza¸c˜

ao do MongoDB

como adaptador de persistˆ

encia, caso resultado positivo da an´

alise condicional (linhas 20

a 23, classe index.js). Tamb´

em na Figura 11, nas linhas 13 e 18 da classe index.js, s˜

ao

definidos o endere¸co e porta utilizadas pelo issuer ou emissor de identidades, ou seja, o

endere¸co do pr´

oprio provedor de identidades OpenID Connect.

Figura 11 – Defini¸c˜

oes para utiliza¸c˜

ao do banco de dados MongDB (Fonte: os autores)

Na Figura 12 ´

e apresentada a configura¸c˜

ao do framework express.js realizada na

classe node-oidc-provider-master\example\express.js, que fornece um conjunto de recursos

para aplicativos web, recorrente no c´

odigo de Skokan, necess´

ario para o bom funcionamento

do provedor de identidades desenvolvido. Assim como no cliente, neste ponto ´

e feita a

declara¸c˜

ao do servidor e porta em que o provedor ser´

a executado. Al´

em disso, ´

e na classe

express ´

e instanciado o objeto referente ao provedor, utilizando deste ponto em diante

as rotas definidas pelo Node.js para a execu¸c˜

ao do mesmo, ou seja, para qual p´

agina o

usu´

ario ser´

a direcionado dependendo da a¸c˜

ao tomada.

(33)

Figura 12 – Defini¸c˜

oes de configura¸c˜

ao do provedor de identidades (Fonte: os autores)

Conforme exposto na Figura 13, a linha 30 da classe

node-oidc-provider-master\lib\helpers\defaults.js define o nome dos Claims ou reivindica¸c˜

oes habilitadas

no provedor de identidades OpenID e que este pode fornecer aos seus clientes. Como

desenvolvimento das modifica¸c˜

oes propostas neste trabalho, est´

a a adi¸c˜

ao do objeto

pol´ıticas a esta linha, permitindo aos clientes que as solicitem `

a este provedor e tornando

o provedor apto a entreg´

a-las.

Figura 13 – (Claims habilitadas no provedor de identidades (Fonte: os autores)

Os escopos no OAuth 2.0 definem privil´

egios de acesso requisitados pela

aplica¸c˜

ao cliente e autorizados pelo usu´

ario final no provedor de autoriza¸c˜

ao. O OpenID

Connect usa escopos para definir quais claims o cliente est´

a requisitando e que est˜

ao

sujeitos `

a autoriza¸c˜

ao e consentimento pelo usu´

ario no OpenID Provider (RFC6749, 2012).

Os endpoints de recursos protegidos podem executar a¸c˜

oes diferentes e retornar

informa¸c˜

oes diferentes com base nos valores de escopo e outros parˆ

ametros usados ao

solicitar o Token de acesso apresentado.

Os valores de escopo definidos para o provedor de identidades s˜

ao definidos na

classe node-oidc-provider-master\example\settings.js, conforme demonstrado na Figura 14.

(34)

Entre as linhas 18 e 25 s˜

ao definidos os valores para os Claims, incluindo neste intervalo o

claim de pol´ıticas.

Figura 14 – Valores do escopo para o provedor de identidades (Fonte: os autores)

O provedor de identidades OpenID deve de alguma maneira persistir as contas

de usu´

arios cadastrados para uso posterior. Esta conta deve ter uma propriedade accountId,

bem como a fun¸c˜

ao claims(), para retornar um objeto com reivindica¸c˜

oes que correspondem

`

as reivindica¸c˜

oes que ele suporta.

As contas de usu´

arios podem estar salvas em um banco de dados ou em classes

com as informa¸c˜

oes em mem´

oria. Para o desenvolvimento deste trabalho, foi utilizada

uma classe account.js, conforme Figura 15, para definir as informa¸c˜

oes do usu´

ario de

teste. Nele, foram registradas as informa¸c˜

oes pessoais do usu´

ario, bem como as pol´ıticas

hipoteticamente definidas por ele.

(35)

Na imagem 15, na linha 30 da classe node-oidc-provider-master\example\account.js

temos uma supress˜

ao de pol´ıticas para uma melhor apresenta¸c˜

ao na imagem. Todas as

combina¸c˜

oes poss´ıveis de tipos de dados, todos os prop´

ositos de uso, todos os benefici´

arios e

todos os contextos descritos anteriormente na proposta deste trabalho devem estar descritas

nas pol´ıticas, resultando em 180 pol´ıticas, al´

em das pol´ıticas adicionais de dissemina¸c˜

ao

de dados e criptografia.

Da forma que foi desenvolvida a extens˜

ao no provedor, basta que neste ponto

sejam alteradas, adicionadas ou removidas pol´ıticas de privacidades, para que estas sejam

enviadas de forma correta para um cliente que receba a claim “pol´ıticas” e trate-a como

determinado e desejado.

(36)

(37)

4 Resultados Experimentais

Na Figura 16, ´

e apresentada a tela de setup ou configura¸c˜

ao de um novo cliente.

Neste ponto ´

e definido qual fluxo ser´

a utilizado para a comunica¸c˜

ao entre o cliente e o

provedor de identidades OpenID Connect, al´

em das trocas de tokens entre eles.

As altera¸c˜

oes implementadas por este trabalho permitem a utiliza¸c˜

ao de

qual-quer um dos fluxos determinados pelo protocolo OpenID Connect, com o correto

funciona-mento do envio das pol´ıticas para todos eles.

Figura 16 – Configura¸c˜

ao de um novo cliente (Tela apresentada no cliente) (Fonte: os

autores)

Ap´

os a cria¸c˜

ao e configura¸c˜

ao do novo cliente, ´

e apresentada uma tela de

descri¸c˜

ao do emissor definido no novo cliente, com informa¸c˜

oes sobre o fluxo a ser utilizado,

os m´

etodos de autentica¸c˜

ao, o endere¸co do endpoint de autoriza¸c˜

ao, das Claims suportadas

pelo novo cliente e informa¸c˜

oes sobre criptografia. Esta tela, apresentada na Figura 17

serve como um registro das informa¸c˜

oes escolhidas na configura¸c˜

ao do novo cliente.

(38)

Figura 17 – Registro do emissor definido para o novo cliente (Tela apresentada no cliente)

(Fonte: os autores)

Quando o usu´

ario de um cliente registrado no provedor tenta fazer seu login, ´

e

apresentada a tela de login, conforme Figura 18. Al´

em de formul´

ario para a submiss˜

ao de

login e senha, s˜

ao novamente apresentadas informa¸c˜

oes sobre a comunica¸c˜

ao entre provedor

e cliente.

(39)

n˜

ao faz nenhum tipo de verifica¸c˜

ao de conta v´

alida para o mesmo. Quaisquer valores

adicionados a ele ser˜

ao remetidos `

a conta de usu´

ario criada em account.js. A verifica¸c˜

ao de

usu´

ario e senha para posterior v´ınculo com contas reais em um banco de dados ´

e definida

como um trabalho futuro e n˜

ao cabe ao escopo deste trabalho.

Figura 18 – Tela de login de usu´

ario (Tela apresentada no cliente) (Fonte: os autores)

Se o usu´

ario j´

a efetuou o login no provedor de identidades, este fica vigente at´

e

que seja feito um logout pelo mesmo. At´

e l´

a, quaisquer logins deste usu´

ario em clientes

registrados no mesmo provedor o levar˜

ao at´

e a tela de autoriza¸c˜

ao do provedor, utilizando

a conta autenticada previamente.

Na Figura 19 foi criado um segundo cliente para logar com o mesmo usu´

ario,

sendo novamente direcionado `

a classe account.js, referenciando assim `

a mesma conta em

dois clientes distintos.