Embed Size (px)
Citation preview
Universidade Federal do Rio Grande do Norte
Instituto Metrópole Digital
Smart Metropolis – Plataformas e Aplicações para Cidades Inteligentes
WP5 - Middleware
Evoluções sobre os Habilitadores Genéricos da Plataforma Fiware
Natal-RN, Brasil Novembro de 2016
Equipe Técnica Docentes Prof.ª Dra. Thais Vasconcelos Batista (Coordenadora) - DIMAp-UFRN Prof. Dr. Carlos Eduardo da Silva Discentes Gabriela Cavalcante da Silva
Sumário
1 Introdução.....................................................................................................................5
7 Security.........................................................................................................................57.1 Objetivos..............................................................................................................................57.2 Conceitos Básicos e Definições.............................................................................................6
7.2.1 Gerenciamento de Identidade e Acesso (Identity and Access Management)...................67.2.2 Segurança Cibernética (CyberSecurity).............................................................................87.2.3 Confiança e Gestão de Confiabilidade (Trust and Trustworthiness Management).........8
7.3 Aplicação de Exemplo........................................................................................................107.4 Visão arquitetural do Capítulo Técnico.............................................................................137.5 Descrição do Identity and Access Management GE..........................................................15
7.5.1 Visão Geral da Arquitetura do Keyrock.........................................................................157.5.2 APIs....................................................................................................................................177.5.3 Descrição do Exemplo da Aplicação................................................................................21
7.6 Descrição dos Componentes de Autorização (PEP Proxy GE e Authorization PDP GE).317.6.1. Conceitos Básicos sobre Controle de Acesso..................................................................317.6.2 Visão Geral da Arquitetura do Authorization PDP GE e PEP Proxy GE....................337.6.3 Representando Políticas de Controle de Acesso usando XACML.................................367.6.3. APIs...................................................................................................................................377.6.3.1. APIs para Administração de domínio de política.......................................................377.6.3.2. API para Administração de Política............................................................................387.6.4 Cenários de Uso.................................................................................................................39
7.7 Descrição do CyberSecurity..............................................................................................457.8 Descrição do Trustworthy Factory GE..............................................................................487.9 Considerações Finais.........................................................................................................52
7.9.1 Problemas Encontrados....................................................................................................527.9.2 Pendências..........................................................................................................................537.9.3 Próximos passos.................................................................................................................53
1 Introdução
Esse documento é a continuidade do trabalho realizado no relatório RT2,
especificamente, no Capítulo de Segurança do FIWARE (que está representado pelo Capítulo
7 no RT2, por isso manteremos aqui o próximo capítulo como sendo o 7). Esse documento
descreve os cinco habilitadores genéricos do Capítulo de Segurança: Identity Management
GE, Authorization PDP GE, PEP Proxy GE, Cyber Security GE e Trustworthy Factory GE.
Apesar de ter trabalhado com todos eles, uma maior ênfase foi dada ao Gerenciamento de
Identidade e Acesso, mostrando um maior detalhamento sobre estes três primeiros GEs com
suas respectivas implementações de referência: KeyRock, AuthZForce e Wilma. Vale salientar
que os outros dois GEs estão classificadas como deprecated desde fevereiro do ano presente.
Também é apresentada uma aplicação como estudo de caso para a apresentação dos GEs de
Segurança, sendo esta formada por um componente back-end (definindo um webservice
REST) e um componente front-end (correspondente a uma aplicação Web para interação com
o usuário que realiza chamadas aos serviços definidos) que puderam ser utilizados de forma a
experimentar a integração dos GEs apresentados com seus componentes.
A próxima seção é identificada como seção 7 para se refereir a continuidade da seção
7 do RT2. 7 Security
7.1 Objetivos
Sabemos que é altamente desejado que aplicativos, softwares ou informações sejam
acessados somente por aqueles autorizados para tal. Para isso, existem vários mecanismos
que lidam com diferentes aspectos de segurança da informação, tais como autenticação,
políticas de segurança, entre outros. A plataforma Fiware foi projetada para considerar estes
aspectos em uma abordagem secure by design, onde atributos de segurança da plataforma em
si, e das aplicações que executem sobre ela, são considerados através de uma arquitetura de
segurança que engloba questões relacionadas a gestão de identidades, controle de acesso e
monitoramento de eventos de segurança. Isso é conseguido com um conjunto de Generic
Enablers (GEs) que podem ser integrados com outros GEs da plataforma.
Neste contexto, este capítulo apresenta um estudo sobre o Capítulo Técnico de
Segurança (Security) da plataforma Fiware que oferece GEs responsáveis pela autenticação,
autorização e confiabilidade de informações. Para uma maior compreensão do estudo deste
capítulo, iniciaremos com uma introdução de alguns conceitos básicos da literatura (Seção
7.2). Para demonstrar a aplicação desses conceitos, desenvolvemos uma aplicação de
exemplo (Seção 7.3) que será explorada ao longo deste estudo. Em seguida, apresentamos
uma visão geral da arquitetura do Capítulo Técnico de Segurança, identificando seus
componentes principais (Seção 7.4), que serão explorados nas seções subsequentes. Mais
especificamente, abordaremos os seguintes GEs: Identity Management GE (Seção 7.5),
Authorization PDP GE e PEP Proxy GE (Seção 7.6), Cyber Security GE (Seção 7.7) e
Trustworthy Factory GE (Seção 7.8).
Durante este estudo, maior ênfase foi dada aos GEs relacionados a controle de acesso,
mais especificamente Identity Management GE, Authorization PDP GE e PEP Proxy GE,
adotando um ponto de vista de desenvolvedor de aplicações que atuariam como clientes
desses GEs. É importante mencionar também que este estudo considera a versão 4 da
plataforma Fiware (R4).
7.2 Conceitos Básicos e Definições Esta seção apresenta alguns termos e definições utilizados na descrição do Capítulo
Técnico de Segurança da plataforma Fiware, que é construído em torno de três áreas
temáticas: Gerenciamento de Identidade e Acesso (Identity and Access Management);
Segurança Cibernética (CyberSecurity); e Confiança e Gestão de Confiabilidade (Trust and
Trustworthiness Management). Desse modo, a terminologia será apresentada em torno desses
tópicos.
7.2.1 Gerenciamento de Identidade e Acesso (Identity and Access Management)
● Identidade Digital (Digital Identity): Uma identidade digital é uma representação
digital de um conjunto de afirmações sobre um sujeito ou entidade. Essas afirmações,
também chamadas de atributos, podem ter sido feitas pelo próprio sujeito ou por
terceiros. Deve ser observado que para qualquer sujeito normalmente haverá múltiplas
identidades digitais.
● Autenticação (Authentication): O ato de verificar a identidade de uma entidade ou
sujeito. A autenticação permite confirmar que um determinado sujeito ou entidade é
quem ele afirma ser. Ao utilizar o termo entidade, permitimos que não somente
humanos possam ser autenticados, mas também entidades genéricas, como um
sistema ou um equipamento.
● Credencial (Credential): Um conjunto de dados apresentados como evidência de
uma identidade e/ou direitos reivindicados. Normalmente utilizado para autenticação
(por exemplo, senha).
● Provedor de Identidades (Identity Provider - IdP): Um provedor de identidade é
uma entidade que atua como um serviço de autenticação para usuários finais, e como
fonte de dados de autenticação para provedores de serviços. Pode ser entendido como
uma base de usuários.
● Participante confiável (Relying party - RP): Uma entidade que confia em uma
representação de identidade ou afirmação (por exemplo, token de segurança) emitido
por uma outra entidade (ex: IdP) dentro de um contexto de requisição.
● Single Sign-On (SSO): Da perspectiva de uma entidade cliente (usuário ou
aplicação), o SSO é a capacidade de autenticar-se com alguma entidade do sistema
(um IdP), e ter a autenticação respeitada por outras entidades, denominados
provedores de serviços (um RP). Em outras palavras, é a capacidade de um cliente se
autenticar somente um vez e ter acesso a múltiplos serviços.
● Gestão de Identidades de Federadas (Federated Identity Management - FIM):
Capacidades de gerenciamento de identidade que permitem que os usuários de um
ambiente (organização, ou domínio de segurança, também conhecido como realm)
possa acessar os serviços de outro, sem a necessidade de se registrar na base de
usuários do domínio que provê o serviço. Uma federação é uma parceria confiável
entre diferentes domínios em uma relação produtor-consumidor, onde todos os
usuários de um domínio tem acesso a todos os serviços oferecidos pelos outros
domínios.
● Autorização (Authorization): Termo utilizado alternadamente para dois significados
próximos, mas distintos, dependendo do contexto:
○ Gestão de autorização (Authorization Management): Processo de atribuição
de permissões para entidades, também conhecida como user-permission
assignment. No Fiware, isso é feito através do IDM GE, de forma que o termo
é utilizado com esse significado.
○ Aplicação de autorização (Authorization Enforcement): Processo de
determinar se uma entidade está autorizada a fazer algo quando do pedido de
acesso, seguido pela concessão ou não do acesso. No contexto da plataforma
Fiware, esse processo é realizado por dois componentes: o Authorization PDP
GE determina se o acesso deve ser permitido, e com base nesta decisão, o PEP
Proxy GE concede ou nega o acesso solicitado à entidade requerente.
7.2.2 Segurança Cibernética (CyberSecurity)
● CyberSecurity: O processo de proteger informação através da prevenção, detecção e
resposta a ataques.
● Risco (Risk): Uma medida de quanto uma entidade é ameaçada por um evento ou
circunstância potencial. Risco normalmente é calculado em função do impacto
adverso caso o evento ocorra, e a probabilidade/possibilidade do evento ocorrer.
● Gerenciamento e Correlação de Eventos de Segurança (SIEM - Security
Information and Event Managent): Sistema que permite a coleta, armazenamento e
análise de eventos de segurança gerados por diversos componentes de um rede,
incluindo aplicativos de segurança (como firewall e proxies), sistemas de detecção de
intrusão, e eventos de controle de acesso.
7.2.3 Confiança e Gestão de Confiabilidade (Trust and Trustworthiness Management)
● Confiança na aplicação - Trust in an application (software): O estado de
credibilidade que a parte interessada em utilizar o sistema credita neste. Por exemplo,
se um usuário não confia em um determinado sistema, a tendência será não utilizá-lo.
● Confiabilidade (Trustworthiness): Uma propriedade objetivo do aplicativo, com
base na existência (ou inexistência) de contramedidas adequadas que reduzam a
probabilidade de resultados inaceitáveis. Em outras palavras, as partes interessadas
(stakeholder) apresentam objetivos de confiabilidade (trustworthiness objective) para
o aplicativo.
● Atributo de confiabilidade (Trustworthiness attribute): Um atributo derivado de
atributos de qualidade de software, exemplo de tal atributo: segurança, capacidade de
reutilização, confiabilidade, escalabilidade, confidencialidade, entre outros, para o
contexto de confiança que podem ser quantificados por métodos de medição aplicados
para a aplicação.
● Objetivo de confiabilidade (Trustworthiness objective): A definição de uma
pontuação mínima a ser atingida para um atributo de confiabilidade.
Perfil de confiabilidade (Trustworthiness profile): A lista de objetivos de confiabilidade fornecida por qualquer das partes interessadas para o desenvolvedor do aplicativo.
7.3 Aplicação de Exemplo
Para demonstrar a utilização dos mecanismos de controle de acesso da plataforma
Fiware, desenvolvemos uma aplicação de exemplo como estudo de caso que será utilizada ao
longo deste documento. Nesta seção apresentamos a versão inicial da aplicação desenvolvida
como estudo de caso. Esta primeira versão não possui autenticação implementada, e é
formada por dois componentes: um componente back-end e um componente front-end. Sua
arquitetura é apresentada na Figura 7.1.
Figura 7.1 - Processo de chamada de operações no Web Service.
O componente back-end consiste em um Web Service REST que apresenta dois
serviços. Cada um desses serviços recebe uma chamada HTTP GET e retorna como resultado
da chamada um JSON contendo informações relevantes e resultados da chamada.
Abaixo, na Tabela 1, apresentamos a API da aplicação com a descrição das operações
que compõem os dois serviços implementados.
Tabela 1: API da Aplicação de estudo de caso
Operação Verbo HTTP Descrição
/service1 GET Ao ser chamado, o método retorna um JSON
contendo uma string simples de "Hello, World!".
/service1/<username> GET Ao ser chamado com parâmetro referente ao
nome a ser exibido (), o método retorna um JSON
contendo uma string formada pela junção das
strings "Hello, "e o texto do parâmetro recebido.
/service2 GET Ao ser chamado o método retorna em um JSON
uma lista contendo os nomes que atualmente
estão armazenados pelo servidor.
/service2/<username> GET O parâmetro recebido é salvo na lista de nomes
armazenados pelo servidor. Como resultado da
sua chamada, nenhum JSON é retornado por esse
método.
O componente de front-end corresponde a uma aplicação Web para interação com o
usuário que realiza chamadas aos serviços definidos. Nessa interface web, uma vez inseridos
os dados e selecionada a operação a ser executada, é realizada uma chamada HTTP ao
serviço correspondente no Web Service com os dados necessários à sua execução. Após a
chamada ter sido processada pelo servidor, e tendo sido retornado o JSON resultante, a
interface recebe o JSON e o processa, atualizando a interface exibida ao usuário com os
dados resultantes da chamada.
A aplicação foi desenvolvida em JSF (Java Server Faces) e nela foi criada uma
interface que permite ao usuário escolher qual das chamadas realizar, com campos para
definição das informações necessárias para as chamadas do serviço, além de permitir também
a exibição dos resultados das chamadas para o usuário.
Figura 7.2 - Arquitetura da aplicação JSF. Na Figura 7.2, vemos a arquitetura da versão inicial da aplicação JSF. Podemos
visualizar a interação entre o componente Interface, composto pelo SecurityAppMBean e o
index.xhtml (responsáveis por interagir com o usuário), e o Web Service.
A Figura 7.3 apresenta um exemplo da interface Web, onde pode ser visualizado o
processo ocorrido durante uma chamada a uma das operações dos serviços pela aplicação
JSF, bem como a interface exibida ao usuário.
Figura 7.3 - Interface da aplicação JSF.
O usuário pode escolher qual serviço vai utilizar, preenchendo os devidos campos
caso necessário, e ao final terá o resultado impresso na tela.
Estas aplicações serão utilizadas ao longo deste capítulo para exemplificar a utilização dos diferentes GEs disponibilizados pelo Capítulo Técnico de Segurança da plataforma Fiware. Desse modo, a evolução da versão inicial da aplicação será detalhada ao longo do texto.
7.4 Visão arquitetural do Capítulo Técnico
Esta seção apresenta uma visão geral da arquitetura do Capítulo Técnico de Segurança
da plataforma Fiware, identificando os diferentes GEs que implementam os recursos de
segurança da plataforma, tais como como gerenciamento de identidade, controle de acesso ou
monitoramento de segurança. A arquitetura de segurança do Fiware, exibida na Figura 7.4 é
composta por cinco GEs que juntas fornecem um conjunto abrangente de serviços para
aplicações com o intuito de cumprir com os requisitos mais importantes de segurança, como
autenticação, autorização e confiabilidade. São estes Identity Management GE, Authorization
PDP GE, PEP Proxy GE, Cyber Security GE e Trustworthy Factory GE.
Figura 7.4 - Visão geral da arquitetura de segurança [3].
O Identity Management GE (IdM) é responsável pelo gerenciamento de identidades
de usuários, organizações e aplicações, assim como de suas respectivas credenciais, e da
autenticação dessas entidades. Este GE considera requisitos para a gestão de identidades de
“coisas” (IoT), e atende às especificações para o gerenciamento de identidades sobre
diferentes domínios. Ele também oferece uma API REST para o gerenciamento de
identidades em ambientes multi-tenant, permitindo ainda a gestão de autorização, com
suporte a definição de papéis e permissões específicas de uma organização ou de uma
aplicação. Desenvolvedores interagem com este componente para registrarem suas aplicações
no IdM, e para gerenciar a segurança de suas aplicações (credenciais, papéis e políticas de
autorização). Usuário finais usam o IdM GE para se registrarem, e gerenciar seus respectivos
perfis e suas organizações, enquanto que todas as entidades clientes de aplicações utilizam o
IdM para fins de autenticação. A implementação de referência deste GE é o Keyrock.
O Authorization PDP GE (PDP) é o componente responsável por gerenciar políticas
de autorização na plataforma Fiware. Este componente utiliza a linguagem XACML para
representação de políticas, implementando a especificação XACML Core v3.0. As políticas
definidas pelos desenvolvedores por meio do IdM são gerenciadas pelo PDP, que é
responsável também por avaliar requisições de acesso, encaminhadas pelo PEP, para permitir
ou negar o acesso a serviços. A implementação de referência deste GE é o AuthZForce.
O PEP Proxy GE (PEP) atua como ponto de aplicação de políticas de segurança na
forma de um proxy-reverso HTTP, com o objetivo de proteger serviços REST. Este
componente intercepta as requisições para o serviço, interage com o IdM para autenticar a
requisição e o token da entidade cliente anexado à requisição, e em seguida interage com o
PDP que autoriza ou não o acesso ao serviço. Além de validar o token e a requisição por
meio do IdM, o PEP também recupera informações sobre o token, e seu usuário, deste mesmo
componente. Para tomar uma decisão de acesso, o PDP leva em consideração a política de
segurança definida, informações acerca da requisição do cliente, e informações acerca do
token enviado (tais como atributos do cliente obtidos do IdM). O PEP aplica a decisão do
PDP, e em caso positivo, encaminha a requisição ao serviço, e a resposta do serviço ao
cliente. A implementação de referência para este GE é o Wilma. A plataforma Fiware
suporta a utilização de outros PEPs, como por exemplo PEPs que protejam serviços não-
REST ou serviços que utilizem outros protocolos além de HTTP.
O CyberSecurity GE é uma ferramenta para a detecção, análise e resposta a incidentes
de segurança. Este componente apresenta mecanismos que permitem calcular e quantificar
vetores de ataque, realizando uma análise de vulnerabilidades e riscos, e sugerir possíveis
medições a partir de um catálogo de contra-medidas. O CyberSecurity GE depende de um
SIEM (não oferecido pela plataforma Fiware) para a coleta de eventos e informações de
segurança. A implementação de referência para este GE está classificada como deprecated no
catálogo de GEs do Fiware.
Além dos componentes apresentados na Figura 7.4, o Capítulo Técnico de Segurança
também contém um GE para questões de confiabilidade. O Trustworthy Factory GE oferece
um ambiente para o desenvolvimento de aplicações confiáveis, incluindo ferramentas
(baseada em análise estática e dinâmica de código-fonte) para a produção de evidências que
objetivos de confiabilidade foram alcançados, e uma plataforma de certificação de código
fonte, permitindo a assinatura digital de código entre outras funcionalidades. A
implementação de referência para este GE está classificada como deprecated no catálogo de
GEs do Fiware.
7.5 Descrição do Identity and Access Management GE
A gestão de identidades engloba alguns aspectos envolvidos com o acesso de usuários
a redes, serviços e aplicações, incluindo autenticação segura e privada de usuários para
dispositivos, redes e serviços, gestão de perfil de usuário e de autorização, Single Sign-On
(SSO) para domínios de serviço e federação de identidade para aplicações. Um sistema de
gestão de identidades visa realizar a tarefa complexa de lidar com as diversas tecnologias nos
domínios de segurança acima mencionados, e fornecer tecnologias de fácil utilização,
colocando o usuário final e suas necessidades diretamente no centro da arquitetura, enquanto
protege sua privacidade.
7.5.1 Visão Geral da Arquitetura do Keyrock
A Figura 7.4 apresenta a arquitetura de alto nível do Keyrock, a implementação de
referência do Identity Management GE. O Keyrock é formado por quatro componentes
principais, que oferecem um conjunto de APIs voltadas para o gerenciamento de diversos
aspectos, e uma API para fins de autenticação e autorização. A API de Gerenciamento de
Usuário (User Management API) fornece operações para criar contas de usuário, recuperar e
modificar atributos de usuário, excluir contas de usuário. A interface é compatível com API
SCIM 2.0. A API de Gerenciamento da Aplicação (Application Management API) fornece
operações para o gerenciamento de aplicações, tais como registro da aplicação, recuperar e
modificar dados da aplicação, por exemplo: credenciais e excluir a aplicação. A API de
Gerenciamento de Acesso (Access Management API) fornece operações para gerenciar
papéis globalmente ou para uma aplicação específica, definindo as permissões de papéis e
atribuindo os papéis para os usuários. As permissões de papéis formam uma política de
autorização que pode ser enviada para a Authorization PDP GE através da sua PAP API. A
API de Autenticação e Autorização (Authentication & Authorization) segue as
especificações dos padrões SAML 2.0 e OAuth2, oferecendo serviços de autenticação e
recuperação de atributos para autorização, suportando cenários de SSO (Single Sign-On) e de
Federação de Identidades.
Figura 7.4 - Identity Management GE - Arquitetura em alto-nível [13].
Este componente oferece dois portais de interação para usuários. O Portal de
Usuário Final (End User Portal) é utilizado pelos usuários finais para registrarem sua conta
pessoal no KeyRock, informando o endereço de e-mail, senha, etc. Isto normalmente é
implementado como uma interface de usuário Web (não fornecida pelo Keyrock). Os
usuários finais podem modificar ou configurar os seus dados da conta pessoal. Por outro lado,
o Portal de Desenvolvedor de Aplicações (Application Developer Portal), mostrado na
Figura 7.5, é utilizado pelos desenvolvedores para registrar e gerenciar as suas aplicações,
especialmente as aplicações do cliente, incluindo as credenciais de aplicação, permitindo o
aplicativo autenticar-se no IdM ou ainda definir os papéis de acessos específicos da
aplicação.
Figura 7.5 - Portal de Desenvolvedor de Aplicações (papéis e permissões)
7.5.2 APIs
O back-end do Keyrock é baseado no projeto Keystone do Openstack, por isso ele traz
consigo todas as APIs Keystone. Além disso, ele implementa algumas extensões
personalizadas que têm suas próprias APIs REST1.
Para gerenciar entidades que somente o Keyrock fornece, é necessário usar as
extensões personalizadas, com as APIs próprias, como citamos anteriormente. A seguir é
possível visualizar uma descrição das operações suportadas pelo conjunto de APIs fornecida
pela KeyRock:
● Consumidores (Consumers): Os consumidores são as aplicações registradas no
Keyrock a consumir recursos OAuth2. O componente que oferece esta API é o
Application Management API.
Tabela 2: REST API para acessar recursos das aplicaçõe
Operação Verbo HTTP
Descrição
1 https://github.com/ging/fiware-idm
/OS-OAUTH2/consumers
GET Lista as informações (id, descrição,
link, imagem, etc) das aplicações registradas no Keyrock.
/OS-OAUTH2/consumers POST Cria uma aplicação, passando na requisição o name, description, client_type, redirect_uris, grant_type e scopes.
/OS-OAUTH2/consumers/consumer_id GET Recupera os detalhes de uma aplicação específica.
/OS-OAUTH2/consumers/consumer_id PATCH
Modifica uma aplicação, passando na requisição o campo que será atualizado (field_to_update).
/OS-OAUTH2/consumers/consumer_id DELETE Deleta a aplicação especificada pelo parâmetro consumer_id.
● Papéis (Roles): o componente responsável pela API de papéis é o Access Management API.
Tabela 3: REST API para acessar recursos relacionados aos papéis
Operação Verbo HTTP
Descrição
/OS-ROLES/roles
GET Lista os papéis.
/OS-ROLES/roles POST Cria um novo papel.
/OS-ROLES/roles/role_id GET Recupera os detalhes de um papel específico.
/OS-ROLES/roles/role_id PATCH
Modifica um papel.
/OS-ROLES/roles/role_id DELETE Deleta o papel especificado pelo parâmetro role_id.
● Permissões (Permission): o componente Access Management API também será responsável pela API de permissões.
Tabela 4: REST API para acessar recursos relacionados as permissões
Operação Verbo HTTP
Descrição
/OS-ROLES/permissions
GET Lista as permissões.
/OS-ROLES/permissions POST Cria uma nova permissão.
/OS-ROLES/permissions/permission_id
GET Recupera os detalhes de uma permissão.
/OS-ROLES/permissions/permission_id
PATCH
Modifica uma permissão.
/OS-ROLES/permissions/permission_id
DELETE Deleta uma permissão.
● Relação Papel-Permissões (Role - Permission Relationship) Tabela 5: REST API para acessar recursos relacionados aos papéis e permissões
Operação Verbo HTTP
Descrição
/OS-
ROLES/roles/role_id/permissions
GET Lista as permissões associadas a um papel.
/OS-ROLES/roles/role_id/permissions/permission_id
PUT Atribui uma permissão a um papel.
/OS-ROLES/roles/role_id/permissions/permission_id
DELETE Remove uma permissão de um papel.
● Relação Papel-Usuário (Role - User Relationship) Tabela 6: REST API para acessar recursos relacionados aos papéis e usuários
Operação Verbo HTTP
Descrição
/OS-ROLES/users/role_assignments
GET Lista as atribuições de funções dos usuários.
/OS-ROLES/users/user_id/applications/ application_id/roles/role_id
PUT Atribui um papel a um usuário.
/OS-ROLES/users/user_id/applications/ application_id/roles/role_id
DELETE Remove um papel atribuído a um usuário.
● Relação Papel-Organização (Role - Organization Relationship) Tabela 7: REST API para acessar recursos relacionados aos papéis e organizações
Operação Verbo HTTP
Descrição
/OS-
ROLES/organizations/role_assignme
nts
GET Lista as atribuições de funções das organizações.
/OS-ROLES/organizations/organization_id/ applications/ application_id/roles/role_id
PUT Atribui um papel à uma organização.
/OS-ROLES/organizations/organization_id/applications/application_id/roles/role_id
DELETE Remove um papel atribuído à uma organização.
Outra API fornecida no Keyrock é a SCIM em sua versão 2.0. Esta API é
disponibilizada somente para administradores e pode ser usada para a gerência de dados de
usuários e organizações. é importante destacar que assim com as extensões do Keystone, esta
API é exposta pelo back-end e não pelo front-end. A seguir, descrevemos na Tabela 8 a
REST API para gerenciar os usuários e na Tabela 9 a REST API para gerência de
organizações.
Tabela 8: REST API para gerência dos usuários.
Operação Verbo HTTP
Descrição
/v3/OS-SCIM/v2/Users/ GET Lista usuários.
/v3/OS-SCIM/v2/Users/ POST Cria um usuário.
/v3/OS-SCIM/v2/Users/user_id GET Lê as informações de um usuário passando como parâmetro o user_id.
/v3/OS-SCIM/v2/Users/user_id PUT Modifica o registro de um usuários passando como parâmetro o user_id.
/v3/OS-SCIM/v2/Users/user_id DELETE Deleta o registro de um usuário passando como parâmetro o user_id que se deseja remover.
Tabela 9: REST API para gerência de organizações. Operação Verbo
HTTP Descrição
/v3/OS-SCIM/v2/Organizations GET Lista as organizações.
/v3/OS-SCIM/v2/Organizations POST Cria uma organização.
/v3/OS-SCIM/v2/Organizations/organization_id
GET Lê as informações sobre uma organização passando como parâmetro o organization_id.
/v3/OS-SCIM/v2/Organizations/organization_id
PUT Modifica o registro de uma organização passando como parâmetro o organization_id.
/v3/OS-SCIM/v2/Organizations/organization_id
DELETE Deleta o registro de uma organização passando como parâmetro o organization_id que se deseja remover.
7.5.3 Descrição do Exemplo da Aplicação
A fim de exemplificar a realização da autenticação da aplicação anteriormente
descrita com o OAuth2, são descritas abaixo as modificações realizadas sobre a aplicação
original, inicialmente sem autenticação, a fim de ilustrar o seu uso. Serão apresentados dois
cenários de autenticação. Em ambos os cenários, é necessário registrar a aplicação junto ao
Keyrock, de forma que a seção 7.5.3.1 demonstra os passos para tal. O primeiro cenário,
apresentado na seção 7.5.3.2, envolve o uso do Keyrock para a realização de autenticação
básica para uma aplicação Web. O segundo cenário, apresentado na seção 7.5.3.3, considera
que uma aplicação Web, necessita de serviços oferecidos por alguma GE Fiware, e para tal
envia um token de acesso junto com sua requisição.
7.5.3.1 Registrando uma Aplicação no Keyrock
O primeiro passo realizado a fim de implementar o processo de autenticação na aplicação, foi
efetuar o registro da aplicação no IdM.
Ao acessar o endereço do IdM e realizar o login é possível ver na tela inicial uma
listagem de aplicações cadastradas e a opção para cadastro de uma nova aplicação. Para
cadastrar uma nova aplicação deve-se clicar em "Register"no canto superior direito da janela
de aplicações, como mostra a Figura 7.6.
Figura 7.6 - Opção de registro de uma nova aplicação. O cadastro é dividido em três partes: o registro das informações da aplicação (nome,
descrição, etc), a seleção de uma imagem de exibição, e o cadastro dos papéis e permissões
associados a aplicação.
Após clicar em "Register", será exibida então uma nova página onde devem ser
inseridas as informações básicas da aplicação a ser registrada. Nessas informações estão o
nome, descrição e URL da aplicação criada, assim como a Callback URL, como vemos a
seguir na Figura 7.7. A Callback URL deve ser declarada na aplicação do usuário. Após
autenticação, o IdM redireciona a sessão de navegação para onde a Callback URL estará
indicando.
Figura 7.7 - Informações para registro da aplicação.
Após preencher essas informações, é possível selecionar uma imagem de exibição
para a aplicação, como mostra a Figura 7.8, e se necessário, cortá-la para melhor se adequar
ao tamanho de exibição.
Figura 7.8 - Seleção da imagem de exibição da aplicação. Por fim, podem ser modificados na página exibida na Figura 7.9, os papéis e
permissões associados a aplicação sendo criada. Existirão inicialmente duas possibilidades de
papéis: provedor e comprador. É possível editar as permissões de cada papel ou criar novos
papéis, clicando em "New role" e escrevendo o nome do novo papel, e depois clicando em
"Save". Também é possível adicionar novas permissões clicando em "New Permission". Será
necessário informar o nome da permissão, a descrição, o verbo HTTP (GET, PUT, POST,
DELETE) e o caminho para a permissão. Como o exemplo em questão não utiliza políticas
de controle de acesso, nenhum papel/permissão foi cadastrado.
Figura 7.9 - Configuração de papéis e permissões da aplicação. Depois desses passos, ao clicar em "Finish" a aplicação é criada e suas informações
(definidas pelo usuário) podem ser acessadas, como na Figura 7.10, ao clicar na aplicação na
tela inicial do IdM ou na sessão de aplicações. Nesta tela, também teremos um Client Id e
Client Secret gerados para acesso ao IdM pela aplicação. Esse Client Id e Client Secret serão
utilizados pela a aplicação no momento em que fizer requisições para o Keyrock.
Figura 7.10 - Informações da aplicação cadastrada.
7.5.3.2 Autenticação Básica para uma Aplicação
A primeira modificação realizada na aplicação foi referente a inserção de elementos de
segurança que permitissem o acesso de informações de um usuário somente após a realização
do processo de autenticação, conforme ilustrado na Figura 7.11.
Figura 7.11 - Modelo de arquitetura para requisição do Web App [19]
No processo exibido na Figura 7.11, ao acessar uma funcionalidade da aplicação web
que requer autenticação, o usuário é inicialmente redirecionado à tela de login no IdM. Uma
vez feito o login com as informações de acesso cadastradas nesse, é solicitada a confirmação
de autorização do usuário para a aplicação na qual ele deseja se autenticar. Uma vez que
tenha autorizado a aplicação, um access-code é gerado e retornado à aplicação. Em posse do
access code, a aplicação realiza uma nova requisição ao IdM para obter o access token, que o
retorna, fazendo com que possa ser inserido pela aplicação em chamadas posteriores.
Tendo sido registrada a aplicação, em seguida, no projeto da aplicação JSF (Java),
responsável pela interação com o usuário e comunicação com o Web Service REST, foram
implementados alguns passos para o seu correto funcionamento.
O primeiro deles foi referente à inserção de um botão para realização da autenticação
do usuário na interface, assim como um para a chamada à uma nova operação que acessa e
exibe as informações de um usuário autenticado. A nova tela é apresentada na Figura 7.12.
Figura 7.12 - Interface JSF para autenticação e requisição de informações do usuário
Na Figura 7.13 podemos visualizar como os componentes da aplicação JSF interagem
entre si. O SecurityAppMBeam está associado a interface do usuário, e receberá a requisição
feita quando o botão Authenticate for pressionado, redirecionando o usuário para se
autenticar no Keyrock.
Figura 7.13 - Arquitetura da aplicação JSF
O trecho de código responsável por fazer esse redirecionamento é exibido na Figura
7.14. Nele é realizada uma requisição HTTP GET ao endereço do IdM, no caminho
/oauth2/authorize, com os parâmetros response_type, client_id e redirect_uri definidos. O
parâmetro response_type deve ter o seu valor definido como “code” e o valor dos demais
parâmetros podem ser obtidos nas informações da aplicação registrada no IdM. O
access_code gerado será retornado como parâmetro GET em uma chamada ao endereço
definido no redirect_uri.
Figura 7.14 - Código para obtenção do access_code.
O endereço informado em redirect_uri aponta para um servlet (AuthServlet), que é
responsável por recuperar o access_code gerado pelo Keyrock. Este servlet é responsável
também pela obtenção do access_token junto ao Keyrock. O trecho de código responsável
pela obtenção do access_token no servlet definido é exibido na Figura 7.15.
Figura 7.15 - Código para obtenção do access_token.
Vemos então a realização da requisição HTTP POST feita ao IdM, no caminho
/oauth2/token. São definidos os cabeçalhos Authorization (com o valor formado por "Basic
"+ base64(client_id:client_secret)) e Content-Type (com o valor “application/x-www-form-
urlencoded”). Tendo sido definida a requisição com seus parâmetros e cabeçalhos, uma
conexão é aberta com o IdM e é realizada a requisição, obtendo o JSON de resposta que
contém o access_token. O token obtido é então acessado e armazenado na sessão da
aplicação, juntamente com o tempo para expiração do token, para que possam ser usados em
requisições de operações posteriores. Por fim é realizado um redirecionamento à página
inicial da aplicação.
Uma vez obtido o access_token, requisições podem ser realizadas ao IdM enviando
como parâmetro para confirmar a autenticação o token recebido, como a solicitação das
informações de um determinado usuário. Na aplicação JSF o trecho de código responsável
pela obtenção de informações do usuário autenticado após a obtenção do access token é o
apresentado na Figura 7.16. Em posse do token, uma requisição HTTP GET é realizada ao
endereço /user, passando o access_token obtido como parâmetro da requisição, recebendo
como resposta um JSON contendo as informações de acesso e permissões do usuário
autenticado com o token enviado.
Figura 7.16 - Código para obtenção do access_token.
7.5.3.2 Envio de Requisições a um Fiware GE
O processo para autenticação da aplicação e interação com um GE Fiware pode ser
ilustrado pela imagem abaixo, sendo a primeira etapa (do primeiro redirecionamento até a
obtenção do access_token) igual à descrita na seção anterior. Em seguida o token obtido é
enviado ao GE Fiware e inserido em chamadas posteriores realizadas por essa ao IdM, a fim
de confirmar a sua autenticação.
Figura 7.17 - Modelo de arquitetura para requisição do Web App com Serviço de GE Fiware [20].
O Keyrock é a implementação do Fiware Identity Management Generic Enabler,
escolhido como GE a ser utilizado no desenvolvimento da aplicação que descrevemos nesta
seção. Nosso objetivo é enviar requisições a esta GE para gerenciar os dados dos usuários
através da API SCIM 2.0. O IDM fornece vários mecanismos de autenticação. Qualquer um
deles é válido para acessar a API SCIM 2.0. O acesso à API SCIM 2.0 só é permitido para os
administradores, as tentativas de acesso realizadas pelos usuários que não são
administradores serão respondidas com HTTP 401 (não autorizado)2. Assim como extensões
Keystone, essas APIs são expostas pelo back-end. Por isso, foi necessário fazer as requisições
não mais ao Horizon (front-end do Keyrock), como fazíamos para requisitar o access_code e
access_token, mas sim ao Keystone (back-end), que responde pela porta 5000.
Para fazer as solicitações ao Keystone, é necessário um Token do próprio Keystone,
que é enviado no cabeçalho X-Auth-Token da requisição. É importante notar que este token
não é o mesmo que recebemos quando o usuário se autentica pelo Horizon. Esse token
Keystone pode ser obtido por meio de uma solicitação POST para o endpoint de autenticação.
Como um dos métodos de autenticação com suporte no Keystone é OAuth2, é possível usar o
token de acesso que obteve a autenticação OAuth2 para obter um token Keystone: POST /v3/auth/tokens body: "auth": {
"identity": { "methods": [ "oauth2" ],
2 http://docs.keyrock.apiary.io/#reference/scim-2.0
"oauth2": { 'access_token_id': access_token
} }
}
Agora é possível utilizar o token de Keystone para realizar solicitações à API SCIM
(ou a qualquer terminal da API para o qual o usuário autenticado tem permissões). O código
responsável por obter o Keystone token é mostrado abaixo:
Figura 7.18 - Código responsável por requisitar o Keystone token.
Com o Keystone token salvo, podemos fazer a requisição as informações dos usuários:
Figura 7.19 - Código responsável por requisitar a lista de usuários.
7.6 Descrição dos Componentes de Autorização (PEP Proxy GE e Authorization PDP
GE)
Nesta seção, trabalharemos apenas com as GEs responsáveis pela parte de
autorização, são PEP Proxy GE e Authorization PDP GE, já que estes habilitadores genéricos
estão altamente interligados em suas funcionalidades, por se preocuparem com o tratamento
das solicitações e permissões de acesso.
7.6.1. Conceitos Básicos sobre Controle de Acesso
A seguir, conceituaremos alguns termos fundamentais de controle de acesso, que
servirão como base para este estudo do capítulo de segurança do Fiware de forma em geral, e
mais especificamente para as GEs desta seção.
O AuthZForce fornece um modelo de controle de acesso baseado em atributo (ABAC
- Attribute-Based Access Control), uma evolução do modelo de acesso baseado em papéis
(RBAC - Role-Based Access Control). Em seguida, conceituamos os elementos principais
desses modelos.
● Recurso (Resource): Entidade a ser protegida contra uso não autorizado. Ex.:
dispositivos, arquivos, registros, tabelas, processos, programas, redes ou domínios que
contenham ou recebam informações.
● Sujeito (Subject): O sujeito é um ator representando um usuário de um recurso. O
sujeito pode ser uma pessoa, um programa, um dispositivo ou outro elemento que
solicite acesso a um recurso.
● Ação (Action): Uma ação corresponde a uma função que pode ser realizada sobre
sobre um recurso. Ex.: ler, escrever, editar, apagar, copiar, executar e modificar.
● Permissão (Permission): É uma aprovação para a execução de uma ação em
particular em um recurso.
● Papel (Role): Estabelece permissões baseadas nos papéis funcionais na empresa,
atribuindo usuários para um papel ou conjunto de papéis. Pode representar tarefas,
responsabilidades e qualificações associadas com uma empresa.
● Atributos (Attributes): Características do sujeito, recurso ou condições ambiente.
Atributos contêm informações dadas por um par “nome-valor”.
● Atributos do sujeito (Subject attributes): Os atributos de um sujeito corresponde à
suas propriedades, como por exemplo o ID de usuário, organização, papel, nível de
acesso.
● Atributos de recurso (Resource attributes): O recurso é uma entidade passiva que o
sujeito solicita agir sobre este. Este recurso pode ser, por exemplo: dados, pessoa,
dispositivo ou aplicação. Atributos de recurso são ID de recurso, URL, classificação,
por exemplo.
● Atributos de ação (Action attributes): Uma ação representa a operação que um
sujeito solicita executar sobre um recurso. Ações podem ser criar, ler, escrever,
deletar. Atributos de ação são ID de ação, parâmetro A, parâmetro B e entre outros.
● Atributos de ambiente (Environment attributes): Contexto operacional ou
situacional em que ocorrem as solicitações de acesso. Ex.: a hora atual, dia da semana,
a localização de um usuário, a carga da CPU do PEP / PDP, o nível de ameaça atual e
temperatura.
● Política (Policy): representação de regras ou relações que torna possível determinar se
um acesso solicitado deve ser permitido, levando em consideração os valores dos
atributos do sujeito, do recurso e das condições ambiente possivelmente.
● Controle de Acesso Baseado em Papel (Role Based Access Control - RBAC):
Método de controle de acesso baseado em papéis que restringe o acesso ao recurso
somente aos sujeitos autorizados, através da análise dos papéis que o sujeito exerce na
organização ou empresa. Permissões são atribuídas a papéis, enquanto que papéis são
atribuídos a sujeitos. As atribuições de papéis podem ser realizadas para um sujeito ou
para grupos.
● Controle de Acesso Baseado em Atributo (Attribute Based Access Control -
ABAC): Método de controle de acesso onde o sujeito solicita a execução de operações
em recursos, que são concedidos ou negados com base em atributos atribuídos ao
sujeito, atributos atribuídos ao recurso, condições ambientais e um conjunto de
políticas que são especificados no termos desses atributos e condições.
O modelo ABAC define um conjunto de componentes funcionais, que capturam os papéis
envolvidos em um mecanismo de autorização, que serão apresentados em seguida.
Figura 7.20 - Exemplo de Pontos Funcionais de Autorização [14]
A relação entre os diversos componentes do modelo ABAC é apresentado na Figura
7.20, onde temos um sujeito (subject) que solicita acesso a um recurso protegido (object). A
requisição de acesso é interceptada pelo PEP (Policy Enforcement Point), que é responsável
por aplicar as decisões de política acesso, permitindo ou negando acesso ao sujeito. Decisão
de acesso são feitas pelo PDP (Policy Decision Point - PDP), que calcula a decisão de
acesso de acordo com as políticas de segurança que são armazenadas em um repositório. Para
isso, o PDP comunica-se com o PIP (Policy Information Point - PIP) que serve como fonte
de recuperação de atributos necessários para a avaliação das políticas de modo a fornecer a
informação necessária para o PDP tomar as decisões. O PAP (Policy Administration Point -
PAP) fornece uma interface de usuário para criar, testar e depurar as políticas, permite a um
administrador gerenciar as políticas do repositório. Uma vez que uma decisão é tomada, o
PDP manda uma resposta ao PEP permitindo ou negando o acesso ao recurso, e este, por
último, irá autorizar ou negar o acesso ao sujeito como decidido pelo PDP.
7.6.2 Visão Geral da Arquitetura do Authorization PDP GE e PEP Proxy GE
Nesta seção detalhamos a arquitetura das GEs Authorization PDP e PEP Proxy, cuja
implementações de referência são, respectivamente, o AuthZForce e Wilma.
O AuthZForce fornece uma API para obter decisões de autorização com base em
políticas de autorização e os pedidos de autorização de PEPs, esta API segue o estilo de
arquitetura REST e está em conformidade com XACML na versão 3.0. Esta GE fornece duas
características principais:
1. Avaliação de decisão de políticas de autorização: Sua principal característica
consiste em avaliar as decisões de autorização com base em políticas e atributos
relacionados a uma requisição de acesso dada, por exemplo, identidade do solicitante,
recurso solicitado e ação solicitada, seguindo a lógica de avaliação da política
definida no padrão XACML.
2. Administração de políticas de autorização: utilizado para a criação, recuperação,
atualização e remoção de políticas XACML. Este recurso é fornecido para clientes
externos através de uma API REST denominada PAP (Policy Administration Point).
Estas características são implementadas pelo AuthZForce através das APIs PDP e
PAP, baseado nos componentes do modelo ABAC. A API PDP oferece serviços para a
tomada de decisão de autorização computadas por um mecanismo de controle de acesso
compatível com XACML (XACML-compliant), enquanto que a API PAP permite o
gerenciamento das políticas XACML que serão consideradas pelos serviços da API PDP.
A API PDP pode ser utilizada por qualquer implementação de PEP que siga a
especificação XACML para solicitar uma decisão de autorização do mecanismo de avaliação
de políticas. O PEP envia uma solicitação HTTP POST para a API com uma requisição
XACML como corpo da solicitação. Este pedido deve conter todos os atributos de
autorização necessários, referidos na política aplicada, para o PDP para ser capaz de avaliar
esta política. O PDP retorna uma resposta XACML que contém a permissão ou negação da
decisão. Ele também pode retornar Indeterminate se ocorreu um erro durante a avaliação, por
exemplo, se algum atributo estava faltando. É possível também definir a política de forma
que o PDP retorne Deny em vez de Indeterminate se ocorrer um erro deste tipo, para evitar
qualquer problema no lado do PEP.
A API PAP é utilizada pela Identity Management GE para gerenciar as políticas de
acesso, definidas por desenvolvedores para suas aplicações através da interface Web do
Keyrock. Esta API também pode ser utilizada diretamente por qualquer cliente de
administração de política, que por ventura venha ser desenvolvido especificamente para tratar
de aspectos específicos da política de controle de acesso que o portal do IdM GE não atenda.
Por outro lado, o PEP Proxy Wilma, atua como ponto de aplicação de decisões. Este
GE é um componente de back-end, sem interface de front-end, que permite proteger o acesso
a serviços e aplicativos, adicionando filtros de autenticação e autorização para GEs do Fiware
e para qualquer serviço de back-end. Em suma, o PEP Proxy é capaz de interceptar cada
solicitação de acesso para um serviço e executar o fluxo de autenticação e autorização. No
PEP Proxy GE, o recurso protegido é um serviço REST, para o qual a GE desempenha o
papel de proxy reverso e é implantado como tal. Nesta configuração, é fundamental que
qualquer requisição de acesso passe através do PEP Proxy antes de chegar ao serviço
protegido.
Figura 7.21 - Authorization PDP -Visão geral da arquitetura [15]
A Figura 7.21 mostra como os componente AuthZForce e Wilma interagem para
garantir controle de acesso. Quando um usuário (Access Requester) deseja acessar um
determinado serviço, ele precisa se autenticar junto ao Identity Management GE, que retorna
um token de acesso (passo 1). Quando o PEP Proxy GE recebe uma requisição (passo 2), ele
recupera o token de autenticação do cabeçalho específico e valida-o com Identity
Management GE (passo 3), obtendo também informações acerca do usuário. Após a
autenticação, o PEP Proxy interage com o Authorization PDP GE para realizar a autorização
(passo 4). O PEP Proxy envia ao Authorization PDP as informações do usuário (ex: Id de
usuário, papel, atributos) e da requisição (ex: recurso a ser acessado, ação). Baseado nas
políticas de segurança configuradas o Authorization PDP toma uma decisão acerca de
permitir ou negar o acesso. Caso o acesso seja permitido, o PEP Proxy GE então encaminha a
requisição para o serviço (passo 5).
Conforme apresentado na Figura 7.21, o Identity Management GE (Keyrock) interage
com a API PAP do Authorization PDP para o gerenciamento de políticas de acesso. Com
isso, um desenvolvedor é capaz de definir sua política de acesso utilizando o Portal de
Desenvolvedor de Aplicações do Keyrock, de forma que não é necessário ter conhecimentos
na linguagem XACML para a definição de políticas de acesso usando componentes Fiware.
7.6.3 Representando Políticas de Controle de Acesso usando XACML
XACML (eXtensible Access Control Markup Language) é uma linguagem de política
de controle de acesso padronizada pela OASIS que implementa o ABAC (Attribute-Based
Access Control ou Controle de Acesso Baseado em Atributos). Por ser um padrão aberto, a
linguagem traz diversos benefícios, tais como suporte de múltiplos fornecedores,
interoperabilidade entre plataformas e implementações, e um comitê que trabalha de forma
transparente para manter em linha o padrão com as crescentes demandas da indústria. A
primeira versão do XACML foi disponibilizada em 2003 (v1.0), e atualmente a mesma
encontra-se na versão 3.0 (disponibilizada em 2013).
O XACML pode ser sumarizado em 3 pontos principais:
● Domínio (Domain): A aplicação permite a criação de múltiplos domínios, estes são
instâncias para utilizar as políticas de autorização de forma independentes, permitindo
a definição de políticas para aplicações distintas, ou para uma organização.
● Linguagem para definição de politicas (Policy language): XACML (eXtensible
Access Control Markup Language) define um modelo de dados XML para a
definição de políticas de autorização, bem como a lógica a seguir para avaliá-las em
um contexto de solicitação de acesso. O XACML é estruturado principalmente nos
seguintes elemento: Regra, Política (conjunto de regras) e “PolicySet” (conjunto de
elementos de política). A Política, a “PolicySet”, combina várias regras ou políticas e,
portanto, várias decisões juntas de várias maneiras, que são definidas na norma, para
tomar a decisão final.
● Protocolo de Requisição-Resposta (Request-Response protocol): O padrão XACML
também define um modelo de dados XML para a solicitação de decisão de
autorização (XACML Request) que um PEP cria com todos os atributos solicitados de
acesso necessários e envia para o API PDP para avaliação e a resposta resultante
(XACML Response), que contém a decisão final (permitir ou negar).
Mais detalhes sobre a linguagem podem ser encontrados em sua especificação3.
7.6.3. APIs
Nesta seção, apresentaremos uma descrição das APIs PAP oferecidas pelo
AuthZForce, que são aqueles APIs utilizadas por desenvolvedores interessados em manipular
políticas de acesso. É importante mencionar que as políticas de acesso podem ser
manipuladas pela interface Web oferecida pelo Keyrock, que utiliza-se das APIs que serão
apresentadas em seguida.
7.6.3.1. APIs para Administração de domínio de política
O AuthZForce pode ser utilizado para decisões de acesso de múltiplas
instâncias/domínios, permitindo que os usuários ou organizações utilizem as políticas de
autorização de forma que estejam completamente isoladas. Existem quatro operações
principais para a manipulação de domínio de política, que são criação, listagem, edição e
remoção de domínios de administração de política.
Tabela 10 - Tabela de Verbos HTTP para manipulação de domínio.
Operação Verbo HTTP
Cabeçalho Descrição
/domains POST Content-Type: application/xml; charset=UTF-8;
Accept: application/xml;
Adiciona domínio.
/domains/{domainId}/properties
PUT Content-Type: application/xml; charset=UTF-8;
Accept: application/xml; charset=UTF-8;
Atualiza propriedades do domínio.
3 https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html
/domains/{domainId}/properties
GET Accept: application/xml; charset=UTF-8;
Obtém uma lista dos domínios existentes.
/domains/{domain_ID} DELETE Content-Type: application/xml; charset=UTF-8;
Accept: application/xml
Deleta domínio.
7.6.3.2. API para Administração de Política
A API para Administração de Política, chamada de PAP, é utilizada por
administradores de política para gerenciar o repositório de políticas a partir da qual o PDP
API carrega as políticas aplicadas. Também, importante saber que o PAP suporta múltiplas
instâncias na forma de domínios de administração genérico que são separados uns dos outros.
Cada administrador de política, exceto o super administrador, é de fato um administrador de
domínio, na medida em que ele está autorizado a administrar a política para um ou mais
domínios específicos. E assim, os domínios são normalmente utilizados para auxiliar no
isolamento de instâncias, deixando um domínio por instância.
As operações utilizadas para manipular as políticas de um domínio são chamadas de
Adding, Updating, Getting e Deleting no inglês, mas traduzindo-as ficariam: adicionando,
atualizando, listando e deletando.
Tabela 11 - Tabela de Verbos HTTP para manipulação de políticas de domínio.
Operação Verbo HTTP
Cabeçalho Descrição
/domains/{domainId}/pap/policies
POST Content-Type: application/xml; charset=UTF-8
Accept: application/xml; charset=UTF-8
Adiciona e atualiza políticas a um domínio.
No corpo é enviado um conjunto de Políticas XACML como definido no esquema XACML3.0
- /domains/{domainId}/pap/policies/{policyId}
- /domains/{domainId}/pap/policies/{policyId}/{version}
- /domains/{domainId}/pap/policies
GET Accept: application/xml; charset=UTF-8
Obtém uma ou mais políticas, ou, ainda, as versões de políticas de um domínio.
- /domains/{domainId}/pap/policies/{policyId}
- /domains/{domainId}/pap/policies/{policyId}/{version}
DELETE
Accept: application/xml; charset=UTF-8
Deleta políticas ou todas as versões de uma política
7.6.4 Cenários de Uso
Nesta seção apresentaremos a evolução da aplicação de exemplo, que inicialmente
possuía apenas a Autenticação do Keyrock, para demonstrarmos a utilização dos
componentes de autorização da plataforma Fiware. Inicialmente explicaremos detalhes da
implementação necessária para adicionarmos a autorização básica com o PEP, e em seguida a
autorização básica com o PEP e PDP.
7.6.6.1 Autenticação com PEP
No primeiro nível, detalharemos o passo a passo somente da autenticação, utilizando
contas Fiware para os usuários e aplicações, neste nível, trabalharemos com IdM GE e PEP
Proxy GE.
Figura 7.22 - PEP Proxy - Nível 1: Autenticação [16]
De acordo com a Figura 7.22 exibida acima, após a autenticação do cliente com sua
conta Fiware, a aplicação de front-end (Web App) recebe um token de acesso (access_token).
Em seguida, ela realiza uma requisição ao PEP anexando o token de acesso. Para que essa
requisição ocorra, é necessário que o PEP seja registrado no Keyrock, junto a conta da
aplicação cliente, permitindo que as credenciais do PEP sejam geradas e a aplicação possa
utilizá-las para realizar as solicitações de acesso aos serviços back-end.
A solicitação REST (request) feita pelo front-end (Web APP) ao PEP, para acesso ao
serviço back-end (Back-end Apps), conterá um token OAuth2 (access-token) do usuário.
Esse access-token será enviado ao Fiware Account para ser validado. O Fiware Account
retornará o resultado da validação, e no caso do access-token ser válido, as informações do
usuários serão retornadas juntamente com o resultado da validação. Por fim, o Pep Proxy
poderá liberar o acesso ao serviço back-end.
Na Figura 7.23 vemos a tela de apresentação da aplicação cadastrada no Fiware, e na
seção PEP Proxy o botão ‘Register a new PEP Proxy’, que ao ser selecionado registra as
credenciais do PEP a aplicação.
Figura 7.23 - Tela de apresentação das informações da aplicação.
É necessário registrar as credenciais do PEP, pois elas não são cadastradas
automaticamente com a criação da aplicação. Depois do registro podemos ter acesso a elas,
como vemos na figura 7.24.
Figura 7.24 - Apresentação da aplicação e das credenciais PEP Proxy.
Outra configuração importante para o PEP são os dados contidos no configuração
config.js, onde devemos indicar as credenciais do PEP gerados pelo Fiware, o endpoint do
idm e do serviço Back-end, para onde o PEP vai redirecionar a requisição caso o
access_token recebido seja válido. Na Figura 7.25 vemos um exemplo de informações no
config.js.
Figura 7.25 – Método que envia a requisição ao Web Service
Do ponto de vista da implementação, devemos alterar todas as referências existentes ao
endereço do serviço back-end, para o endereço do PEP, o acesso ao back-end será visível
somente para o PEP.
O código responsável por realizar as requisições é mostrado na Figura 7.26. Nele,
vemos o HTTP Header: X-Auth-Token com o access token obtido do Keyrock.
Figura 7.26 - Método que envia a requisição ao Web Service
Quando o PEP Proxy recebe a solicitação, ele extrai o token do cabeçalho HTTP e
envia uma solicitação para o Servidor de Contas do Fiware (IdM GE) para validá-lo, como
explicamos anteriormente. Lembre-se que a URL do servidor é definida no campo
"account_host" do arquivo de configuração. Se o token é válido, o PEP redireciona a
solicitação para o serviço back-end configurado no "app_host" e "app_port" do arquivo de
configuração.
7.6.6.2 Autorização Básica com PEP e PDP
O segundo nível utilizará uma autorização básica, isto é, além de realizar a parte de
autenticação, trabalha com configuração dos papéis e das permissões para um usuário do
aplicativo, através do uso do IdM GE, PEP Proxy GE e Authorization PDP.
Figura 7.27 - PEP Proxy - Nível 2: Autorização Básica [16]
Na figura 7.27, observamos que o nível 2 ocorre de forma semelhante ao nível 1, mas
com a adição de alguns parâmetros que também serão analisados pela GE discutida. Logo,
nesse nível 2, o primeiro passo é a criação de usuário e aplicativo na conta do Fiware, mas
além disso, também configurar os papéis e permissões para esse usuário que terá no
aplicativo.
O PEP Proxy irá verificar se o access_token é de um usuário autenticado numa conta
Fiware, caso afirmativo, o PEP receberá uma resposta com as informações do usuário, nestas
informações está incluída a lista de papéis que o usuário tem para esta aplicação. Além disso,
o PEP Proxy interage com o Authorization PDP para saber se o usuário possui permissão ao
recurso (Back-end Apps) utilizando informações como os papéis do usuário, HTTP Verb e o
caminho do recurso.
Para que esta interação entre PEP e PDP ocorra, não é necessário registro do PDP no
Keyrock, porém o processo de configuração feito na aplicação anterior descrita na seção
7.6.6.1 é necessario, tendo que registrar a aplicaçao back-end no arquivo de configuraçoes
config.js. Também é necessário a associação dos usuários com determinadas Roles e
Permissions, como mostramos na Figura 7.9. Os papéis e políticas de cada usuários são
recuperadas pelo PDP quando o PEP é requisitado e recebe o token do usuário que está
solicitando um determinado serviço do back-end.
Além disso, é necessário editar o arquivo de configurações do PEP para liberar a
utilização do PDP, como mostramos na figura a seguir:
Figura 7.28 - Arquivo de configurações do PEP.
Para que o PDP seja utilizado, basta atribuir ‘true’ a enable, identificar o endereço
onde o AuthZForce está sendo executado, a sua porta, e a política.
Na Figura 7.29 podemos ver a arquitetura da aplicação de exemplo após a adição do
do PEP Proxy e do PDP. O PEP Proxy passa a ser uma camada de proteção para os serviços
oferecidos pelo back-end, e se comunica com o Keyrock, para a validação do access_token
enviado pelo front-end, e com o PDP, passando os papéis, o verbo HTTP e o path do recurso
que se deseja acessar para verificar a autorização do usuário a este recurso.
Figura 7.29 - Arquitetura da aplicação com o PEP Proxy e o PDP.
Durante os testes recebemos um erro do AuthZForce que nos notificou da falta de
domínio para a aplicação que desejávamos acessar. Após pesquisarmos soluções,encontramos
o registro de um erro similar causado por um bug no Keyrock.
7.7 Descrição do CyberSecurity
O CyberSecurity GE é um componente com foco na detecção e resposta a incidentes
de segurança. Este componente oferece mecanismos que tratam desde a análise de riscos até a
sugestão de possíveis respostas que permitam mitigar esse risco, tendo como público-alvo
organizações que desejam detectar e gerenciar risco de segurança em sistemas e aplicações,
como por exemplo, mantenedores de infraestrutura Fiware, e desenvolvedores de aplicações
baseada na plataforma Fiware.
A proposta do Cyber Security GE engloba (1) Coletar vulnerabilidades e avaliar
ameaças potenciais; (2) Identificar ataques mais prováveis e de maior impacto; (3) Avaliar
riscos e propor soluções de remediação; (4) Entregar um serviço de visualização centralizado
em nível de risco e custo; e (5) Prover recursos de compartilhamento de dados críticos que
preservem a privacidade da organização. De forma a atingir esses objetivos, a arquitetura do
CyberSecurity GE engloba um conjunto de componentes que atuam em conjunto com um
SIEM.
Figura 7.30 - Componentes de desenvolvimento e interações com Cyber Security GE [17].
O CyberSecurity GE trabalha em conjunto com outros componentes de segurança,
incluindo elementos de infraestrutura (tais como firewalls, roteadores e switches) e elementos
de controle de acesso (como o IdM KeyRock e o PDP AuthZForce do Fiware). Esses
componentes são monitorados através de um SIEM, através de probes.
O Cyber Data Extraction é o componente responsável por extrair e processar os
dados relevantes fornecidos pelo usuário sobre seu sistema: topologia de rede, regras de
firewall, resultados de analisadores de vulnerabilidades, etc. A saída deste componente é
utilizada como entrada pelos componentes Scored Attack Path e Remediation. Dois tipos de
dados são utilizados: O relatório de um analisador de vulnerabilidades (como por exemplo o
Nessus) e um arquivo descrevendo a topologia do sistema. Este XML descreve computadores
e suas interfaces de rede, endereços IP, VLAN, serviços de rede, firewall e configuração de
roteamento. Este arquivo pode ser gerado automaticamente a partir de ferramentas de
gerenciamento disponíveis. Para dar informações sobre vulnerabilidades e a topologia para
outros componentes, duas formas de saída podem ser geradas. A primeira é a informação
necessária para que o MulVAL Attack Graph Engine gere o grafo de ataque. Esse arquivo
contém tanto os dados sobre vulnerabilidades quanto sobre a topologia. O segundo arquivo é
gerado como um XML, necessário para a aplicação de remediação.
O componente MulVAL Attack Graph Engine é um analisador topológico de
vulnerabilidades capaz de gerar, a partir da saída do Cyber Data Extraction, os possíveis
caminhos utilizados por ataques. Esta engine combina os conceitos de grafo de ataque4 com
CVSS (Common Vulnerability Score System) para prover uma analise qualitativa e
quantitativa de vulnerabilidades individuais. As interações entre múltiplos elementos de redes
devem ser considerados para determinar o impacto na segurança que as vulnerabilidades em
software possuem para um determinada rede. Desse modo, o MulVAL analisa: Quais
vulnerabilidades foram reportadas e se elas existem em meus servidores; Quais softwares e
serviços estão rodando em meus servidores e como eles estão configurados; Como meus
roteadores e firewalls estão configurados; Quem são os usuários da minha rede; Como esses
componentes interagem; e Quais acessos eu devo permitir. O MulVAL cria grafos lógicos
que apresentam os caminhos de ataque, passando pelas regras de segurança, dispositivos e
serviços de rede. Os administradores de redes podem definir suas preferências de pontuação.
Baseado no grafo de ataque o componente Scored Attack Paths analisa as principais
vias de ataque e computa uma pontuação para cada um dos caminhos de acordo com seu
impacto no negócio e probabilidade de ocorrência. Basicamente, define o nível de risco
associado com cada caminho possível em um grafo de ataque.
O componente Remediation Engine ajuda a mitigar os riscos e toma ações efetivas
de acordo com as políticas de segurança, computando diferentes formas de quebrar as vias de
ataque, estimando o custo de cada uma. Desta forma, o administrador de rede pode selecionar
o caminho de rede e verificar as alternativas de remediação. Para computar remediações, um
banco de remediações é necessário. Este banco faz a conexão entre as vulnerabilidades e uma
possível remediação. Diversos tipos de remediação podem ser utilizados, tais como correções
de configuração, e aplicação de patches em software. Outros tipos de remediações não podem
ser armazenados em um banco de dados, pois elas dependem de remediações em nível de
rede, como regras de firewall, mudança de regra de roteamento. Para isso, o Remediation
Engine necessita de uma simulação da topologia da rede. A lista de remediações apresenta o
custo estimado, operacional e impacto. Existe também a possibilita de remediação
automática, utilizando aprendizagem de máquina. Utilizando respostas análogas as tomadas
por administradores em caminhos de ataques parecidos.
4 http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Fiware.OpenSpecification.Security.CyberSecurity
O componente Visualization interface provê uma interface Web para o
administrador de rede para que ele possa interagir com os componentes, analisando
dinamicamente os riscos do sistema. O administrador pode utilizar a ferramenta para
visualizar os possíveis caminhos de ataques, ver o nível do risco e as opções de remediações
para resolvê-las.
O componente Privacy-Presenting Data Sharing possibilita que uma organização
possa compartilhar dados relativos a um ataque bem sucedido com grande impacto de
negócio com outros, sem expor informações confidenciais. As funcionalidades do Cyber
Security possibilita que a organização compreenda sua situação e reaja de forma apropriada,
particularmente durante fases críticas. Nessas fases pode ser crucial compartilhar informações
com instituições privadas ou companhias de consultoria. Privacy-Preserving Data Sharing
possibilita que essas informações sejam compartilhadas sem expor dados confidenciais e
críticos da organização. Isso é conseguido através dos princípios de Multi-Party
Computation, uma técnica baseada em criptografia onde entidades diferentes são capazes de
operar em um conjunto de informações com garantias de privacidade.
A implementação de referência do Cyber Security GE pode ser encontrada no
catálogo de GEs Fiware. Entretanto, a mesma está classificada como deprecated, tendo sua
última atualização em 02/02/2016.
7.8 Descrição do Trustworthy Factory GE
Há muita vulnerabilidade em sistemas disponibilizados na internet devido a malware,
spyware, hackers e falhas de segurança todos os dias, mas a maioria dessas vulnerabilidades
hoje são as vulnerabilidades dos aplicativos. Embora a confiança de um sistema seja algo
subjetivo, confiabilidade de um sistema pode ser medido de acordo com indicadores
quantificados. Portanto, foi desenvolvida a Trustworthy Factory GE para fornecer um
ambiente para desenvolver aplicativos confiáveis e para ajudar a sua certificação com base na
avaliação dos atributos de qualidade de software (baseado na ISO 25010). O ponto de partida
para esta GE é uma lista de objetivos de confiabilidade (trustworthiness profile).
A maioria dos habilitadores genéricos do Fiware fornece funções comuns que podem
ser integradas dentro de novas aplicações e efetivamente utilizadas em tempo de execução, ou
seja, quando o aplicativo é executado. Já a Trustworthy Factory GE não presta este tipo de
função comum no momento de execução do aplicativo, mas sim uma função comum para o
desenvolvimento de novas aplicações Java confiáveis e, portanto, utilizada principalmente
durante a fase de desenvolvimento.
A Trustworthy Factory GE consiste em duas características principais:
● Static and Dynamic Application Trustworthiness Assessment: Este recurso
oferece um ambiente de desenvolvimento que auxilia um desenvolvedor a
escrever código-fonte Java com melhor qualidade, considerando aspectos de
projeto e melhores práticas. Além disso, outras ferramentas podem ser
utilizadas de forma a oferecer uma avaliação intermediária da confiabilidade
para os desenvolvedores. Com isso, desenvolvedores são capazes de consultar
o objetivo de confiabilidade dado como entrada pelo provedor de software e
compará-lo com uma avaliação atual.
● Semi-automated Workflow for Application Trustworthiness
Certification: Este recurso é usada pelo avaliador para preparar a fase de
certificação. Ele possui como entrada o código fonte da aplicação e diferentes
informações fornecidas pelo desenvolvedor de software, tais como contexto da
aplicação e o objetivo de confiabilidade). Um conjunto de ferramentas,
integradas de acordo com um workflow, auxiliam o avaliador a compreender o
contexto da aplicação, redefinir ou adicionar novos objetivos de
confiabilidade, além de avaliar os atributos de confiabilidade de uma aplicação
em relação a estes objetivos. Com isso, o avaliador é capaz de quantificar o
nível de confiabilidade de um aplicativo. Os resultados deste trabalho são
armazenadas em um arquivo XML, assinado pelo avaliador, chamado "Digital
Trustworthiness Certificate (DTwC)" e este arquivo será usado pela
certificadora para certificar a aplicação.
Figura 7.31 - Contexto de fabricação de confiança [18].
Uma visão geral deste processo é apresentado na Figura 7.8.1. O ambiente de
desenvolvimento consiste na IDE Eclipse com um conjunto de plugins, apresentando visões
diferentes para o desenvolvedor e o avaliador. Um conjunto de plugins foram adicionados a
fim de combinar, agregar, fundir e transformar os resultados gerados por diversas ferramentas
de avaliação de código-fonte com um ponto de vista de confiabilidade. Uma vez pronta, a
aplicação passa por uma ferramenta de certificação, onde um avaliador verificar se o
aplicativo é compatível com os requisitos de confiabilidade especificadas como entrada.
O processo de certificação consiste em cinco etapas:
1. System description: Esta etapa consiste em declarar os diferentes componentes do
sistema e identificar qual componente está sob avaliação.
2. Trustworthiness Problem definition: Esta segunda etapa, define os problemas que
poderiam impactar um componente da aplicação. A lista de problemas é uma lista
predefinida, classificados por tipo. O avaliador seleciona um componente e verifica os
possíveis problemas que podem ocorrer neste recurso.
3. Trustworthiness Property Specification: Além do perfil de confiabilidade, ou seja,
a lista de objetivos, inicialmente passado para o desenvolvedor, o avaliador pode
associar atributos de confiabilidade extra para componentes específicos do aplicativo
e definir métricas diferentes para cada um.
4. Evidence collection: Esta etapa permite ao avaliador recolher as provas para calcular
as diferentes métricas e o valor para cada atributo de confiabilidade. A coleção pode
ser feito automaticamente usando ferramentas diferentes, exemplo análise estática e
em tempo de execução, ou podem ser recolhidos manualmente, no caso de algumas
provas serem fornecidas manualmente, por exemplo, os resultados de testes.
5. DTwC (Digital Trustworthiness Certificate) creation and editing: Este passo é
usado para validar a geração do certificado. Todos os dados necessários são
verificados e validados, a fim de gerar um certificado completo. Esta visão mostra o
caminho em que o certificado está e onde componente deve ter sido gerado, isto é, o
seu caminho físico ou URL de mercado.
A implementação de referência do Trustworthy Factory GE pode ser encontrada no
catálogo de GEs Fiware. Semelhantemente a CyberSecurity GE, está classificada como
deprecated, tendo sua última atualização em 02/02/2016.
7.9 Considerações Finais Neste capítulo de Segurança desenvolvemos um estudo detalhado da sua arquitetura,
trabalhando com os cinco habilitadores genéricos: Identity Management GE, Authorization
PDP GE, PEP Proxy GE, Cyber Security GE e Trustworthy Factory GE. Apesar de ter
trabalhado com todos eles, uma maior ênfase foi dada à área temática de Gerenciamento de
Identidade e Acesso, tendo um maior detalhamento sobre estes três primeiros GEs com suas
respectivas implementações de referência: KeyRock, AuthZForce e Wilma. Vale salientar
que os outros dois GEs estão classificadas como deprecated desde fevereiro do ano presente.
Também apresentamos uma aplicação como estudo de caso para a apresentação dos
GEs de Segurança, sendo esta formada por um componente back-end (definindo um
webservice REST) e um componente front-end (correspondente a uma aplicação Web para
interação com o usuário que realiza chamadas aos serviços definidos) que puderam ser
utilizados de forma a experimentar a integração dos GEs apresentados com seus
componentes. 7.9.1 Problemas Encontrados Surgiram diversos problemas durante o estudo do Capítulo de Segurança da
plataforma Fiware. Um dos problemas diz respeito ao acesso à um GE utilizado um token de
autenticação. Foi desenvolvido um cliente Web para acessar o Repository GE,
disponibilizado pelo capítulo técnico de aplicações (Applications, Services and Data
Delivery) após autenticação do usuário junto ao Keyrock. Entretanto, embora o token de
autenticação tenha sido obtido com sucesso, o mesmo não era aceito pelo GE. Uma tentativa
de identificar a causa do problema foi iniciada, mas não tivemos tempo hábil para um estudo
aprofundado do Repository GE e seus mecanismos de autenticação junto ao Keyrock.
Outro problema ocorreu quando tentamos acessar a API de gerência de usuários do
Keyrock. Inicialmente, quando tentamos acessar a API enviando o token recebido após a
autenticação pelo Horizon obtivemos a resposta de token não autorizado. Uma primeira
solução foi recuperar o token admin do Keystone, e depois acessar os recursos do back-end
do Keyrock. Depois de compartilharmos o problema no fórum stackoverflow5 conseguimos
5 http://stackoverflow.com/questions/39962726/access-scim-api-keyrock-fiware/40127254#40127254
uma segunda solução, que foi requisitar um token válido para o Keystone utilizado o token de
acesso recebido através da autenticação por oauth.
Por fim, quando estávamos implementando a autorização com o PDP, surgiu uma
notificação feita pelo AuthZForce sobre a falta de domínio para a aplicação que estávamos
tentando acessar. Tentamos criar um domínio pelo AuthZForce, porém não obtivemos
sucesso para conectar esse domínio a aplicação. Ao consultar o repositório oficial do projeto,
foi confirmado por um de seus desenvolvedores que esse comportamento é causado por um
bug no Keyrock, que não configura as políticas de acesso corretamente no AuthZForce.
7.9.2 Pendências Devido às dificuldades enfrentadas no desenvolvimento das aplicações e com o fim
do prazo para a conclusão do relatório, o desenvolvimento de uma aplicação de exemplo que
utilize o PDP (AuthZForce) é uma pendência em aberto. É importante ressaltar que tal
dependência é causada por um bug no Keyrock, e que seus desenvolvedores já foram
contactados sobre o assunto.
Também é apresentada como pendência a utilização da linguagem XACML para o
gerenciamento de domínios e políticas de controle de acesso.
7.9.3 Próximos passos
Como próximos passos está a definição de uma solução para a utilização de políticas
de controle de acesso através do componente Keyrock e AuthZForce. Para tal, indicamos o
estudo sobre a administração de domínios e políticas com AuthZForce, o que exigirá um
estudo acerca da linguagem XACML. Tal estudo permitirá também que se explore de
maneira mais aprofundada os componentes Keyrock, Wilma, e AuthZForce. Tal estudo visa a
produção de material didático acerca da utilização das GEs mencionadas para proteger
aplicações que rodem em cima de uma infraestrutura Fiware.
