Overview

The SVS component is based on SaToSa and add InACademia specific components from teh SVS git repository

An ansible script, based on https://github.com/surfnet-niels/simplesaml-idp, is used to handle the configuration inside the docker container.

The overall setup is part of the inacademia-dev repository: https://github.com/surfnet-niels/inacademia-dev/tree/master/ssp-idp

Please note the SVS by itself does not deliver https based traffic. This is offloaded to POUND which is configures as part of the op.inacademia.local

Directory structure

├── build_svs.sh
├── config
│   ├── cdb
│   │   ├── cdb.json
│   │   └── cdb.json.example
│   ├── production
│   │   ├── attributemaps
│   │   │   ├── adfs_v1x.py
│   │   │   ├── adfs_v20.py
│   │   │   ├── basic.py
│   │   │   ├── __init__.py
│   │   │   ├── saml_uri.py
│   │   │   └── shibboleth_uri.py
│   │   ├── backend.xml
│   │   ├── certs
│   │   │   ├── saml_metadata_backend.crt
│   │   │   └── saml_metadata_backend.key
│   │   ├── dhparams.txt
│   │   ├── entityids.json
│   │   ├── idp.xml
│   │   ├── inAcademia.key -> certs/saml_metadata_backend.key
│   │   ├── inAcademia.pub -> certs/saml_metadata_backend.crt
│   │   ├── info.log
│   │   ├── internal_attributes.yaml
│   │   ├── metadata.crt -> certs/saml_metadata_backend.crt
│   │   ├── metadata.key -> certs/saml_metadata_backend.key
│   │   ├── plugins
│   │   │   ├── attribute_processor.yaml
│   │   │   ├── custom_logging.yaml
│   │   │   ├── inacademia_backend.yaml
│   │   │   ├── inacademia_frontend.yaml
│   │   │   └── user_consent.yaml
│   │   └── proxy_conf.yaml
│   └── rsyslog
│       ├── inacademia.conf
│       └── rsyslog.conf
├── Dockerfile
├── LICENSE
├── NOTICE
├── README.md
├── run_svs.sh
└── start.sh

The Dockerfile is the basis for the docker to be build. The build_svs.sh and run_svs.sh scripts will build and run the docker image respectively. The run_svs.sh script will test if the image exists, and if not, try to build it before running it.

In the config directory 2 subdirectories exist:

  • cdb contains the client database, the RPs that are allowed to connect to InAcademia and which scopes and claims they are allowed to query
  • production contains a set of directiries and files that describe the InAcademia setup.
    • attributemaps configures how SaToSa maps various protocols from and to its internal state. This needs no changes for InAcademia.
    • certs contains the certificates needed for SAML and OIDC (but NOT for https). 
    • plugins contain the InAcademia frontend, backend and microservices needed by SaToSa for InAcademia.For more info on the syntax used, see the SaToSa documentation https://github.com/IdentityPython/SATOSA/tree/master/doc
    • backend.xml contains Frontend SAML metadata and gets autogenerated when InAcademia docker starts.
    • rsyslog directory contains the configuration for the rsyslog. For the production service we use a central server we use for all logfiles from InAcademia
    • entityids.json contains a list of all IdPs that are allowed to use the InAcademia service.
    • idp.xml contains the SAML metadata of the IdPs that connect to InAcademia. In production thi sis typically not used and a MDQ is used instead.
    • for historic reasons teh certificates neede by SatoSa for the SAML endpoint and the OIDC endpoint are named differently. This is resolved by the use of the symlinks inAcademia* and metadata* who all point to the certificates in the certs directory
    • info.log is the InAcademia logfile.

Typically neither of these files need changes for a deploy.Docker file

The docker file is completely self contained, so it will build the SVS based on the condig and by pulling relevant repositories if needed

FROM ubuntu:16.04
MAINTAINER InAcademia Team, tech@inacademia.org

RUN apt-get update && apt-get install -y --no-install-recommends \
    git \
    python3-dev \
    build-essential \
    python3-pip \
    libffi-dev \
    libssl-dev \
    xmlsec1 \
    libyaml-dev \ 
    rsyslog
RUN apt clean

RUN pip3 install --upgrade pip setuptools
RUN pip3 install git+git://github.com/InAcademia/SATOSA.git@svs-1.0.1#egg=SATOSA
RUN pip3 install git+git://github.com/InAcademia/svs.git#egg=svs
RUN pip3 install pystache

COPY config/rsyslog/rsyslog.conf /etc/rsyslog.conf
COPY config/rsyslog/inacademia.conf /etc/rsyslog.d/inacademia.conf
COPY start.sh /tmp/inacademia/start.sh
COPY config/production/attributemaps /tmp/inacademia/attributemaps
COPY config/cdb/cdb.json.example /etc/cdb/cdb.json

ENTRYPOINT ["/tmp/inacademia/start.sh"]

Deploying & Starting SVS

Run build_svs.sh to build a new docker.

Assuming your build went without errors you can now run the docker image trough run_svs.sh

Success, you now have a working SVS component. By defaul tthe debug log is being shown in the console

You can quickly test if the SVS component is responding by pointing your browser to http://svs.inacademia.local (NOT https!)

This should give you a page stating "Couldn't find the page you asked for!", which is basically SaToSa telling you you did not make a valid SMAL or OIDC request.


  • No labels