You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

For the development of InAcademia a combination of components is needed.

Source: InAcademiaSchematic for dev.ditaa

(1) Relaying Party

A OIDC relaying party who mimics the role of the merchant website asking for the validation.

For this we use a vanilla Apache server together with apache mod OIDC
Setup is described here: https://github.com/InAcademia/Client-docs/blob/master/Apache2%2Bmod_auth_oidc.md

(2) Identity provider

The SAML IdP provides the identities and in this case mimics the institutional Identity providers we use from eduGAIN.

As we do not need real identities from users for development we use a mock IdP which can be set up form these Ansible scripts: https://github.com/surfnet-niels/simplesaml-idp

(3) InAcademia Core SVS

The core of the InAcademia service is offered by SaToSa, which we have extended by the SVS functionality

SaToSa can be found here: https://github.com/IdentityPython/SATOSA

SVS is here: https://github.com/InAcademia/svs

(4) Discovery and MDQ

To aid the code service, a discovery and MDQ service is sometimes needed. In production this is operated by Nordunet, but for dev we need to run our own.

To deploy this we use these ansibl scripts that deploy a ready to run Docker instance: https://dev.niif.hu/vopaas/MDXandDisco


Docker Environment

As most of the components only need to be static we set up dockers so we can readily and reliably redeploy these for a developer. As such a current version of docker is required.

Docker network

First setup a docker network

docker network create --subnet=172.20.0.0/16 inacademia

Setup of the dockers

We want the dockers to be set up in a consistent way. As such:

  • All configuration that needs to be consumed by the docker will be mounted of the local filesystem of the docker host from the "config" directory
  • Application data that may need changing will be consumed from a local filesystem of the docker host from the "app" directory
  • Logs will be display in std_out of the docker and be made available in the local filesystem of the docker host from the "logs" directory

The Dockerfile will be the only entity that controls the creation of the docker from a vanilla Ubuntu 18.04 LTS and is responsible fro ALL dependency resolution. It may pull git repositories of even Ansible code to do so of case, but can also use regular apt commands.

A start/stop shell script will start the docker and dynamically inject config like mount points, network config etc.

An example is provided below for the IdenityProvider component based on SimpleSamlPhp

ssp-idp
   - config/
     - ansible
       - idp.yml
       - inventory
     - metadata/
       - saml20-idp-hosted.php
       - saml20-idp-remote.php
       - saml20-sp-remote.php
   - Dockerfile
   - build_ssp-idp.sh
   - run_ssp-idp.sh


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

FROM ubuntu:16.04

EXPOSE 443

RUN apt -y update && apt -y full-upgrade && apt -y autoremove && apt install -y sudo dnsutils git software-properties-common
RUN apt-add-repository -y ppa:ansible/ansible && apt install -y ansible

RUN git clone https://github.com/surfnet-niels/simplesaml-idp.git /tmp/ansible/simplesaml-idp
COPY config/ansible/inventory /tmp/ansible/simplesaml-idp/
COPY config/ansible/idp.yml /tmp/ansible/simplesaml-idp/group_vars/

RUN  ansible-playbook -i /tmp/ansible/simplesaml-idp/inventory /tmp/ansible/simplesaml-idp/simplesaml-idp.yml


COPY config/metadata /var/www/simplesamlphp/metadata 

ENTRYPOINT service apache2 start && /bin/bash








  • No labels