Merge branch 'OCF-Doc74-update-pictures-of-ocf' into 'develop'

### Where is the registration done?

Registration is done in a REST API outside of the CAPIF specification taht we have implemented.

Registration is done in a REST API outside of the CAPIF specification that we have implemented.

### Is the username and password chosen by the user when registering or is it assigned when requesting registration to CAPIF public instance?

### When doing the register_provider where can I find the CSRs that are generated?

When using the "register_provider" command, if you add the "debug" option, it shows you a json with the data used to register the provider. There we can find in the body a list of 3 elements corresponding to AEF, APF and AMF. IN each of them, the apiProbPubKey field corresponds to the CSR.

When using the "register_provider" command, if you add the "debug" option, it shows you a json with the data used to register the provider. There we can find in the body a list of 3 elements corresponding to AEF, APF and AMF. In each of them, the apiProbPubKey field corresponds to the CSR.

### How to use the example client (CAPIF_INVOKER_GUI)?

### What is the purpose of the "get_security_auth" function in the invoker client?

Sirve para pedir el token o para refrescarlo en caso de que haya caducado. You have to use that token to call the API from the invoker.

It is used to request the token or refresh it in case it has expired. You have to use that token to call the API from the invoker.

### What is the purpose of the "register_security_context" function in the invoker client?

<img src="../images/logos/OpenCAPIF.png" alt="drawing" width="200"/>

# **Architecture**

The CAPIF architecture has three main components, Register Service, Vault and CCF, which are represented in the following image:

![New Architecture](./images/architecture/New_Architecture.png)

Each component is separated into different namespaces and all communications between them use Rest APIs.

Apart from the communication between components, there are 2 other entities that can use them:

- **Admin/superadmin**: Responsible for managing users with the Register or carrying out special operations in the CCF.

- **Users**: They are those who want to use CAPIF, registering as a user in the Register and as Invoker or Provider in the CCF.

## **Register NS**

This namespace belongs to the Register service, and we find 2 components:

- **Register Service**: It is responsible for managing all users who use CAPIF, in addition to providing the necessary information for its use.

- **Register MONGO DATABASE**: It is the Register database, in it we store all the information about registered users.

## **Vault NS**

This namespace belongs to Vault. 

This component is responsible for managing all CAPIF certificates, so other components such as the Register or the CCF communicate with it to create new certificates or request keys.

## **Mon NS**

This is the main namespace of CAPIF, since it contains all the CCF services in addition to other components:

- **NGINX**: Responsible for acting as a reverse proxy to distribute CAPIF requests to the different services, controlling whether or not they are authorized to access them.

- **REDIS**: Used for internal communication of services.

- **CAPIF MONGO DATABASE**: CAPIF database, where all information related to CAPIF services such as invokers, registered providers or published services is stored.

- **HELPER**: Service that simplifies integration with third parties such as external management portals.

## **New Architecture**

You can check the details of all these changes in the conversation on the [OCF wiki](https://labs.etsi.org/rep/ocf/community/-/wikis/New%20architecture).

<img src="../../assets/images/logos/OpenCAPIF.png" alt="drawing" width="200"/>

# **Architecture**

The CAPIF architecture has three main components, Register Service, Vault and OpenCAPIF Core, which are represented in the following image:

![New Architecture](../assets/images/architecture/Architecture.png)

Each component is separated into different namespaces and all communications between them use Rest APIs.

Apart from the communication between components, there are 2 other entities that can use them:

- **Admin/superadmin**: Responsible for managing users with the Register or carrying out special operations in the OpenCAPIF Core.

- **Users**: They are those who want to use CAPIF, registering as a user in the Register and as Invoker or Provider in the OpenCAPIF Core.

## **Vault NS**

This namespace belongs to Vault. 

This component is responsible for managing all CAPIF certificates, so other components such as the Register or OpenCAPIF Core communicate with it to create new certificates or request keys.

## **OpenCAPIF NS**

This namespace belongs to the Register service, and all OpenCAPIF micro-services. We can find 2 main components:

- **Register Service**: It is responsible for managing all users who use CAPIF, in addition to providing the necessary information for its use.

- **OpenCAPIF Services**: This is the core function of OpenCAPIF.

### **Register Component**

The Register component consists in 2 main services:

- **Register Service**: This contains all logic to manage and give access to users:

  - **Admin Role**: Admin can create, delete or list users.

  - **User Role**: User created by admin, can request access to OpenCAPIF, this will give JWT Token and all endpoints accessible by that user to interact with OpenCAPIF Core.

- **Register DB**: This DB stores all user information.

This component will expose a URL at K8s ingress to access it.

### **OpenCAPIF Services**

The OpenCAPIF Component consists of 12 services, each one related to one API:

- **CAPIF Discover Service**: Allows API invokers to search for and discover published APIs based on query filters, retrieving API metadata and interface information.

- **CAPIF Publish Service**: Allows API providers to publish, update and unpublish their APIs in the CAPIF Core, making them discoverable to authorized invokers.

- **CAPIF Events Service**: Enables API invokers to subscribe to CAPIF events. It supports event subscription and unsubscription and can optionally send event notifications.

- **CAPIF Invoker Management Service**: Handles onboarding and offboarding of API invokers, including registration of invoker profiles and management of their status.

- **CAPIF Security Service**: Acts as the access control point of the CAPIF Core, validating API invocations and enforcing authorization policies.

- **CAPIF Logging Service**: Intercepts and stores logs of API invocations for monitoring, troubleshooting and compliance purposes.

- **CAPIF Auditing Service**: Provides audit capabilities for service API invocations to support accountability and traceability.

- **CAPIF Access Control Policy Service**: Manages access control policies that define which API invokers can access which published APIs and under what conditions.

- **CAPIF Provider Management Service**: Handles registration and management of API providers, including their profile and the APIs they own.

- **CAPIF Routing Info Service**: Provides routing information to API invokers, so they can locate the correct API Exposing Function (AEF) endpoint for a given published API.

- **CAPIF Open Discover Service**: Enables API invokers external to the CAPIF domain to discover published APIs, for use in interconnection scenarios.

- **Helper Service**: Service that simplifies integration with third parties such as external management portals.

Also this component deploys some side services:

- **NGINX**: Responsible for acting as a reverse proxy to distribute CAPIF requests to the different services, controlling whether or not they are authorized to access them.

- **REDIS**: Used for internal communication of services.

- **Celery**: This component is responsible for sending event messages when eventReq feature is active.

- **CAPIF DB**: CAPIF database, where all information related to CAPIF services such as invokers, registered providers or published services is stored.

    - Modifying specific parameters.

    - Adding or updating configuration settings dynamically.

By this Helper Service, CAPIF users can effortlessly retrieve and manage critical system information, improving overall visibility and efficiency.

Through this Helper Service, CAPIF users can effortlessly retrieve and manage critical system information, improving overall visibility and efficiency.

## API Documentation

For a detailed API reference, please check the **Helper Service Swagger Documentation**:

➡️ [Helper Service API Documentation](../helper/swagger.md)

➡️ [Helper Service API Documentation](./swagger.md)