CH IUA Authorization Server Simulator

The goal of this document is to help deploy a simulator for the IUA (Internet User Authorization) Profile concording to both the IHE and CH specification, and give an overlook of what such a tool should be able to do.

Table of Contents

1. Installation process
2. Specifications 2.1 ITI-71 2.2 ITI-72 2.3 ITI-102 2.4 ITI-103

Installation process

Prérequisites :

Either :

• Java 17
• Wildfly server 27
• A Keycloak server open at port 8090

or

• Docker

Docker Installation

In this project you'll find a docker compose file containing everything you need. You just need to execute this file to have your environment setup

docker-compose command line to write

• A Keycloak server deployed at address localhost:8080
• A wildfly running with the authorization server available at address localhost:8080

All other endpoints needed to understand the workflow of the simulator will be explained later in this document.

Configuration

Environment variables

Applications deployment (for dev)

Deploy with Maven

The first possibility is to deploy GUM with maven-docker-plugin. This process is useful for integrations tests.

mvn -f iua-simulator-service/pom.xml docker:start

The list of applications that will be deployed :

• gazelle-database (https://gitlab.inria.fr/gazelle/private/industrialization/docker/gazelle-database)

gazelle-keycloak (https://gitlab.inria.fr/gazelle/private/industrialization/docker/gazelle-keycloak/-/tree/keycloak_v_20)

• iua-simulator

Check the logs

docker logs -f iua-simulator

Tips : you can add the flag -Ddocker.follow to your command to automatically follow the logs.

Stop the services

mvn -f iua-simulator-service/pom.xml docker:stop

Java Installation

Place yourself in the root directory of this project, then on a terminal, run the command

mvn clean install -DskipTests

An artifact will be created in the iua-simulator-service directory called iua-simulator-service.war

Copy this artifact in your wildfly standalone/deployments/ folder and start your server.

You'll then be able to access your simulator through the address setup in your wildfly configuration file.

Specifications

As explained in the specification that can be found on profiles.ihe.net, IUA is a way to add Authorization to profiles and transaction through the use of an Authorization Server. Authorization Clients are used to interact with the Authorization Server to retrieve access token. Tokens then used in HTTP Rest transactions to access resources deployed on Servers. You'll find here a list of all transactions available through this simulator.

ITI-71

The ITI-71 transaction is sent by the Authorization Client to the Authorization Server to retrieve an access Token to be used within requests to the Resource server.

Two ways can be used to resolve this transaction, but the one used by this simulator is the Authorization Code grant type.

The first Http Request is a GET containing the following parameters :

This request must be sent to the /authorize endpoint of the authorization server. This means the request should look like something like this :

HTTP GET {$simulator.endpoint}/iua-simulator/rest/ch/authorize?
   response_type=code
   &client_id=ch-iua-client
   &state=helloFromChIua
   &resource=ihe.pixm.net
   &code_challenge=fDH8WRQ-vp-6dU6_llO2Fa7wHYSoiKOWoDNxl_u0TLg
   &code_challenge_method=S256
   &redirect_uri={$simulator.endpoint}/iua-simulator/rest/ch/callback
   &scope=profile
   &aud=http://pixmResourceServerURL.ch
   &launch=azerty
   HTTP 1.1

Following this request, you will receive an Authorization Code in a JSON formatted response.

Using the Authorization client, you will then need to do a second Request:

This request is a Post sent to the /token endpoint of the authorization server. Those arguments must therefore be contained in a body as an application/x-www-form-urlencoded content-type, and encoded in UTF-8 Finally both client_id and client_secret must be encapsulated in the base HTTP Authorization header.

This means the request should like something like this :

HTTP POST {$simulator.endpoint}/iua-simulator/rest/ch/token HTTP 1.1
Authorization: Basic vsdvZRTYHQS51SgvtsqeGFs62
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=13fER1Gqe2FshWDRwg
&redirect_uri={$simulator.endpoint}/iua-simulator/rest/ch/callback
&code_verifier=-5Q635ku8ER2pfGeuDagpsk40

As a response to this, you should receive a JSON containing the access_token. You can use resources such as jwt.io to verify the content of your access_token.

This access_token can now be used by the user to access resource servers or for other transactions.

ITI-72

Coming soon

ITI-102

Not in scope

ITI-103

The ITI-103 request allows for interaction between the authorization server and resources server.

The content returned by this page is the following :

HTTP GET {$simulator.endpoint}/iua-simulator/rest/ch/.well-known/smart-configuration HTTP 1.1