@@ -13,11 +13,11 @@ These services can have a set of authentication and authorization rules applied
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.
``Reverse-proxy`` service in base stack provides central access endpoint to the VS. It exposes ports 80 and 443 for HTTP and HTTPS access in the host mode. 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.
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 which an update requires removing and re-creating the stack.
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``.
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 global configurations from ``traefik-dynamic.yml``.
.. code-block:: yaml
...
...
@@ -48,7 +48,7 @@ An example of such auth@file configuration from ``traefik-dynamic.yml`` would be
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.
Unsecured HTTP access is configured to be redirected to the HTTPS endpoint. Inside the swarm among the services, only HTTP is used internally.
Authentication and Authorization
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
...
@@ -60,27 +60,27 @@ Here, access on such endpoint requires basic authentication credentials (usernam
- Shibboleth Service Provider 3 + Apache 2 instance, to which requests are 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.
Middleware delegates the authentication to Shibboleth. If Shibboleth response code is 2XX, access is granted and the original request is performed. Otherwise, the error response from Shibboleth is returned.
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 and a session is created for the user. SP then saves the information about a created session into a cookie and based on user attributes can authorize access to the services. If the user was already logged in, he is automatically offered the requested resource.
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.
Currently setting individual authorization rules on a ``Collection`` (docker stack) and ``Service`` (docker service) level is possible. It is yet not clearly possible to separate viewing and download functionality, as both of these parts are handled by ``renderer`` service.
Configuration
~~~~~~~~~~~~~
For correct configuration of Shibboleth SP3 on a new stack, several steps need to be done. Most of these configurations are usually done in the :ref:`initialization` step using ``pvs_starter`` tool. Still, it is advised to check following steps, understand them and change if necessary.
Briefly summarized, SP and IdP need to exchange metadata and certificates to trust each other, SP needs to know which attributes the IdP will be sending about the logged-in user and respective access-control rules are configured based on those attributes. Most of the configurations are done via docker configs defined in the docker compose
Briefly summarized, SP and IdP need to exchange metadata and certificates to trust each other, SP needs to know which attributes the IdP will be sending about the logged-in user and respective access-control rules are configured based on those attributes. Most of the configurations are done via docker configs defined in the docker compose files.
- Create a pair of key, certificate using attached Shibboleth ``config/shibboleth/keygen.sh`` in the cloned vs repository and save them as respective docker secrets.
- Create a pair of key, certificate using attached Shibboleth utility ``config/shibboleth/keygen.sh`` in the cloned ``vs`` repository and save them as respective docker secrets.
.. code-block:: bash
SPURL="https://emg.pass.copernicus.eu" # service initial access point made accessible by traefik
- Get IDP metadata and save it as a docker config. Also read the entityID of the IdP for further use in referencing it in your ``shibboleth2.xml`` configuration.
- Get IDP metadata and save it as a docker config. Also save the entityID of the IdP for further use in filling the ``shibboleth2.xml`` template.
.. code-block:: bash
...
...
@@ -88,17 +88,9 @@ Briefly summarized, SP and IdP need to exchange metadata and certificates to tru
- Configure Apache ServerName used inside the ``shibauth`` service by modifying ``APACHE_SERVERNAME`` environment variable of corresponding ``shibauth`` service in ``docker-compose.<stack>.ops.yml``. This URL should resolve to the actual service URL.
- Modify shibboleth2.xml content by setting your "entityID" in <ApplicationDefaults> Additionally edit the "entityID" value inside ``SSO`` element to match the IdP "entityID". Note that "entityID" does not need to resolve to an actual service URL.
- Configure SP and IdP EntityIDs used inside the ``shibauth`` service by modifying ``SPEntityID`` and ``IDPEntityID`` environment variables of corresponding ``shibauth`` service in ``docker-compose.<stack>.ops.yml``. ``SPEntityID`` can be chosen in any way, IDPEntityID should be extracted from received IDP metadata.
- Deploy your shibauth service and exchange your SP metadata with the IdP provider and have them recognize your SP. Necessary metadata needs to be downloaded from url ``<service-url>/Shibboleth.sso/Metadata``.
- Deploy your shibauth service and exchange your SP metadata with the IdP provider and have them register your SP. Necessary metadata can be downloaded from url ``<service-url>/Shibboleth.sso/Metadata``.
- Get information about attributes provided by IdP and update ``config/shibboleth/attribute-map.xml`` by adding individual entries mapping ``name`` provided by IdP to ``id`` used by SP internally. Example configuration:
...
...
@@ -109,7 +101,7 @@ Briefly summarized, SP and IdP need to exchange metadata and certificates to tru
- Create custom access rules based on these attributes and map these access controls to different internal apache routes to which Traefik ForwardAuth middleware will point. Access rules are created in ``config/shibboleth/<stack-name>-ac.xml``.
- Create custom access rules based on these attributes and map these access controls to different internal Apache routes to which Traefik ForwardAuth middleware will point. Access rules are created in ``config/shibboleth/<stack-name>-ac.xml`` and ``config/shibboleth/<stack-name>-ac-cache.xml``.
Example of external Access control rules configuration:
...
...
@@ -136,45 +128,38 @@ Example of external Access control rules configuration:
Relevant Apache configuration in ``config/shibboleth/shib-apache.conf``, enabling Shibboleth authentication and authorization of the ``/secure`` endpoint.
Relevant Apache configuration in ``config/shibboleth/shib-apache.conf``, enabling Shibboleth authentication and authorization of the renderer service on the ``/secure`` endpoint.
.. code-block:: apacheconf
<Location />
SetHandler shib
# Internally redirected to here. Rewrite for proper relaystate in shib
<Location /secure>
<If "-n req('Authorization')">
# rules for Basic Auth fallback
</If>
<Else>
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Uri} ^(.*)$ [NC]
RewriteRule ^.*$ %1 [PT]
</Else>
</Location>
<VirtualHost *:80>
PassEnv APACHE_SERVERNAME
ServerName "${APACHE_SERVERNAME}"
<Location /secure>
AuthType shibboleth
ShibRequestSetting requireSession 1
Require shib-plugin /etc/shibboleth/pass-ac.xml
</Location>
...
Part of Traefik ForwardAuth middleware configuration from ``traefik-dynamic.yml``, defining the internal address pointing to the ``shibauth`` service and ``/secure`` endpoint in it:
.. code-block:: yaml
http:
middlewares:
shibAuth:
forwardAuth:
address: http://shibauth/secure
trustForwardHeader: true
<LocationMatch "^/(admin|ows|opensearch)">
RewriteEngine On
AuthType shibboleth
ShibRequestSetting requireSession 1
Require shib-plugin /etc/shibboleth/pass-ac.xml
RewriteRule ^.*$ - [R=200]
</LocationMatch>
Part of renderer service Traefik labels from ``docker-compose.emg.ops.yml``, where access through the middleware is configured.
Part of Traefik ForwardAuth middleware configuration from ``docker-compose.emg.ops.yml``, defining the internal address pointing to the ``shibauth-emg`` service and ``/secure`` endpoint in it:
