TODO merge with idhub? | it allows to run everything done in this project as a docker compose
This repository has been archived on 2024-05-31. You can view files and clone it, but cannot push or open issues or pull requests.
Find a file
pedro 1e1a339917 idhub.entrypoint: refactor oidc waiting interval
instead of sleep, waits that all idhubs have wrote its content in
/sharedsecret/ dir
2024-03-18 10:05:16 +01:00
docker idhub.entrypoint: refactor oidc waiting interval 2024-03-18 10:05:16 +01:00
.dockerignore useful dockerignores to ignore local python env 2023-11-16 17:17:56 +01:00
.env.example refactor var: ADMIN -> INITIAL_ADMIN, dyn DOMAIN 2024-03-07 15:15:47 +01:00
.gitignore env var idhub could be used 2024-02-05 20:48:20 +01:00
build__all.sh better wait_seconds 2024-03-15 09:03:02 +01:00
build__common.sh build__common: bugfix wrong substitution 2024-03-15 09:44:04 +01:00
build__instance-autotest-pair.sh test instances: allow overriding of persistence 2024-03-14 16:51:41 +01:00
build__instance-autotest.sh test instances: allow overriding of persistence 2024-03-14 16:51:41 +01:00
build__instance-localhost-pair.sh docker: add localhost pair 2024-03-09 20:29:44 +01:00
build__instance-nightly-pair.sh test instances: allow overriding of persistence 2024-03-14 16:51:41 +01:00
build__instance-nightly.sh test instances: allow overriding of persistence 2024-03-14 16:51:41 +01:00
build__pilot-generic.sh new generic pilot and instances autotest & nightly 2024-02-06 15:32:51 +01:00
build__pilot-lafede.sh lafede: bugfix deployment 2024-02-06 15:58:16 +01:00
build__pilot-pangea.sh bugfix persistent idhubs were not updating code 2024-02-06 14:51:31 +01:00
build__pilot-setem.sh bugfix persistent idhubs were not updating code 2024-02-06 14:51:31 +01:00
build__pilot-xo9b.sh bugfix persistent idhubs were not updating code 2024-02-06 14:51:31 +01:00
docker-compose__instance-autotest-pair.yml pair instances: bugfix missing ADMIN/PASSWORD 2024-03-08 13:29:07 +01:00
docker-compose__instance-autotest.yml refactor var: ADMIN -> INITIAL_ADMIN, dyn DOMAIN 2024-03-07 15:15:47 +01:00
docker-compose__instance-localhost-pair.yml docker: add localhost pair 2024-03-09 20:29:44 +01:00
docker-compose__instance-nightly-pair.yml pair instances: bugfix missing ADMIN/PASSWORD 2024-03-08 13:29:07 +01:00
docker-compose__instance-nightly.yml refactor var: ADMIN -> INITIAL_ADMIN, dyn DOMAIN 2024-03-07 15:15:47 +01:00
docker-compose__pilot-generic.yml update generic pilot 2024-03-08 13:36:46 +01:00
docker-compose__pilot-lafede.yml bugfix domain env vars 2024-02-29 20:46:31 +01:00
docker-compose__pilot-pangea.yml idhub deployment var no longer needed 2024-02-07 12:43:52 +01:00
docker-compose__pilot-setem.yml pilot setem: DOMAIN env var is not used 2024-02-21 14:34:52 +01:00
docker-compose__pilot-xo9b.yml pilot xo9b: add idhub3 2024-03-18 09:32:43 +01:00
docker-compose_idhub-temp.yml idhub: make it more dev env friendly 2023-12-01 10:10:11 +01:00
docker-compose_orchestra-temp.yml orchestra temp build 2023-11-24 12:33:55 +01:00
Makefile bugfix makefile when branch contains / char 2024-03-06 18:54:20 +01:00
orchestra_build.sh orchestra temp build 2023-11-24 12:33:55 +01:00
pull-repos.sh pull-repos: git pull should go before 2024-01-24 15:04:32 +01:00
README.md add instance autotest-pair 2024-02-29 18:18:40 +01:00
status.sh status: update styling, add this docker dir 2024-03-08 13:28:43 +01:00
web_cmd.sh web_cmd: maybe now is fixed 2024-03-15 09:37:04 +01:00

Docker deployment of IdHub and tools

About the pilots and instances that this repository deploys

Pilots

  • XO9B:

    • Instances:

    • Motivation: The aim is to support an accreditation program for vulnerable people, exploring the value of using verifiable credentials to get services/benefits.

    • Scenario: A vulnerable family obtains a benefit (internet connection fee discount) by presenting a verifiable credential to a connectivity provider entity.

      Actors-> XO9B: IdHub1 (acting as a user wallet for families holding credentials issued by a social support organisation), Connectivity provider entity: Demo portal, IdHub2 (acting as verifier). The verifier portal incorporates verification capabalities and support to establish an OIDC4VP dialog with the user wallet for credential presentation (accreditation).

  • Setem:

    • Instances:

    • 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) presenting a verifiable credential to obtain a discount.

      Actors-> Setem BCN: IdHub1 (acting as a user wallet for their members holding credentials issued by Setem BCN), Setem Madrid: Demo portal, IdHub 2 (acting as verifier). The verifier portal incorporates verification capabilities and support to establish an OIDC4VP dialog with the user wallet for credential presentation (accreditation).

  • Lafede:

    • Instance:

    • Motivation: Implementation of dual EIDAS1 and EIDAS2 compliant attestations as signed PDFS with public verifiable credentials exported as QR codes embedded in these documents. Member organisations and related persons of the Lafede federation request membership and training certificates.

      Actors-> Lafede: idHub

  • Pangea:

    • Instances:
    • 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).
    • 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).

        Actors-> Pangea: IdP (goauthentik), Musician, Orchestra. Organisation A: IdP, IdHub

        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.

      • 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.

        Actors-> Pangea: IdP (goauthentik), IdHub (as verifier), Musician, Orchestra (with also nginx API rproxy). Organisation A: IdHub (as user wallet)

  • generic: https://idhub.demo.pangea.org

    • Motivation: For demo purposes, for showing other people different than the intended pilot what we do. It is currently similar to lafede pilot

Instances

Installation

Considering debian stable distribution (Debian 12 bookworm).

  • docker: install using the convenience script
  • 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.

Deployment

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).

Or run a specific pilot with ./build__pilot-example.sh.

All the scripts are written in POSIX Shell. I hope they are easy enough and structured to be adapted to your needs.

Development

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.

    volumes:
      - ./idhub1__pilot-example:/opt/idhub

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.

In the .env there are some variables intended to be used for debugging purposes.

Commands that you might like

if you want to enter a shell inside a new container:

docker run -it --entrypoint= ${target_docker_image} bash

if you want to enter a shell on already running container:

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)