Add JWT support in HTTP/HTTPS based locations

Issue-ID: DCAEGEN2-2536

Signed-off-by: Krzysztof Gajewski <krzysztof.gajewski@nokia.com>
Change-Id: I46e07b8fe97d621e94611dda104e43f8426ca450

3 files changed, 46 insertions, 5 deletions

diff --git a/docs/sections/services/dfc/architecture.rst b/docs/sections/services/dfc/architecture.rst
index 6d44b7a8..75913dbb 100644
--- a/docs/sections/services/dfc/architecture.rst
+++ b/docs/sections/services/dfc/architecture.rst
@@ -30,9 +30,11 @@ Interaction
 """""""""""
 DFC will interact with the DMaaP Message Router, using json, and with the Data Router, using metadata in the header and
 file in the body, via secured protocol.
-So far, the implemented protocols to communicate with xNFs are http (with basic authentication), https, sftp and ftpes.
-When https protocol is used, the following ways of connection are possible: client certificate authentication, basic
-authentication, and no authentication.
+So far, the implemented protocols to communicate with xNFs are http, https, sftp and ftpes.
+When HTTP protocol protocol is used, following ways of authentication are supported: basic authentication and bearer token
+(e.g. JWT) authentication.
+When HTTPS protocol protocol is used, following ways of authentication are supported: client certificate authentication,
+basic authentication, bearer token (e.g. JWT) authentication and no authentication.
 
 Retry mechanism
 """""""""""""""
diff --git a/docs/sections/services/dfc/http-notes.rst b/docs/sections/services/dfc/http-notes.rst
index 7f65b6ca..c45c7bd8 100644
--- a/docs/sections/services/dfc/http-notes.rst
+++ b/docs/sections/services/dfc/http-notes.rst
@@ -112,3 +112,23 @@ Note, effective way of authentication depends of uri provided and http server co
 
 If port number was not supplied , port 443 is used by default.
 Every file is sent through separate https connection.
+
+JWT token in HTTP/HTTPS connection
+""""""""""""""""""""""""""""""""""
+
+JWT token is processed, if it is provided as a ``access_token`` in the query part of the **location** entry:
+
+.. code-block:: bash
+
+   scheme://host:port/path?access_token=<token>
+   i.e.
+   https://example.com:443/C20200502.1830+0200-20200502.1845+0200_195500.xml.gz?access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkZW1vIiwiaWF0IjoxNTE2MjM5MDIyfQ.MWyG1QSymi-RtG6pkiYrXD93ZY9NJzaPI-wS4MEpUto
+
+JWT tokens are consumed both in HTTP and HTTPS connections. Using JWT token is optional. If it is provided, its
+**validity is not verified**. Token is extracted to the HTTP header as ``Authorization: Bearer <token>`` and is **NOT**
+used in URL in HTTP GET call. Only single JWT token entry in the query is acceptable. If more than one ''access_token''
+entry is found in the query, such situation is reported as error and DFC tries to download file without token. Another
+query parameters are not modified at all and are used in URL in HTTP GET call.
+
+If both JWT token and basic authentication are provided, JWT token has the priority. Such situation is considered
+as fault and is logged on warning level.
diff --git a/docs/sections/services/dfc/troubleshooting.rst b/docs/sections/services/dfc/troubleshooting.rst
index bdc0cd80..680bf1ff 100644
--- a/docs/sections/services/dfc/troubleshooting.rst
+++ b/docs/sections/services/dfc/troubleshooting.rst
@@ -171,5 +171,24 @@ To resolve this warning, provide a known_hosts file or disable StrictHostKeyChec
 Inability to download file from xNF due to certificate problem
 """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
-When collecting files using HTTPS and DFC contains certs from CMPv2 server, an exception like "unable to find valid certification path to requested target" may occur.
-Except obvious certificates problems make sure, that xNF which are connecting to the DFC are supplied with certificates coming from the same ONAP unit where DFC was installed.
\ No newline at end of file
+When collecting files using HTTPS and DFC contains certs from CMPv2 server, an exception like "unable to find valid
+certification path to requested target" may occur. Except obvious certificates problems make sure, that xNF which
+are connecting to the DFC are supplied with certificates coming from the same CMPv2 server and the same CA which
+is configured on ONAP side and used by DFC.
+
+Inability to properly run DFC (v1.5.3 and above)
+""""""""""""""""""""""""""""""""""""""""""""""""
+
+Note, since DFC 1.5.3 FTPeS/HTTPS config blueprint was slighly changed.
+
+.. code-block:: json
+
+    "dmaap.ftpesConfig.*"
+
+was changed with
+
+.. code-block:: json
+
+    "dmaap.certificateConfig.*"
+
+Container update without updating DFC config (or blueprint) will result in inability to run DFC with FTPeS and HTTPS.