Update README.md

Reformulate section "About pilots"
This commit is contained in:
mildred 2024-01-24 12:48:19 +00:00
parent 78a79e69e9
commit e044dadfcc
1 changed files with 77 additions and 64 deletions

141
README.md
View File

@ -1,64 +1,77 @@
# Docker deployment of IdHub and tools # Docker deployment of IdHub and tools
## About the pilots that this repository deploys ## About the pilots that this repository deploys
- xo9b: - **XO9B**:
- motivation: one idhub connects to the other using OIDC4VP flow - Motivation: The aim is to support an accreditation program for vulnerable people, exploring the value of using verifiable credentials to get services/benefits.
- components: idhub1, idhub2 - Scenario: A vulnerable family obtains a benefit (internet connection fee discount) presenting a verifiable credential to an connectivity provider entity.
- setem:
- motivation: a user from org 1 connects to org 2 to get a discount code Actors-> **XO9B**: IdHub (acting as a user wallet), **Connectivity provider entity**: Demo portal (acting as Verifier Portal). The verifier portal incorporates verification capabalities and support to establish an OIDC4VP dialog with the user wallet.
- components: idhub1, idhub2 - **Setem**:
- lafede: - Motivation: Since SETEM is a federation, members of one of the federated entities (Setem BCN) can accredit their membership to other federation members (Setem Madrid) with a verifiable credential to obtain a discount.
- motivatiion: a user gets a verifiable credential presentation from idhub, optionally could be signed also using EIDAS1
- components: idhub1 Actors-> **Setem BCN**: IdHub (acting as a user wallet), **Setem Madrid**: Demo portal (acting as Verifier Portal). The verifier portal incorporates verification capabalities and support to establish an OIDC4VP dialog with the user wallet.
- pangea: - **Lafede**:
- motivation: - Motivation: Implementation of the dual model of EIDAS1-compliant signed PDFS that embed public verifiable credentials exported as QR codes embedded in these documents. Member organisations of the Lafede federation request membership and training certificates.
- a user from org 1 connects to org 1 services
- a user from org 1 connects to org 2 services Actors-> **Lafede**: idHub
- components: idhub1, idhub2, goauthentik services, orchestra (with also nginx api rproxy), musician
- test: intended for software quality such as testing, CI/CD, etc. - **Pangea**:
- Motivation: The case of Pangea as a web/internet service provider, with member organisations that receive services. These organisations have allocated several resources units (mail accounts, blogs, etc.). Only authorised users with a specific role should be able to access the Musician (Administration Control Panel of resources).
## Installation - Scenarios:
- Scenario 1-> 'Login with Organisation A (Idp)'. The staff members of organisation A, with the appropiate role, can authenticate themselves by providing their organisation credentials (username and password) to access a service in Pangea (Musician).
Considering debian stable distribution (Debian 12 bookworm)
Actors-> **Pangea**: Idp (goauthentik), Musician, Orchestra. **Organisation A**: Idp, IdHub
- docker: [install using the convenience script](https://docs.docker.com/engine/install/debian/#install-using-the-convenience-script)
- make: some of the actions are declared in `Makefile`, you will need `sudo apt install make`. Pangea delegates authentication to the idP of organisation B using OpenID Connect. In this case, the Pangea's IdP (goauthentik) delegates the authentication to Organisation A's IdP, which get the user's role information from the Organisation A's IdHub.
- figlet: display large texts, better visibility when running all the pilots together `sudo apt install figlet`.
- Scenario 2-> 'Present a verifiable credential'. The staff members of organisation A, with the appropiate credentials, present them to Pangea in order to access the Musician service.
## Deployment
Actors-> **Pangea**: Idp (goauthentik), IdHub (as verifier), Musician, Orchestra (with also nginx api rproxy). **Organisation A**: IdHub (as user wallet)
Execute `./build__all.sh` to run all the pilots, that includes building locally all the docker images and deploying its docker compose (each pilot has its `docker-compose__pilot-example.yml`).
- **test**: intended for software quality such as testing, CI/CD, etc.
Or run a specific pilot with `./build__pilot-example.sh`.
## Installation
All the scripts are written in POSIX Shell. I hope they are easy enough and structured to be adapted to your needs.
Considering debian stable distribution (Debian 12 bookworm)
## Development
- docker: [install using the convenience script](https://docs.docker.com/engine/install/debian/#install-using-the-convenience-script)
You can use these docker images for developing the software. This repo is targeted on integrating, deploying and testing the IdHub tools. You can do the same with the other tools, the trick used is to override the docker's directory with a local directory. Example found on all pilots instances - make: some of the actions are declared in `Makefile`, you will need `sudo apt install make`.
- figlet: display large texts, better visibility when running all the pilots together `sudo apt install figlet`.
```yaml
volumes: ## Deployment
- ./idhub1__pilot-example:/opt/idhub
``` Execute `./build__all.sh` to run all the pilots, that includes building locally all the docker images and deploying its docker compose (each pilot has its `docker-compose__pilot-example.yml`).
If you are developing IdHub, all the instances generate a copy of the target repository such as `idhub1__pilot-example`, which you can modify there, and the changes will apply to the deployment Or run a specific pilot with `./build__pilot-example.sh`.
In the `.env` there are some variables intended to be used for debugging purposes All the scripts are written in POSIX Shell. I hope they are easy enough and structured to be adapted to your needs.
### Commands that you might like ## Development
if you want to enter a shell inside a new container: You can use these docker images for developing the software. This repo is targeted on integrating, deploying and testing the IdHub tools. You can do the same with the other tools, the trick used is to override the docker's directory with a local directory. Example found on all pilots instances
```sh ```yaml
docker run -it --entrypoint= ${target_docker_image} bash volumes:
``` - ./idhub1__pilot-example:/opt/idhub
```
if you want to enter a shell on already running container:
If you are developing IdHub, all the instances generate a copy of the target repository such as `idhub1__pilot-example`, which you can modify there, and the changes will apply to the deployment
```sh
docker exec -it ${target_docker_image} bash In the `.env` there are some variables intended to be used for debugging purposes
```
### Commands that you might like
Where `target_docker_image` contains the ID of the container you want to run (see `docker ps` or `docker ps -a`)
if you want to enter a shell inside a new container:
```sh
docker run -it --entrypoint= ${target_docker_image} bash
```
if you want to enter a shell on already running container:
```sh
docker exec -it ${target_docker_image} bash
```
Where `target_docker_image` contains the ID of the container you want to run (see `docker ps` or `docker ps -a`)