diff options
| author |   Aleksandra Maciaga <aleksandra.maciaga@nokia.com> | 2020-05-12 09:58:35 +0200 |
|---|---|---|
| committer |   Adam Wudzinski <adam.wudzinski@nokia.com> | 2020-05-21 12:21:37 +0200 |
| commit | 3472d39bd861fc88c48a2f3217d73716b81f6ae3 (patch) | |
| tree | 70ced79c94a662cea9e6d17e04cb5893c324e27f /docs/sections/introduction.rst | |
| parent | 0c3c68ba16c8c1953247776e48072ff7668a7b02 (diff) | |
Fix documentation1.0.1
Issue-ID: AAF-1091
Signed-off-by: Aleksandra Maciaga <aleksandra.maciaga@nokia.com>
Change-Id: I057f20fa82057affae18dbaae5c0f4d0b979bde5
Diffstat (limited to 'docs/sections/introduction.rst')
| -rw-r--r-- | docs/sections/introduction.rst | 23 |
1 files changed, 14 insertions, 9 deletions
diff --git a/docs/sections/introduction.rst b/docs/sections/introduction.rst index 0b7e8d1b..9d6c7816 100644 --- a/docs/sections/introduction.rst +++ b/docs/sections/introduction.rst @@ -5,19 +5,12 @@ Introduction -============ +============= Overview -------- -The micro-service called CertService is designed for requesting certificates signed by external Certificate Authority (CA) using CMP over HTTP protocol. It uses CMPv2 client to send and receive CMPv2 messages. -CertService's client is also provided so other ONAP components (aka end components) can easily get certificate from CertService. End component is an ONAP component (e.g. DCAE collector or controller) which requires certificate from CMPv2 server to protect external traffic and uses CertService's client to get it. - -CertService's client communicates with CertService via REST API over HTTPS, while CertService with CMPv2 server via CMP over HTTP. - -To proof that CertService works Open Source CMPv2 server (EJBCA) is deployed and used in E2E tests. - -It is planned that Network Functions (aka xNFs) will get certificates from the same CMPv2 server and the same CA hierarchy, but will use own means to get such certificates. Cause xNFs and ONAP will get certificates signed by the same root CA and will trust such root CA, both parties will automatically trust each other and can communicate with each other. +In Frankfurt release AAF was enhanced by Certificate Management Protocol ver. 2 (CMPv2) support. Such support is handled by new AAF's microservice called CertService. CertService provides certificates signed by external CMPv2 server - further on such certificates are called operators certificates. Operators certificates are meant to secure external ONAP traffic - traffic between network functions (xNFs) and ONAP. Context View @@ -28,6 +21,18 @@ Context View :height: 315px :alt: CMPV2 Context View +It is planned that Network Functions (aka xNFs) will get certificates from the same CMPv2 server and the same CA hierarchy, but will use own means to get such certificates. Cause xNFs and ONAP will get certificates signed by the same root CA and will trust such root CA, both parties will automatically trust each other and can communicate with each other. + + +Functionality +------------- In Frankfurt release only `Initialization Request <https://tools.ietf.org/html/rfc4210#section-5.3.1>`_ with `ImplicitConfirm <https://tools.ietf.org/html/rfc4210#section-5.1.1.1>`_ is supported. + Request sent to CMPv2 server is authenticated by secret value (initial authentication key) and reference value (used to identify the secret value) as described in `RFC-4210 <https://tools.ietf.org/html/rfc4210#section-4.2.1.2>`_. + + +Security considerations +----------------------- + +CertService's REST API is protected by mutual HTTPS, meaning server requests client's certificate and **authenticate** only requests with trusted certificate. After ONAP default installation only certificate from CertService's client is trusted. **Authorization** isn't supported in Frankfurt release.
\ No newline at end of file |