Signet's SAMLtest.ID testing service is dead

[prigaux]

Default configuration is an SP-to-IdP proxy using Signet's SAMLtest.ID testing service.

Alas https://samltest.id/ is no more:

• Latest web.archive.org snapshot is late 2023 ( https://web.archive.org/web/20231209104333/https://samltest.id/ )
• It was hosted by https://www.signet.id/ which is now squatted.

[rishabh-cldcvr]

hey is there any plan to fix this? I'm facing connection error to samltest.id host when launching latest docker image. Is there any workaround to fix this?

[PeterBolha]

I stumbled upon this exact issue in July 2024 and it still seems to be problematic. In case someone else needs a workaround, this is what worked for me:

• created a local docker volume for the /etc/satosa folder
• downloaded the satosa container from the Docker Hub on Docker Desktop
• launched the image with the configuration provided in the screenshot

• launched the container

The first launch fails but the configuration files are now available in the Docker volume. In the volume folder, the files:
/plugins/frontends/saml2_frontend.yaml and plugins/backends/saml2_backend.yaml contain the broken links to the samltest.id.

Other testing sites that do not crash the initial boot of SATOSA are for example Mock SAML for IdP or RSA for SP. I have personally managed to configure a working example based on this guide.

[peter-]

FWIW, here's how I'm using the official image from docker compose, avoiding the provided entrypoint script (and thereby this issue) completely:

services:
  satosa:
    image: satosa  # or satosa:alpine
    volumes:
    - ./satosa:/etc/satosa:ro
    environment:
      PYTHONDONTWRITEBYTECODE: 1
      SATOSA_CONFIG: /etc/satosa/proxy_conf.yaml
      # etc.
    entrypoint:
    - gunicorn
    command:
    - --bind=0.0.0.0:${GUNICORN_PORT:-8080}
    - --workers=${GUNICORN_WORKERS:-3}
    - --worker-tmp-dir=/dev/shm
    - satosa.wsgi:app

The local directory satosa contains the required configuration files, specifically proxy_conf.yaml.
The same can be done on the docker command line, of course.