INSTALAÇÃO

5. FHIRBOX (IMPLEMENTAÇÃO)

5.1.2. SERVIDOR RESTFUL

5.1.2.2. INSTALAÇÃO

De forma a mais facilmente instalar o servidor FHIR foi criado umDockerfile que arranca um

servidor aplicacional jetty

(com base na docker image “jetty:9-jre8-alpine”

) e faz deploy do war

gerado pelo maven.

EsseDockerfileé tão simples como:

Com este ficheiro é possível criar uma docker image com o war gerado pelo maven da

seguinte forma:

78https://www.hl7.org/fhir/compartmentdefinition.html

FROM jetty:9-jre8-alpine USER jetty:jetty

De seguida apenas é necessário arrancar ocontainercom essa imagem:

Note-se que o comando acima estabelece uma conexão entre estecontainere o da base de

dados PostgreSQL através do argumento “--link

fhirserver-db:fhirserver-db

”. Para tal é

necessário arrancar primeiramente o container da BD, utilizando os comandos anteriormente

mencionados, para que ocontainerdo servidor FHIR tenha acesso ao mesmo.

5.2. AUTHORIZATION SERVER

Para a instalação dokeycloakforam utilizadas duasdocker imagespresentes nodocker hub:

“mysql:5.7.19”

e “jboss/keycloak-mysql:3.2.1.Final”

.

A diretoria que contém os ficheiros de base de dados do container mysql foi mapeada,

através de umdocker volume, para uma diretoria, previamente encriptada, dohost, à semelhança

do que foi feito com a base de dadosPostgreSQLdo FHIR server.

De seguida procedeu-se à configuração dokeycloakde acordo com as necessidades:

▪ Configuração de uma novarealmdenominada “fhirbox”

▪ Criação de um client, denominado “fhirbox”, que será utilizado pela Gateway para

autenticação da própria plataforma sendo-lhe atribuída a scope “admin”

▪ Criação das scopes a suportar em conformidade com o perfil FHIR OAuth 2.0 Scopes com a

alteração previamente mencionada dos Compartments como permission types (ex:

“Patient/Observation.read”, “Patient/Observation.write”, “Patient/Condition.write”, “Patient/.”,

“Device/Observation.read”, “Practitioner/Practitioner.*”)

▪ Configuração de client templates

,para serem atribuídos a clients, com o protocolo

openid-connect de forma a possibilitar a utilização dos workflowsdo OAuth 2.0 com tokens JWT, e

seleção dasscopespré-definidas que se adequem, para:

▪ instituições de saúde (que deverão ser usados para autenticação pelos EHRs)

▪ dispositivos médicos

▪ aplicações de terceiros que não se enquadrem nos anteriores

78https://hub.docker.com/_/mysql/

79https://hub.docker.com/r/jboss/keycloak-mysql/

80http://www.keycloak.org/docs/3.2/server_admin/topics/clients/client-templates.html

mvn package

docker build -t fhirbox-fhirserver .

docker run -d --name fhirbox-fhirserver -p 8080:8080 --link fhirserver-db:fhirserver-db fhirbox-fhirserver

▪ Criação de umclientportemplatepara utilização durante o desenvolvimento e testes

A Tabela 2 descreve as scopes suportadas por cada tipo de cliente:

Tabela 2 - FHIRbox scopes por tipo de cliente

Tipo de cliente Scopes

Instituição de saúde

Patient/*.* Patient/*.read Patient/*.write Patient/AllergyIntolerance.* Patient/AllergyIntolerance.read Patient/AllergyIntolerance.write Patient/Condition.* Patient/Condition.read Patient/Condition.write Patient/Observation.* Patient/Observation.read Patient/Observation.write Patient/Patient.* Patient/Patient.read Patient/Patient.write Patient/Procedure.* Patient/Procedure.read Patient/Procedure.write

Dispositivos médicos

Device/*.* Device/*.read Device/*.write Device/Device.* Device/Device.read Device/Device.write Device/Observation.* Device/Observation.read

Device/Observation.write Patient/Patient.read Patient/Observation.* Patient/Observation.read Patient/Observation.write

FHIRbox

admin

Outras aplicações

Configurado individualmente conforme necessidades da aplicação

Note-se que foi criada ascope“admin” que deverá ter permissão total de forma a ser utilizada

internamente pelos diferentes componentes do FHIRbox.

Adicionalmente foi configurado umprotocol mapper

para cada cliente de forma a incluir o

endereço de email do utilizador nos JWT para posterior utilização pelas aplicações com o objetivo

de identificar o paciente em questão. Esta configuração só é necessária devido à decisão de

utilizar, para efeito do presente projeto, o email como identificador único (ver capítulo 4.3.2). Numa

situação real devem ser suportados outros tipos de identificadores de forma a que o paciente não

tenha, obrigatoriamente, de partilhar o seu email com as entidades envolvidas. Omapperutilizado

para o email foi, ainda assim, marcado como consent required de forma a ser necessário o

consentimento do paciente quanto à partilha do seu email com osclientsque lhe solicitem acesso

a dados da sua conta do FHIRbox.

De seguida procedeu-se à criação de umclientpara cada template previamente configurado.

Na configuração doclienté necessário especificar o tipo de acesso que o mesmo possuirá, isto é

muito importante para garantir a segurança dos flows de autenticação e autorização. Foi, então,

definido, para cada cliente:

▪ Tipo de acesso

▪ Confidencial - Deve ser atribuído a clientes capazes de manter a confidencialidade de

umclient secret. Tipicamente deve ser usado para aplicações que executem os pedidos

ao authorization server através do seuserver side.

▪ Público - Deve ser atribuído a clientes que necessitam de executar umlogin no browser

ou aplicações mobile (client side). Nestas aplicações, tipicamente, não existe forma de

manter um client secret seguro. Para estes clientes, é muito importante restringir o

acesso configurando apenas as URIs de redirecionamento necessárias para o cliente.

▪ Bearer-only - Este tipo de acesso significa que o cliente apenas é portador de tokens e

não pode participar num processo de login (não pode pedir tokens ao authorization

server).

▪ Necessidade de consentimento - Define a necessidade de consentimento dos utilizadores

para com asscopes requeridas pelo cliente, ou seja, é pedido ao utilizador para conceder as

permissões devidas à aplicação (cliente). Os metadados relativos às scopes para as quais o

cliente está interessado são exibidos ao utilizador para que este saiba exatamente a que

informações o cliente requer acesso.

▪ Redirect URIs - Definição dos padrões de URL de redirecionamento válidos. É importante

limitar os URLs ao mínimo necessário para o cliente de forma a evitar redirecionamentos

indevidos para outros sítios web aumentando a segurança e a dificuldade de ataques como

Man-in-the-middle

e CSRF

.

▪ Flows de autorização habilitados - Devem ser habilitados apenas os flows que façam sentido

para determinado cliente. Em termos deOpenID ConnecteOAuth 2.0é possível habilitar os

seguintes flows:

▪ Authorization Code Flow

▪ Implicit Flow

▪ Direct Grants (Resource Owner Password Credentials Grant)

▪ Client Credentials Grant

A Tabela 3 contém todos os clientes criados para testes, bem como o client template e as

configurações de alguns dos parâmetros acima definidos que lhes foram atribuídas.

Tabela 3 - Clientes para teste e respetiva parametrização

Client ID Client template Tipo de acesso Consentimento Flows

some-healthcare-institution ^{Healthcare institution} ^Confidencial ^Requerido

Authorization Code Flow Direct Grants Client Credential Grant

some-medical-device Medical device Confidencial Requerido