This chapter describes general concepts of how external access to each component is provided and how authentication and authorization layer based on `Shibboleth SP3 <https://wiki.shibboleth.net/confluence/display/SP3/Home>`_. is configured.
General overview
~~~~~~~~~~~~~~~~
Each individual docker **stack** has its own internal network ``intnet`` where services can communicate between each other. This network is not exposed to the public and provides most of the necessary communication. Additionally external user access to some services (client, renderer, cache) is provided via external network ``extnet`` and reverse-proxy (traefik) with load balancer.
These services can have a set of authentication and authorization rules applied both on traefik level and Shibboleth SP level. Kibana and Traefik dashboard are also accessible externally, but through a different set of default credentials.
Routing with traefik
~~~~~~~~~~~~~~~~~~~~
``Reverse-proxy`` service in base stack provides central access endpoint to the VS. It exposes ports 80 and 443 for HTTP and HTTPS access. Configuration of the reverse-proxy is done on three places.
First two are static and dynamic configuration files ``traefik.yml`` and ``traefik-dynamic.yml``. Static configuration sets up connections to providers and define the entrypoints that Traefik will listen to. Dynamic configuration defines how the requests are handled. This configuration can change and is seamlessly hot-reloaded, without any request interruption or connection loss. Third part are docker ``labels`` on individual services which Traefik provides access to.
For example following configuration snippet enables access to certain paths of ``renderer`` service under a given hostname. It also sets externally set basic authentication and other rules via ``@file`` identifier, which references configurations from ``traefik-dynamic.yml``.
An example of such auth@file configuration from ``traefik-dynamic.yml`` would be following snippet, where ``BASIC_AUTH_USERS_AUTH`` is referencing a docker secret configured earlier:
.. code-block:: yaml
http:
middlewares:
auth:
basicAuth:
realm: "PRISM View Server (PVS)"
usersFile: "/run/secrets/BASIC_AUTH_USERS_AUTH"
Unsecured HTTP access is configured to be redirected to the HTTPS endpoint but inside the swarm among the services, only HTTP is used internally. Traefik also needs access to each external network, that he will be servicing.
Authentication and Authorization
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Authentication of access to external parts of VS is made up of two options:
- Traefik provided basic authentication - configured as ``file@auth`` and ``file@apiAuth``
Here, access on such endpoint requires basic authentication credentials (username, password) to be inserted, while web browsers are usually prompted for input. After inserting valid credentials, access is granted.
- Shibboleth Service Provider 3 + Apache 2 instance, to which request is forwarded by `Traefik ForwardAuth middleware <https://doc.traefik.io/traefik/middlewares/forwardauth/>`_.
Middleware delegates the authentication to Shibboleth. If Shibboleth response code is 2XX, access is granted and the original request is performed. Otherwise, the response from the Shibboleth is returned.
Shibboleth can automatically establish a session whenever a particular URL is accessed. This means that any user accessing that resource must be able to authenticate at an IdP trusted by the SP.
In order to authenticate with Shibboleth, a user must log in with valid credentials on the side of Identity Provider (IDP), if doing so, the IDP informs the SP about successful login, accompanied by relevant user attributes. SP then saves the information about a created session into a cookie and based on user attributes can authorize access to the services.
Currently setting individual authorization rules on a ``Collection`` and ``Service`` level is possible with current approach. It is yet not clearly possible to separate viewing and download, as both of these parts are handled by ``renderer`` service.
