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

Compare with Current View Page History

« Previous Version 12 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
Based on the client setup as is described for InAcademia 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

Detailed information on deploying and running this IdP in docker can be found

(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

Pound is being used to proxy the SaToSa to the outside world. It also takes care of https offloading

(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.172.172.0/16 inacademia.local

Local hostname resolution

Add the following hosts to you local hosts file (/etc/hosts)

172.172.172.1   svs.inacademia.local
172.172.172.2   op.inacademia.local
172.172.172.100 rp.inacademia.local                  
172.172.172.200 idp.inacademia.local

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

For the components we have detailed pages describing the setup:

  • No labels