Universidade Federal do Rio Grande do NorteInstituto Metrópole Digital

SmartMetropolis – Plataforma e Aplicações para Cidades Inteligentes

WP4 – Infraestrutura

Relatório de Controle de Acesso

Natal-RN, BrasilAbril 2017

Equipe TécnicaDocentes

Prof. Dr. Carlos Eduardo da Silva (Coordenador) – IMD/UFRN

DiscentesGabriela Cavalcante da Silva

Sumário1 Introdução 5

2 Autenticação 52.1 SimpleSamlPHP como IdP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Instalação e configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Criando IdP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3 Configurando IdP metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.4 Criando self signed certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Keystone Federado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.1 Keystone executando no Apache . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.2 Configure o Apache para usar um método de autenticação federado . . . . . . . 102.2.3 Configure Federação no Keystone . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.4 Demonstração de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Autorização 163.1 Demonstração de autorização com o Fiware . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.1 Configurando papéis e permissões no Keyrock . . . . . . . . . . . . . . . . . . 173.2 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Considerações Finais 20

Lista de Figuras1 Entity ID do IdP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Página de autenticação do IdP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Resposta do IdP após autenticação bem sucedida . . . . . . . . . . . . . . . . . . . . . 154 Arquitetura da aplicação com o PEP Proxy e o PDP . . . . . . . . . . . . . . . . . . . . 165 Criando papel developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Criando nova permissão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Associando papel e permissão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5

1 Introdução

O projeto Smart Metropolis, conduzido pelo Instituto Metrópole Digital (IMD) da Universidade Federaldo Rio Grande do Norte (UFRN), tem como objetivo o desenvolvimento de soluções de tecnologia dainformação e comunicação para Cidades Inteligentes e Humanas.

O projeto é organizado em seis Pacotes de Trabalho (Work Packages - WP) temáticos, liderados cadapor um coordenador. Cada WP possui um conjunto de objetivos a serem alcançados ao longo dos cincoanos de execução do projeto.

Este relatório está inserido no contexto do WP 4 - Infraestrutura Computacional, que no contexto dosegundo ano de execução do projeto Smart Metropolis, tem os seguintes objetivos principais:

• Operação de Infraestrutura: Este objetivo engloba a operação e manutenção da instância Fiwaredo projeto, incluindo ferramentas para monitoramento da infraestrutura, e para gerenciamento deaplicações.

• Segurança da Informação e Controle de Acesso: Este objetivo engloba o estudo aprofundado dosmecanismos de segurança da plataforma Fiware com o fim de oferecer uma solução de controle deacesso que possa ser utilizada pelas aplicações que irão executar sobre a infraestrutura Fiware.

Neste contexto, este relatório corresponde ao entregável definido pela Meta 1.9: Estudo sobre osconceitos, ferramentas e bibliotecas relacionados a controle de acesso (autenticação e autorização).Como resultado desse estudo, apresentamos a implementação de um Provedor de Serviço (SP) Keystonecom Federação (juntamente com a configuração de um Provedor de Identidade (IdP) SimpleSamlPHP), ea criação de papeis, permissões e usuários no Keyrock, para permitir a autorização, junto ao AuthZForce,de um usuário a um serviço requisitado.

2 Autenticação

Como apresentado em relatórios anteriores, autenticação é o ato de verificar a identidade de uma entidadeou sujeito. A autenticação permite confirmar que um determinado sujeito ou entidade é quem ele afirmaser. Ao utilizar o termo entidade, permitimos que não somente humanos possam ser autenticados, mastambém entidades genéricas, como um sistema ou um equipamento.

Tendo em vista a necessidade de se definir uma solução de autenticação para ser utilizada no SGEOL,e para outras aplicações que por ventura venham a ser desenvolvidas sobre a plataforma Fiware, foi feitoum estudo aprofundado em soluções de autenticação baseado nas tecnologias utilizadas pela Comuni-dade Acadêmica Federada (CAFe) da RNP, que permite que usuários possam utilizar suas credenciaisde acesso de sua instituição de origem para acessarem diversos serviços. É importante mencionar queem relatórios anteriores demonstraram a utilização do protocolo OAuth para autenticação, e que nesterelatório estamos focados no protocolo SAML por ser o protocolo utilizado pela CAFe.

Tal estudo se baseou em interações com os membros da equipe de desenvolvimento do Keyrock, e fo-cou na integração de mecanismos de autenticação com o OpenStack Keystone, componente de segurançada plataforma OpenStack que atua como base para o Fiware Keyrock.

Nessa seção, apresentaremos os passos necessários para a criação de um provedor de um Provedor deIdentidade (Identity Provider - IdP) baseado no SimpleSamlPHP1 (Seção 2.1), e em uso para autenti-

1https://simplesamlphp.org

6

car usuários que acessam um OpenStack Keystone (Seção 2.2). Finalizamos esta seção com uma brevediscussão sobre os experimentos realizados (Seção 2.3).

2.1 SimpleSamlPHP como IdP

Para integrar o OpenStack Keystone com uma federação de identidade foi utilizado o SimpleSamlPHP,uma ferramenta escrita em PHP que lida com questões relacionadas a autenticação. O funcionamentobásico de uma autenticação em federação foi apresentado no relatório do WP5 - Middleware do SegundoTrimestre [1]. A seguir, descreveremos como configurar e implementar o IdP com o SimpleSamlPHP. Osprocedimentos a seguir foram realizados utilizando um Linux Ubuntu 16.04

2.1.1 Instalação e configuração

Aconselhamos que antes de começar com a instalação, tenha certeza que tudo está atualizado.

$ sudo apt-get update

$ sudo apt-get upgrade

Como a versão do Sistema Operacional utilizado nos nossos experimentos foi Ubuntu 16.04, tivemosque utilizar a versão 7 do php.

$ sudo apt-get install php7.0

Alguns pacotes são pré-requisitos para o funcionamento do SimpleSamlPHP, e precisam ser instala-dos:

$ sudo apt-get install apache2

$ sudo apt-get install php-xml

$ sudo apt-get install php5-sqlite

$ sudo apt-get install php5-curl

$ sudo apt install zip unzip php7.0-zip

$ sudo apt-get install libapache2-mod-php

Baixe o repositório do SimpleSamlPHP (o diretório do simplesamlphp no experimento foi /var):

# cd /var/

# git clone https://github.com/simplesamlphp/simplesamlphp.git simplesamlphp

Copie os templates de configuração e matadata:

# cd simplesamlphp

# cp -r metadata-templates/*.php metadata/

# cp -r config-templates/*.php config

Para ajudar na instalação de algumas dependências necessárias, dentro do diretório simplesamlphpvamos ter um arquivo composer. Esse arquivo é utilizado pela ferramenta Composer2, que funcionacomo gerenciador de dependências PHP, permitindo que as bibliotecas necessárias para o projeto sejamdeclaradas em um arquivo composer, e ele vai gerenciar (instalar/atualizar) para o desenvolvedor. Instaleo Composer:

2https://getcomposer.org/download/

7

$ sudo apt-get install composer

E dentro do diretório do simplesamlphp execute:

$ sudo composer install

Adicione um link do diretório do simplesamlphp para o diretório /var/www/html/ (para sabermais sobre o comando ln, use o comando man ls no terminal):

$ cd /var/www/html/

$ ln -s /var/simplesamlphp/www simplesaml

O diretório que precisa ser acessível é o simplesamlphp/www. Você pode expôr esse diretório devárias formas, uma das maneiras é a que usamos em nosso experimento (criando um link entre o diretóriodo simplesamlphp e o diretório /var/www/html), mas você também pode editar o arquivo deconfiguração do Apache e adicionar uma virtual host, como na documentação do SimpleSamlPHP3.

Vamos passar agora para a configuração de algumas informações no arquivo config/config.php,como a senha do usuário admin:

’auth.adminpassword’ => ’setnewpasswordhere’,

Mude também o valor de SecretSalt (uma string aleatória usada em algumas partes do SimpleSamlPhppara gerar hash seguras). Caso você não mude o valor default, o SimpleSamlPHP dará um erro. O co-mando a seguir para ajudar a gerar a string para o SecretSalt:

$ tr -c -d ‘0123456789abcdefghijklmnopqrstuvwxyz’ </dev/urandom |

dd bs=32 count=1 2>/dev/null;echo

Reinicie o apache.

# service apache2 start

2.1.2 Criando IdP

Com a instalação e configuração finalizadas, o próximo passo é configurar o liberar a funcionalidade IdPem nosso projeto SimpleSamlPHP. Para isso, basta editar o arquivo config/config.php. As opçõesenable.saml20-idp e enable.shib13-idp, controlam tanto o SAML 2.0 quanto o Shibboleth 1.3. No nossoexemplo, basta liberar a opção enable.saml20-idp.

’enable.saml20-idp’ => true

O próximo passo é configurar a forma como o usuário se autentica no IdP. Existem vários módulos nodiretório modules/, o que escolhemos foi o exampleauth:UserPass (autenticar o usuário usando umalista de usernames e passwords).

$ touch modules/exampleauth/enable

3https://simplesamlphp.org/docs/stable/simplesamlphp-install#section_6

8

Agora devemos configurar nossa fonte de autenticação (authentication source) no SimpleSAMLphpIdP. A fonte de autenticação será a base de usuários utilizada para realizar a autenticação. No Simple-SAMLphp podemos utilizar a autenticação de usuários a partir de várias fontes de autenticação comoservidor LDAP, usuários em um servidor SQL, etc.

Cada fonte de autenticação tem um nome, que é usado para referenciar uma configuração especi-fica no IdP. Essa configuração para a fonte de autenticação pode ser encontrada no arquivo config/

authsources.php.No nosso exemplo, o conteúdo desse arquivo será:

1 <?php2 $ c o n f i g = a r r a y (3 / / Th i s i s a a u t h e n t i c a t i o n s o u r c e which h a n d l e s admin a u t h e n t i c a t i o n .4 ’ admin ’ => a r r a y (5 / / The d e f a u l t i s t o use c o r e : AdminPassword6 / / b u t i t can be r e p l a c e d wi th7 / / any a u t h e n t i c a t i o n s o u r c e .8 ’ c o r e : AdminPassword ’ ,9 ) ,

10 ’ example−u s e r p a s s ’ => a r r a y (11 ’ exampleau th : UserPass ’ ,12 ’ admin : adminpass ’ => a r r a y (13 ’ uid ’ => a r r a y ( ’ admin ’ ) ,14 ’ mai l ’ => ’ admin@email . com ’ ,15 ’ f i r s t _ n a m e ’ => ’ User ’ ,16 ’ l a s t_name ’ => ’Admin ’17 ) ,18 ’ d e v e l o p e r : d e v e l o p e r p a s s ’ => a r r a y (19 ’ uid ’ => a r r a y ( ’ d e v e l o p e r ’ ) ,20 ’ mai l ’ => ’ deve lope r@emai l . com ’ ,21 ’ f i r s t _ n a m e ’ => ’ User ’ ,22 ’ l a s t_name ’ => ’ Deve loper ’23 ) ,24 ) ,25 ) ;

Essa configuração cria dois usuários: admin e developer, com senhas adminpass e developerpass, res-pectivamente. Os atributos para cada usuário é configurado no array referenciado por index. Por exemplo,os atributos do usuário admin:

1 a r r a y (2 ’ exampleau th : UserPass ’ ,3 ’ admin : adminpass ’ => a r r a y (4 ’ uid ’ => a r r a y ( ’ admin ’ ) ,5 ’ mai l ’ => ’ admin@email . com ’ ,6 ’ f i r s t _ n a m e ’ => ’ User ’ ,7 ’ l a s t_name ’ => ’Admin ’8 ) ,

9

2.1.3 Configurando IdP metadata

O metadata do IdP é configurado por um arquivo armazenado em metadata/saml20-idp-hosted.

php. Nesse arquivos devemos definir um host para o IdP, o local onde se encontram a privatekey e o cer-tificate, e por fim, a fonte de autenticação que deverá ser usada para autenticar o usuário. Como podemosver nos comentário do arquivo abaixo, o nome dado para a fonte de autenticação deve ser o mesmodefinido em config/authsources.php.

O conteúdo da configuração para o SAML 2.0 IdP seria:

1 <?php2 $ m e t a d a t a [ ’__DYNAMIC: 1 __ ’ ] = a r r a y (3 /∗4 ∗ The hostname f o r t h i s IdP . Th i s makes i t p o s s i b l e t o run m u l t i p l e5 ∗ IdPs from t h e same c o n f i g u r a t i o n . ’__DEFAULT__ ’ means t h a t t h i s one6 ∗ s h o u l d be used by d e f a u l t .7 ∗ /8 ’ hos t ’ => ’__DEFAULT__ ’ ,9 /∗

10 ∗ The p r i v a t e key and c e r t i f i c a t e t o use when s i g n i n g r e s p o n s e s .11 ∗ These a r e s t o r e d i n t h e c e r t −d i r e c t o r y .12 ∗ /13 ’ p r i v a t e k e y ’ => ’ s e r v e r . pem ’ ,14 ’ c e r t i f i c a t e ’ => ’ s e r v e r . c r t ’ ,15 /∗16 ∗ The a u t h e n t i c a t i o n s o u r c e which s h o u l d be used t o a u t h e n t i c a t e t h e17 ∗ u s e r . Th i s must match one of t h e e n t r i e s i n c o n f i g / a u t h s o u r c e s . php .18 ∗ /19 ’ au th ’ => ’ example−u s e r p a s s ’ ,20 ) ;

2.1.4 Criando self signed certificate

O SimpleSAMLPHP precisa de um certificado para as mensagens SAML. O diretório onde essas infor-mações são armazenadas, pode ser encontrado no arquivo de configuração (config/config.php).

’certdir’ => ’cert/’,

Para gerar uma private key e um certificado, execute o comando no diretório indicado no arquivo deconfiguração:

$ openssl req -new -x509 -days 3652 -nodes -out server.crt -keyout

server.pem

2.2 Keystone Federado

Com a configuração do IdP finalizada, passamos então para o Provedor de Serviço usando o Keystone.Em nosso experimento, o acesso ao Keystone será dado por meio de uma federação SAML, apos ousuário se autenticar no IdP SimpleSamlPHP.

10

Para liberar a federação, são necessários três passos principais são descritos na documentação: executaro Keystone no Apache, Configurar o Apache para usar um método de autenticação federado, e por fim,configurar a Federação no Keystone. Esses passos serão descritos nas próximas subseções, finalizandocom a demonstração do funcionamento do SP e IdP.

2.2.1 Keystone executando no Apache

Para nosso experimento usamos o Apache como proxy reverso, e habilitaremos o mod_proxy_uwsgi parasubir o Keystone com o uwsgi.

O arquivo httpd/uwsgi-keystone.conf4 deve ser copiado para a localização do Apache ser-ver (/etc/apache2/sites-enabled). O Ubuntu requer que o pacote libapache2-mod-proxy-uwsgiseja instalado, e habilitado:

enable using sudo a2enmod proxy

sudo a2enmod proxy_uwsgi.

Crie um link entre o arquivo em sites-available para sites-enabled:

ln -s /etc/apache2/sites-available/uwsgi-keystone.conf

/etc/apache2/sites-enabled/

Agora para configurar e inicializar o serviço uwsgi, é necessário copiar os arquivos do repositório doKeystone, httpd/keystone-uwsgi-admin.ini5 e httpd/keystone-uwsgi-public.ini6

para /etc/keystone.

$ sudo pip install uwsgi

$ uwsgi /etc/keystone/keystone-uwsgi-admin.ini

$ uwsgi /etc/keystone/keystone-uwsgi-public.ini

2.2.2 Configure o Apache para usar um método de autenticação federado

Atualmente existem dois protocolos suportados: SAML e OpenID Connect. Para esse experimento usa-mos o SAML com Shibboleth. Seguimos então para a instalação do Shibboleth:

$ apt-get install libapache2-mod-shib2

Configuramos o Keystone virtual host (/etc/apache2/sites-enabled/keystone.conf)e ajustamos a configuração para o SAML2. Adicionamos as diretivas<Location> para cada Provedor deIdentidade.

1 < L o c a t i o n / S h i b b o l e t h . sso >2 S e t H a n d l e r s h i b3 </ Loca t i on >45 < L o c a t i o n / v3 / OS−FEDERATION / i d e n t i t y _ p r o v i d e r s / myidp / p r o t o c o l s / mapped / au th >6 S h i b R e q u e s t S e t t i n g r e q u i r e S e s s i o n 1

4https://github.com/openstack/keystone/blob/master/httpd/uwsgi-keystone.conf5https://github.com/openstack/keystone/blob/master/httpd/keystone-uwsgi-admin.ini6https://github.com/openstack/keystone/blob/master/httpd/keystone-uwsgi-public.ini

11

7 AuthType s h i b b o l e t h8 S h i b E x p o r t A s s e r t i o n Off9 R e q u i r e v a l i d −u s e r

1011 < I f V e r s i o n < 2.4 >12 S h i b R e q u i r e S e s s i o n On13 S h i b R e q u i r e A l l On14 </ I f V e r s i o n >15 </ Loca t i on >

Duas informações importantes na diretiva <Location> é o mapped, que é o protocolo que vamos usar,e o myidp é o nome associado com o IdP no Keystone. O próximo passo é habilitar o modulo shib2:

$ a2enmod shib2

Reiniciar o Apache:

$ service apache2 restart

Configurando shibboleth2.xmlCom o Keystone vhost configurado, passamos para a configuração do Shibboleth e para o upload do

Metadata no IdP.Iniciamos criando um keypar para o Shibboleth. Esse arquivo criado será armazenado em /etc/

shibboleth/sp-key.pem:

$ shib-keygen -y <number of years>

Agora o arquivo que precisará ser editado é o /etc/shibboleth/shibboleth2.xml. Primeirodefine o SP entity ID. Esse valor não precisa ser uma URI real, somente ter o formato. É importante queo início seja do endereço onde se encontra o shibboleth (https://10.7.49.47:5000/).

<ApplicationDefaults entityID="https://10.7.49.47:5000/shibboleth">

Configure o IdP entity ID. Esse valor pode ser recuperado do IdP SimpleSamlPHP que criamos.Como podemos ver na Figura 1, na aba de Federação podemos ver a lista de IdPs, e o entity ID de

cada um. Esse entity ID deve ser colocado em nosso arquivo de configuração do shibboleth:

1 <SSO e n t i t y I D =" h t t p s : / / myidp . example . com / v3 / OS−FEDERATION / saml2 / i d p ">

Também é preciso adicionar a URI do metadata do IdP:

1 < M e t a d a t a P r o v i d e r t y p e ="XML"2 u r i =" h t t p : / / 1 0 . 7 . 4 9 . 4 7 / s imp le samlphp /www/ saml2 / i d p / m e t a d a t a . php " / >

Feitas a edições, reinicie o Shibboleth e o apache:

$ service shibd restart

$ service apache2 restart

Possíveis erros que possam acontecer, vão estar armazenados em /var/log/shibboleth/shibd\

_warn.log. Para recuperar o arquivo de metadata do SP para fazer o upload no IdP, basta fazer o down-load:

$ wget http://10.7.49.47/Shibboleth.sso/Metadata

12

Figura 1: Entity ID do IdP

2.2.3 Configure Federação no Keystone

Configurar os drivers de autenticação no keystone.confÉ necessário adicionar os métodos de autenticação na seção [auth] do arquivo keystone.conf.

1 [ a u t h ]2 methods = e x t e r n a l , password , token , mapped , op en id

Criando grupos e atribuindo papéis no keystoneNão é necessário criar usuários no SP, porém é preciso criar uma base de grupos e papéis para autorizar

usuários federados. A função do mapping é mapear o usuário em objetos no serviço de identidade local.Então é necessário criar grupos no SP que correspondam aos grupos do IdP, e esses grupos devem ter

papéis em um ou mais projetos ou domínios.Para criar um novo domínio e projeto:

$ openstack domain create federated_domain

$ openstack project create federated_project --domain federated_domain

Um novo grupo:

$ openstack group create federated_users

Adicionar o grupo no domínio e projeto:

$ openstack role add --group federated_users --domain

federated_domain Member

13

$ openstack role add --group federated_users --project

federated_project Member

Adicionando Identity Provider(s), Mapping(s), e Protocol(s)Para utilizar federação, foi necessário criar no serviço de identidade O Provedor de Identidade, o

Mapping e Protocol. Criamos um objeto IdP no Keystone para representar o IdP que ira ser usado paraautenticar os usuários:

$ openstack identity provider create --remote-id

http://10.7.49.47/simplesamlphp/www/saml2/idp/metadata.php myidp

O valor para o remote-id é o identificador único do IdP, o entityID que temos do nosso IdP Sim-pleSamlPHP. O nome local do IdP foi definido em nosso exemplo como myidp, mas fica a cargo dodesenvolvedor decidir como o IdP será referenciado no SP. É importante manter a coerência durante aconfiguração.

MappingO mapping é uma lista de regras usada para mapear atributos de federação para objetos da API de

identidade. Um IdP tem exatamente um mapping por protocolo, como o que usamos para nosso experi-mento:

1 [2 {3 " l o c a l " : [4 {5 " u s e r " : {6 " name " : "{0}"7 } ,8 " group " : {9 " domain " : {

10 " i d " : "2 ad429b2bac041b9b1142dd371f f95e7 "11 } ,12 " name " : " f e d e r a t e d _ u s e r s "13 }14 }15 ] ,16 " remote " : [17 {18 " t y p e " : " givenName "19 }20 ]21 }22 ]

Esse conteúdo foi colocado em um arquivo rules.json, e usado para a criação do mapping:

$ openstack mapping create --rules rules.json myidp_mapping

Protocolo

14

Um protocolo contém informações que determinam que mapping deve ser usado para uma solicitaçãode entrada feita por um IdP. Um IdP pode ter múltiplos protocolos suportados. Você pode criar umprotocolo como este:

$ openstack federation protocol create mapped --mapping myidp_mapping

--identity-provider myidp

O nome que você dá ao protocolo não é arbitrário. Ele deve corresponder ao nome do método quevocê deu na opção [auth] do arquivo de configuração do Keystone. Quando a autenticação será referidacomo o protocol_id.

2.2.4 Demonstração de uso

Nessa demonstração, vamos mostrar o processo para obter um unscoped token. Para iniciar a autenticaçãoFederada, um usuário deve acessar a URL dedicada identificando o IdP (identity_provider) e o protocolo(protocol). O URL tem um formato de:

/v3/OS-FEDERATION/identity\_providers/{identity\_provider}/protocols/

{protocol}/auth}

Essa instância segue um procedimento de autenticação padrão do SAML2, ou seja, o usuário seráredirecionado para a página de autenticação do Provedor de Identidade e pedido o fornecimento decredenciais, como podemos ver na Figura 1.

Figura 2: Página de autenticação do IdP

Após a autenticação com êxito, o usuário será redirecionado de volta ao provedor de serviços. Seestiver usando um navegador da Web, um token será retornado em formato XML.

15

Figura 3: Resposta do IdP após autenticação bem sucedida

2.3 Discussão

A experiência de implementar uma infraestrutura federada com o SimpleSamlPHP como IdP e o Keys-tone como SP foi concluída com sucesso. Apesar disso, durante o experimento, algumas dificuldadesforam encontradas. Após configurarmos o Keystone para Federação, tentamos recuperar o unscoped to-ken e recebemos a seguinte mensagem:

1 {2 " e r r o r " : {3 " message " : " The r e q u e s t you have made r e q u i r e s a u t h e n t i c a t i o n . " ,4 " code " : 401 ,5 " t i t l e " : " U n a u t h o r i z e d "6 }7 }

Para verificar o que poderia estar acontecendo, fizemos um script Python para realizar dois passos (1)acessar a url do SP para se autenticar, e (2) preencher o formulário de login do IdP e enviar.

Na primeira parte acessamos a página do SP, e fomos redirecionados para a página de login do IdP. Aofazer um login no IdP, obtivemos um arquivo SAML com as informações do usuário autenticado, porémainda tínhamos como retorno "Unauthorized". Com isso, concluímos que o problema estava no momentoque o SP recebia o SAML com os atributos.

Foi então que seguimos para verificar o log do Keystone, e verificamos que mesmo recebendo asinformações do usuário, o Keystone não substituía os dados no mapping que criamos, e com isso, nãoera possível criar um usuário válido no Keystone.

16

O nosso último passo foi analisar o shibboleth, e como resultado percebemos que configuraçoes con-tidas no attribute-policy.xml faziam os atributos vindos no arquivo SAML, fossem ignorados.O problema foi resolvido, alterando os arquivos attribute-policy.xml (editando o filtro que im-pedia que os atributos fosse recebidos), e attribute-map.xml (arquivo onde os atributos recebidossão descritos).

3 Autorização

A aplicação da autorização é um processo de determinar se uma entidade está autorizada a fazer algoquando do pedido de acesso, seguido pela concessão ou não do acesso. No contexto da plataformaFIWARE, esse processo é realizado por dois componentes: o Authorization PDP GE determina se oacesso deve ser permitido, e com base nesta decisão, o PEP Proxy GE concede ou nega o acesso solici-tado à entidade requerente.

Em nosso último relatório, descrevemos a resolução de um erro que estava nos impedindo de continuaros testes com a ferramenta de autorização do Fiware, o AuthZForce. Corrigido o erro, pudemos continuarcom os testes relacionados a autorização e finalizar o exemplo que envolvia o PDP GE.

3.1 Demonstração de autorização com o Fiware

Nessa seção, explicaremos o que foi necessário fazer para finalizar nossos testes com o PDP, conside-rando a arquitetura apresentada no relatório do WP5 - Middleware do Terceiro Trimestre [1].

Figura 4: Arquitetura da aplicação com o PEP Proxy e o PDP

Nosso foco estará voltado para a configuração necessária do Keyrock junto ao PDP, como a criaçãode usuário, de papéis e permissões. Também mostraremos como realizar a associação entre permissões epapéis, e como atribuir um papel a um usuário. Ao final, teremos funcionando o passo 9 e 10 mostradosna Figura 4.

17

3.1.1 Configurando papéis e permissões no Keyrock

O ponto de partira para o experimento foi a criação de um usuário de test. Para o exemplo, foi necessáriousar um script Python para a criação desse usuário. Isso por que p Keyrock não oferece uma interface degerencia de usuários, mas sim uma API, o SCIM. Esta API simples abstrai a API de gerenciamento deusuários do OpenStack Keystone, de forma que o próprio Keystone poderia ser utilizado para a definiçãode usuários. O trecho do código usado para a criação do novo usuário.

1 d e f c r e a t e _ u s e r ( k e y s t o n e _ u r l , t o k e n ) :2 j s o n _ p a y l o a d = {3 " userName " : " t e s t " ,4 " d isp layName " : " T e s t " ,5 " password " : " t e s t 1 2 3 " ,6 " e m a i l s " : [7 {8 " v a l u e " : " t e s t @ e m a i l . com"9 }

10 ]11 }1213 h e a d e r s = { ’X−Auth−token ’ : token , ’ Conten t−Type ’ : ’ a p p l i c a t i o n / j son ’ }14 r e s p o n s e = r e q u e s t s . p o s t ( u r l = k e y s t o n e _ u r l + ’ / v3 / OS−SCIM / v2 / Use r s / ’ ,15 d a t a = j s o n . dumps ( j s o n _ p a y l o a d ) ,16 h e a d e r s = h e a d e r s )1718 i f r e s p o n s e . s t a t u s _ c o d e i n ( 2 0 1 , 2 0 0 ) :19 l o g g i n g . i n f o ( r e s p o n s e . t e x t )20 e l s e :21 l o g g i n g . e r r o r ( r e s p o n s e . t e x t )

No código acima temos o método create_user, que recebe como parâmetro a URL do Keystone (ex.:http://10.7.49.61:5000/), e o token (este token é requisitado ao Keystone e precisa ser enviado a cadarequisição feita para obter a permissão ao recurso solicitado). Das linhas 2 a 11, temos a definição davariável que contém as informações do usuário que desajamos criar. Na linha 12, definimos o cabeçalhoda nossa requisição, com o token e o Content-Type, e por fim, da linha 13 a 15, realizamos a requisiçãoPOST, passando a URL do recurso, as informações do usuário, e o cabeçalho.

Após criar o novo usuário cadastrado, podemos utilizar a interface do Keyrock para criar um novopapel, o de developer, como exibido na Figura 5.

O próximo passo foi criar uma nova permissão. Os dados que precisarão ser informados foram o nomeda permissão (nesse exemplo Get Service), uma descrição, a ação HTTP (GET em nosso exemplo),e o recurso que precisa dessa permissão para ser acessado através da ação HTTP que definimos nocampo anterior. Podemos ver todos esses campos na Figura 6. No caso do recurso (Resource), colocamosservice1/list por que em nosso exemplo, a URL do recurso que estamos protegendo é similar a http://example.com/service1/list.

Finalizando a criação do papel e da permissão, fazemos a associação dos dois, ainda usando a interfacedo Keyrock, como mostramos na Figura 7. Podemos ver uma coluna apresentando a lista de papéis, eoutra coluna com a lista de permissões. Pela interface do Keyrock, podemos selecionar um determinado

18

Figura 5: Criando papel developer

Figura 6: Criando nova permissão

19

papel, e marcar quais permissões serão atribuídas a ele. Por fim, devemos salvar as alterações feitasclicando no botão Save.

Figura 7: Associando papel e permissão

Por fim, damos ao usuário o papel que acabamos de criar. Fizemos essa atribuição por meio de umscript Python, como apresentamos abaixo.

1 d e f p u t _ r o l e _ i n _ u s e r ( u s e r _ i d , a p p l i c a t i o n _ i d , r o l e _ i d , k e y s t o n e _ u r l , t o k e n ) :2 h e a d e r s = { ’X−Auth−token ’ : t o k e n }34 r e s p o n s e = r e q u e s t s . p u t (5 u r l = k e y s t o n e _ u r l + ’ / v3 / OS−ROLES / u s e r s / ’6 + u s e r _ i d + ’ / a p p l i c a t i o n s / ’7 + a p p l i c a t i o n _ i d + ’ / r o l e s / ’ + r o l e _ i d ,8 h e a d e r s = h e a d e r s )9

10 i f r e s p o n s e . s t a t u s _ c o d e i n ( 2 0 1 , 2 0 0 ) :11 p a r s e d = j s o n . l o a d s ( r e s p o n s e . t e x t )12 l o g g i n g . i n f o ( j s o n . dumps ( pa r sed , i n d e n t =4 , s o r t _ k e y s =True ) )13 r e t u r n p a r s e d14 e l s e :15 l o g g i n g . e r r o r ( ’PUT ROLE IN USER ### ’ + r e s p o n s e . t e x t )

Nesse método, recebemos o ID do usuário que receberá o papel, o ID da aplicação que essas alteraçõesestão sendo feitas, o ID do papel, a URL do Keystone, e o token. Neste caso, a requisição feita será um

20

PUT, juntamente com todos os dado recebidos como parâmetro e o token no cabeçalho.Com usuário, papel e permissão criados e configurados, foi então possível dar continuidade ao nosso

teste, e através da aplicação, realizarmos o login do usuário de teste, e receber como resultado do PEP oretorno Decision: [ ’Permit’ ], nos indicando a permissão para acessar ao recurso.

1 pep−proxy_1 | 2016−12−14 1 6 : 4 9 : 4 4 . 4 7 4 − INFO : IDM−C l i e n t − Checking2 t o k e n wi th IDM . . .3 pep−proxy_1 | 2016−12−14 1 6 : 4 9 : 4 4 . 5 3 1 − INFO : AZF−C l i e n t − Checking4 a u t h wi th AZF . . .5 pep−proxy_1 | 2016−12−14 1 6 : 4 9 : 4 4 . 5 3 3 − INFO : AZF−C l i e n t − Checking6 a u t h o r i z a t i o n t o r o l e s [ ’395 c f 9 f f 2 2 2 5 4 e 0 e b 3 6 b f a e d 4 5 e e d b b 9 ’ , ’ d e v e l o p e r ’ ]7 t o do GET on s e r v i c e 1 / l i s t and app 5 fca86e2905e4970a fcc01be4e4e67688 pep−proxy_1 | 2016−12−14 1 6 : 4 9 : 4 4 . 5 3 4 − INFO : AZF−C l i e n t − Checking9 a u t h wi th AZF . . .

10 pep−proxy_1 | 2016−12−16 1 6 : 4 9 : 4 4 . 5 3 5 − DEBUG: AZF−C l i e n t −11 D e c i s i o n : [ ’ Permi t ’ ]

3.2 Discussão

As atividades relacionadas a autorização com o AuthZForce foram finalizadas, assim como a aplicaçãode exemplo que ficou pendente no relatório passado por causa de uma falha, já corrigida, do PEP.

Durante os experimentos, não chegamos a ter nenhum entrave especificadamente com o AuthZForce eao fim, ele realizou o que desejávamos. Porém, os testes que realizamos com ele foram superficiais. Alémdisso, houve uma grande parcela do tempo voltada para outras GEs que precisavam estar funcionandopara que pudéssemos usar o PDP. Por causa de erros nas ferramentas, ou de lacunas na documentação,atrasamos os testes com o PDP. Nesse caso, um próximo passo seria realizar um estudo mais aprofundadona ferramenta, e testes mais complexos, para podermos então indica-lo com segurança para fazer controlede acesso de uma aplicação como o SGEOL.

Um outro ponto importante é que, de acordo com o FIWARE, o mecanismo de definição de politicasde acesso é o Keyrock (como mostramos na Figure 6). As opções oferecidas são a de definir de um papel,verbo e recurso, ou então a de uma política XACML. O problema que levantamos nesse caso, é quemgeraria essa política. Pensando nisso, estamos dando andamento na definição de uma política de exemplodo SGEO, para podermos fazer testes com XACML no Keyrock e AuthZForce.

Outro possibilidade que podemos considerar, é a de analisar outras ferramentas de autorização, comoWSO27, que suporta XACML e possui uma interface amigável.

4 Considerações Finais

Este documento apresentou um relato das atividades realizadas durante o primeiro trimestre de execuçãodo projeto Smart Metropolis por parte do WP4 - Infraestrutura, no âmbito da tarefa de Estudo sobreos conceitos, ferramentas e bibliotecas relacionados a controle de acesso (autenticação e autorização).Durante o primeiro trimestre, o foco principal foi na análise do Keystone, componente base do Keyrock,no que diz respeito ao suporte a autenticação em ambiente federado e no funcionamento completo dofluxo de autenticação e autorização, com vistas à sua utilização no contexto do SGEOL.

7http://wso2.com

21

Como resultado do estudo que fizemos com Keystone configurado com federação, e da interação commembros da equipe de desenvolvimento do Keyrock do Fiware, chegamos a conclusão que para nósnão exitem motivos que justifiquem a utilização do Keyrock para aplicativos desenvolvidos pelo projetoSmart Metropolis. Neste contexto, o OpenStack Keystone se mostrou mais que suficiente para as ne-cessidades de autenticação. Além disso, é preciso considerar também as características das organizaçõesque utilizarão os sistemas desenvolvidos. Nesse contexto, um próximo passo é levantar as necessidadesespecíficas do SGEOL no que diz respeito a autenticação/autorização de modo a avaliarmos o uso doKeystone oficial através da implantação de um estudo de caso.

Também foi possível realizar a conclusão da aplicação de exemplo que demonstra a autorização atra-vés do AuthZForce. Com todas as aplicações funcionando, e o fluxo de autorização de autenticaçãofinalizados, podemos sugerir como próximo passo o levantamento de outras ferramentas similares aoAuthZForce como PDP. Como estudo de caso para esta tarefa, está em andamento a definição de umapolítica de acesso que capture um estudo de caso baseado em um cenário definido pela equipe da Prefei-tura Municipal do Natal no contexto do SGEOL.

Referências

[1] WP5 Middleware. Evoluções sobre os habilitadores genéricos da plataforma fiware. Technicalreport, IMD/UFRN, November 2016.