...
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
| Code Block |
|---|
├── 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 |
...
- 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.
...
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.
