For the development of InAcademia a combination of components is needed.
Source: InAcademiaSchematic for dev.ditaa
(1) Relying Party
A OIDC relying 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-development/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: