Fix Dockerfile to add config file and certs
[nonrtric/plt/sme.git] / capifcore / README.md
index 9242007..b4149f9 100644 (file)
 
 This product is a Go implementation of the CAPIF Core function, based on the 3GPP "29.222 Common API Framework for 3GPP Northbound APIs (CAPIF)" interfaces, see https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3450.
 
-The data used within CAPIF Core is shown in the diagram below.
+The, almost, complete data model for CAPIF is shown in the diagram below.
+
+<img src="docs/diagrams/Information model for CAPIF.svg">
+
+The data used within CAPIF Core for registering rApps that both provides and consumes services is shown in the diagram below.
 
 <img src="docs/diagrams/Information in rApp registration.svg">
 
-An example of how an rApp that both exposes and consumes services can be registered in CAPIF Core is shown in the sequence diagram below.
+Some examples of interactions between components using the CAPIF interface are shown in the sequence diagram below.
 
-***NOTE!*** It has not been decided that CAPIF Core will actually do the Helm chart installation and starting. This is just provided in the prototype as an example of what CAPIF Core could do. Before publisihing a service, the chart that belongs to the service must be registered in ChartMusem. When publishing the service the following information should be provided in the `ServiceAPIDescription::description` attribute; "namespace", "repoName", "chartName", "releaseName". An exaple of the information: "Description of rApp helloWorld,namespace,repoName,chartName,releaseName".
+***NOTE!*** It has not been decided that CAPIF Core will actually do the Helm chart installation. This is just provided in the prototype as an example of what CAPIF Core could do.
 
 <img src="docs/diagrams/Register Provider.svg">
 
+If Helm is used, before publishing a service, the chart that belongs to the service must be registered in ChartMuseum. When publishing the service the following information should be provided in the `ServiceAPIDescription::description` attribute; "namespace", "repoName", "chartName", "releaseName". An example of the information: "Description of rApp helloWorld,namespace,repoName,chartName,releaseName".
+
 ## Generation of API code
 
 The CAPIF APIs are generated from the OpenAPI specifications provided by 3GPP. The `generate.sh` script downloads the
@@ -53,14 +59,23 @@ To fix the specifications there are three tools:
 When a dependency to a new specification is introduced in any of the CAPIF specifications, see example below, the following steps should be performed:
 
 For the CAPIF specification "TS29222_CAPIF_Discover_Service_API" a new dependency like the following has been introduced.
-websockNotifConfig:
-&nbsp;&nbsp;&nbsp;&nbsp;$ref: '**TS29122_CommonData.yaml#/components/schemas/WebsockNotifConfig**'
 
-1. Copy the bold part of the reference and add it to the `definitions.txt` file. This step is not needed if the type is already defined in the file.
+    websockNotifConfig:
+        $ref: ✅TS29122_CommonData.yaml#/components/schemas/WebsockNotifConfig✅'
+
+1. Copy the part between the checkboxes of the reference and add it to the `definitions.txt` file. This step is not needed if the type is already defined in the file.
 2. Look in the `generate.sh` script, between the "<replacements_start>" and "<new_replacement>" tags, to see if "TS29122_CommonData"
    has already been replaced in "TS29222_CAPIF_Discover_Service_API".
 3. If it has not been replaced, add a replacement above the "<new_replacement>" tag by copying and adapting the two rows above the tag.
 
+### Security in CAPIF
+
+Security requirements that are applicable to all CAPIF entities includes provide authorization mechanism for service APIs from the 3rd party API providers and support a common security mechanism for all API implementations to provide confidentiality and integrity protection.
+
+In the current implementation Keycloak is being used as identity and access management (IAM) solution that provides authentication, authorization, and user management for applications and services. Keycloak provides robust authentication mechanisms, including username/password, two-factor authentication, and client certificate authentication that complies with CAPIF security requirements.
+
+A docker-compose file is included to start up keycloak.
+
 ## Build and test
 
 To generate mocks manually, run the following command:
@@ -87,6 +102,10 @@ The application can also be built as a Docker image, by using the following comm
 
 To run the Core Function from the command line, run the following commands from this folder. For the parameter `chartMuseumUrl`, if it is not provided CAPIF Core will not do any Helm integration, i.e. try to start any Halm chart when publishing a service.
 
-    ./capifcore [-port <port (default 8090)>] [-chartMuseumUrl <URL to ChartMuseum>] [-repoName <Helm repo name (default capifcore)>] [-loglevel <log level (default Info)>]
+    ./capifcore [-port <port (default 8090)>] [-secPort <Secure port (default 4433)>] [-chartMuseumUrl <URL to ChartMuseum>] [-repoName <Helm repo name (default capifcore)>] [-loglevel <log level (default Info)>] [-certPath <Path to certificate>] [-keyPath <Path to private key>]
+
+Use docker compose file to start Keycloak:
+
+    docker-compose up
 
-To run CAPIF Core as a K8s pod together with ChartMuseum, start and stop scipts are provided. The pod configurations are provided in the `configs` folder. CAPIF Core is then available att port `31570`.
+To run CAPIF Core as a K8s pod together with ChartMuseum, start and stop scripts are provided. The pod configurations are provided in the `configs` folder. CAPIF Core is then available on port `31570`.