Add server restricted to internal network

docs/source/advancedDevelopment/authorization/authorization.rst

@@ -27,10 +27,10 @@ To understand the material of this section, knowledge on earlier sections of the
    consoleAndLadybug
    authorizationMethodsAndRoles
    httpInterfaces
+   internalNetwork
 
 .. WARNING::
 
    The following topics, and more, will be added:
 
-   * Using secrets to do basic authentication.
    * Keeping secrets using parameters.

docs/source/advancedDevelopment/authorization/consoleAndLadybug.rst

@@ -13,7 +13,7 @@ Setting ``dtap.stage`` to another value than ``LOC`` has another major consequen
 
 .. NOTE::
 
-   In enterprises it is common to restrict access to the Frank!Framework without requiring HTTPS! When multiple servers cooperate they usually do so in a dedicated network that is not accessible from the outside. Requests from outside this network are required to be HTTPS and they enter via a dedicated server. This server handles the details of HTTPS like checking against a certificate. Configuring Tomcat to handle HTTPS is outside the scope of this manual.
+   In enterprises it is common to restrict access to the Frank!Framework without requiring HTTPS! When multiple servers cooperate they usually do so in a dedicated network that is not accessible from the outside. Requests from outside this network are required to be HTTPS and they enter via a dedicated server. This server handles the details of HTTPS like checking against a certificate. Configuring Tomcat to handle HTTPS is outside the scope of this manual. See :ref:`advancedDevelopmentAuthorizationInternalNetwork`.
 
 Properties ``dtap.stage`` and ``application.security.http.transportGuarantee`` should be provided as system properties. The other properties required for authorization can be provided as application properties, but not configuration properties. File ``DeploymentSpecifics.properties`` shown below demonstrate a very basic way to protect the Frank!Console and Ladybug:
 

docs/source/advancedDevelopment/authorization/internalNetwork.rst

@@ -0,0 +1,17 @@
+   .. WARNING::
+
+      The information given here is not complete. Please check :ref:`deploymentSecurity` for additional information.
+
+.. _advancedDevelopmentAuthorizationInternalNetwork:
+
+Restricting server to internal network
+======================================
+
+In :ref:`advancedDevelopmentAuthorizationConsoleLadybug`, it was said that requiring authorization can be combined with allowing acces through HTTP instead of HTTPS. This makes sense when the server is only accessible from an internal network -- an internal network that only connects servers that are part of the same product.
+
+We continue the example of the previous subsection :ref:`advancedDevelopmentAuthorizationHttpInterfaces` in which only access to ``<ApiListener>`` elements is possible. The example adds a client that connects to the server and authenticates using basic authentication. The client is treated in the next subsection. Below you see the ``docker-compose.yml`` file in which the server container is highlighted:
+
+.. literalinclude:: ../../../../srcSteps/Frank2Authentication/v500/docker-compose.yml
+   :emphasize-lines: 2 - 11
+
+The important part here is what is missing -- there is no ``ports`` entry. No port is made accessible on the host network. This is the way to restrict docker containers to the internal network. The network of containers that are part of the same Docker Compose file.