Non-RT RIC
Summary
The Non-RealTime RIC (RAN Intelligent Controller) is an Orchestration and Automation function described by the O-RAN Alliance for non-real-time intelligent management of RAN (Radio Access Network) functions.
The primary goal of the Non-RealTime RIC is to support non-real-time radio resource management, higher layer procedure optimization, policy optimization in RAN, and providing guidance, parameters, policies and AI/ML models to support the operation of near-RealTime RIC functions in the RAN to achieve higher-level non-real-time objectives.
Non-RealTime RIC functions include service and policy management and RAN analytics for the RAN. The Non-RealTime RIC platform hosts and coordinates rApps (Non-RT RIC applications) to perform Non-RealTime RIC tasks. The Non-RealTime RIC also hosts the new R1 interface (between rApps and SMO/Non-RealTime-RIC services).
The O-RAN-SC (OSC) NONRTRIC project provides concepts, architecture and reference implementations as defined and described by the O-RAN Alliance architecture. The OSC NONRTRIC implementation communicates with near-RealTime RIC elements in the RAN via the A1 interface. Using the A1 interface the NONRTRIC will facilitate the provision of policies for individual UEs or groups of UEs; monitor and provide basic feedback on policy state from near-RealTime RICs; provide enrichment information as required by near-RealTime RICs; and facilitate ML model training, distribution and inference in cooperation with the near-RealTime RICs. The OSC NONRTRIC hosts rApps, and coordinates all interactions between the rApp and underlying SMo by way of the R1 Interface.
Find detailed description of the NONRTRIC project see the O-RAN SC NONRTRIC Project Wiki.
NONRTRIC Components
These are the components that make up the Non-RT-RIC:
Non-RT-RIC Service Exposure Security Architecture Prototyping. (Documentation site).
DMaaP/Kafka Information Producer Adapters. (Documentation site adapter), (Documentation site mediator).
Service Management & Exposure (SME) (CAPIF). (Documentation site).
RAN Performance Monitoring Functions (File-based PM) (Documentation site).
-
“Helloworld” O-RU Fronthaul Recovery use case. (Documentation site).
“Helloworld” O-DU Slice Assurance use case. (Documentation site).
Non-RT-RIC Control Panel / NONRTRIC Dashboard
Graphical user interface.
View and Manage A1 policies in the RAN (near-RT-RICs)
Graphical A1 policy creation/editing is model-driven, based on policy type’s JSON schema
View and manage producers and jobs for the Information coordinator service
Configure A1 Policy Management Service (e.g. add/remove near-rt-rics)
Interacts with the A1-Policy Management Service & Information Coordination Service (REST NBIs) via Service Exposure gateway
Implementation:
Frontend: Angular framework
Repo: portal/nonrtric-controlpanel
Documentation at the NONRTRIC-Portal documentation site.
Information Coordination Service
The ICS is a data subscription service which decouples data producers from data consumers. A data consumer can create a data subscription (Information Job) without any knowledge of its data producers (one subscription may involve several data producers). A data producer has the ability to produce one or several types of data (Information Type). One type of data can be produced by zero to many producers.
A data consumer can have several active data subscriptions (Information Job). One Information Job consists of the type of data to produce and additional parameters, which may be different for different data types. These parameters are not defined or limited by this service.
Maintains a registry of:
Information Types / schemas
Information Producers
Information Consumers
Information Jobs
The service is not involved in data delivery and hence does not put restrictions on this.
Implementation:
Implemented as a Java Spring Boot application.
Repo: nonrtric/plt/informationcoordinatorservice.
Documentation at the Information Coordination Service site.
A1 Policy Management Service (from ONAP CCSDK)
A1 Controller Service above A1 Controller/Adapter that provides:
Unified REST & DMaaP NBI APIs for managing A1 Policies in all near-RT-RICs.
Query A1 Policy Types in near-RT-RICs.
Create/Query/Update/Delete A1 Policy Instances in near-RT-RICs.
Query Status for A1 Policy Instances.
Maintains (persistent) cache of RAN’s A1 Policy information.
Support RAN-wide view of A1 Policy information.
Streamline A1 traffic.
Enable (optional) re-synchronization after inconsistencies / near-RT-RIC restarts.
Supports a large number of near-RT-RICs (& multi-version support).
Converged ONAP & O-RAN-SC A1 Adapter/Controller functions in ONAP SDNC/CCSDK (Optionally deploy without A1 Adapter to connect direct to near-RT-RICs).
Support for different Southbound connectors per near-RT-RIC - e.g. different A1 versions, different near-RT-RIC version, different A1 adapter/controllers supports different or proprietary A1 controllers/EMSs.
Implementation:
Implemented as a Java Spring Boot application.
Repo: nonrtric/plt/a1policymanagementservice.
Documentation at the A1 Policy Management Service documentation site.
A1/SDNC Controller & A1 Adapter (Controller plugin)
Mediation point for A1 interface termination in SMO/NONRTRIC.
Implemented as CCSDK OSGI Feature/Bundles.
A1 REST southbound.
RESTCONF Northbound.
NETCONF YANG > RESTCONF adapter.
SLI Mapping logic supported.
Can be included in an any controller based on ONAP CCSDK.
Implementation:
Repo: nonrtric/plt/sdnca1controller
A1 Interface / Near-RT-RIC Simulator
Stateful A1 test stub.
Used to create multiple stateful A1 providers (simulated near-rt-rics).
Supports A1-Policy and A1-Enrichment Information.
Swagger-based northbound interface, so easy to change the A1 profile exposed (e.g. A1 version, A1 Policy Types, A1-E1 consumers, etc).
All A1-AP versions supported.
Implementation:
Implemented as a Python application.
Repo: sim/a1-interface.
Documentation at the A1 Simulator documentation site.
(Spring Cloud) Service Gateway
Support Apps to use A1 Services.
Spring Cloud Gateway provides the library to build a basic API gateway.
Exposes A1 Policy Management Service & Information Coordinator Service.
Additional predicates can be added in code or preferably in the Gateway yaml configuration.
Implementation:
Implemented as a Java Spring Cloud application.
Repo: portal/nonrtric-controlpanel.
Service Exposure Security Architecture Prototyping
Support Apps to use NONRTRIC, SMO and other App interfaces. A building block for coming releases as the R1 Interface concept matures .
Support dynamic registration and exposure of service interfaces to Non-RT-RIC applications (& NONRTRIC Control panel).
The architecture and components are defined in Non-RT RIC Security Architecture Prototyping (Documentation site).
Works with the CAPIF Service Management & Exposure (SME). Documentation site functions.
DMaaP Information Producer Adapters (Kafka)
Configurable mediators to take information from DMaaP and Kafka and present it as a coordinated Information Producer.
These mediators/adapters are generic information producers, which register themselves as information producers of defined information types in Information Coordination Service (ICS). The information types are defined in a configuration file. Information jobs defined using ICS then allow information consumers to retrieve data from DMaaP MR or Kafka topics (accessing the ICS API).
There are two alternative implementations to allow Information Consumers to consume DMaaP or Kafka events as coordinated Information Jobs.
Implementation:
Implementation in Java Spring (DMaaP Adapter), repo: nonrtric/plt/dmaapadapter, see DMaaP Adapter documentation site.
Implementation in Go (DMaaP Mediator Producer), repo: nonrtric/plt/dmaapmediatorproducer, see DMaaP Mediator Producer documentation site.
Initial App Catalogue
Register for Non-RT-RIC Apps.
Non-RT-RIC Apps can be registered / queried.
Limited functionality/integration for now.
More work required in coming releases as the rApp concept matures.
Implementation:
Implemented as a Java Spring Boot application and in Python.
Repo: nonrtric/plt/rappcatalogue
Documentation at the rApp Catalogue documentation site.
Initial Kubernetes Helm Chart LCM Manager
Onboard, start, stop, and modify Non-RT-RIC App microservices as Helm Charts. A building block for coming releases as the RAPP concept matures.
Interfaces that accepts Non-RT-RIC App microservices Helm Charts.
Support basic LCM operations.
Onboard, Start, Stop, Modify, Monitor.
Initial version co-developed with v. similar functions in ONAP.
Limited functionality/integration for now.
Implementation:
Implemented as a Java Spring Boot application.
Repo: nonrtric/plt/helmmanager
Documentation at the Helm Manager documentation site.
Service Management and Exposure (CAPIF)
An initial implementation of the CAPIF Core service. It implements the following CAPIF APIs:
API Provider Management
Publish Service
Discover Service
API Invoker Management
Security
Events
Implementation:
Implemented in Go
Repo: nonrtric/plt/sme
Documentation at the Service Management & Exposure (SME) documentation site.
Authentication Support (Keycloak)
The auth-token-fetch provides support for authentication. It is intended to be used as a sidecar and does the authentication procedure, gets and saves the access token in the local file system. This includes refresh of the token before it expires. This means that the service only needs to read the token from a file.
It is tested using Keycloak as authentication provider.
So, a service just needs to read the token file and for instance insert it in the authorization header when using HTTP. The file needs to be re-read if it has been updated.
The auth-token-fetch is configured by the following environment variables.
CERT_PATH - the file path of the cert to use for TSL, example: security/tls.crt
CERT_KEY_PATH - the file path of the private key file for the cert, example: “security/tls.key”
ROOT_CA_CERTS_PATH - the file path of the trust store.
CREDS_GRANT_TYPE - the grant_type used for authentication, example: client_credentials
CREDS_CLIENT_SECRET - the secret/private shared key used for authentication
CREDS_CLIENT_ID - the client id used for authentication
OUTPUT_FILE - the path where the fetched authorization token is stored, example: “/tmp/authToken.txt”
AUTH_SERVICE_URL - the URL to the authentication service (Keycloak)
REFRESH_MARGIN_SECONDS - how long in advance before the authorization token expires it is refreshed
RApp Manager Service
Early version of a service to manage rApps and rApp instances.
Manages the entire lifecycle and state of rApp and thie instances
Integrated with NONRTRIC Data Management & Exposure functions (ICS)
Integrates with NONRTRIC Service registration and discovery functions (SME CAPIF)
Also add new ONAP ACM participants to handle rApp composition elements
Implementation:
Implemented as a Java Spring Boot application.
Repo: nonrtric/plt/rappmanager
Documentation at the Non-RT RIC rApp Manager documentation site.
RAN Performance Monitoring Functions (File-based PM)
Functions to collect/parse/filter/store/forward file-based & event-based RAN PM data:
End-to-end tool-chain to collection, parsing, filtering and delivery of file-based RAN PM observability data
PM report data format defined by 3GPP (TS 32.432 and 3GPP TS 32.435)
High performance, fully scalable
Subscribers (e.g. rApps) can subscribe for chosen measurement types from specific resources in the network
Implementation:
Implemented in Go, Java and Python
Repo: nonrtric/plt/ranpm
Documentation at the Non-RT RIC RAN PM Usecase / Functions documentation site.
Non-RT-RIC Test Framework
A full test environment with extensive test cases/scripts can be found in the test directory in the nonrtric source code.
Non-RT-RIC Use Cases
“Helloworld” O-RU Fronthaul Recovery use case
A very simplified closed-loop rApp use case to re-establish front-haul connections between O-DUs and O-RUs if they fail. Not intended to to be ‘real-world’.
Implementation:
One version implemented in Python, one in Go as an Information Coordination Service Consumer, and one as an apex policy.
Repo: nonrtric/rapp/orufhrecovery
Documentation at the O-RU Fronthaul Recovery documentation site.
“Helloworld” O-DU Slice Assurance use case
A very simplified closed-loop rApp use case to re-prioritize a RAN slice’s radio resource allocation priority if sufficient throughput cannot be maintained. Not intended to to be ‘real-world’.
Implementation:
One version implemented in Go as a micro service, one in Go as an Information Coordination Service Consumer.
Repo: nonrtric/rapp/ransliceassurance
Documentation at the O-DU Slice Assurance documentation site.
Developer Guide
This document provides a quickstart for developers of the Non-RT RIC parts.
Additional developer guides are available on the O-RAN SC NONRTRIC Developer wiki.
Kubernetes deployment
Non-RT RIC can be also deployed in a Kubernetes cluster, it/dep repository. hosts deployment and integration artifacts. Instructions and helm charts to deploy the Non-RT-RIC functions in the OSC NONRTRIC integrated test environment can be found in the ./nonrtric directory.
For more information on installation of NonRT-RIC in Kubernetes, see Deploy NONRTRIC in Kubernetes.
For more information see Integration and Testing documentation in the O-RAN-SC.
API-Docs
Descriptions of the APIs to the Non-RT RIC functions can be found in the repos for the functions.
Use Cases
To support the use cases defined for the Non-RT RIC, there are implementations provided in the Non RT-RIC project.
Health Check
The Health Check use case for the Non-RT RIC is a python script that regularly creates, reads, updates, and deletes a policy in all Near-RT RICs that support the type used by the script. A self refreshing web page provides a view of statistics for these regular checks.
For more information about it, see the README file in repo.
O-RU Front-Haul Recovery
This use case is a non-real-world closed-loop use case to demonstrate automated recovery when the front-haul connection between an O-DU and O-RU is reset. An application in the NONRTRIC senses the fault from the O-RU (O1-FM) and initiates a NETCONF reset operation (O1-CM) using the OAM controller. More details about the use case can be found on the O-RAN SC wiki: RSAC and OAM.
Non-RT RIC provides multiple implementation versions of the recovery part of the use case. One in the form of a python script, one utilizing the ONAP Policy Framework, and one Go version that utilizes Information Coordination Service (ICS).
The code is available in the use case repo
Standalone Script Solution
The script version consists of a python script that performs the tasks needed for the use case. There are also two simulators. One message generator that generates alarm messages, and one SDN-R simulator that receives the config change messages sent from the script and responds with alarm cleared messages to MR.
All parts are Dockerized and can be started as individual containers, in the same network, in Docker.
ONAP Policy Solution
There is also another solution for performing the front-haul recovery that is based on ONAP Policy Framework. A TOSCA Policy has been created that listens to DMaaP Message Router, makes a decision on an appropriate remedy and then signals the decision as a configuration change message via REST call to the OAM controller.
There is a docker-compose available in the nonrtric repo for bringing up the complete standalone version of ONAP Policy Framework.
The detailed instructions for deploying and running this policy are provided in the wiki.
ICS Consumer Solution
The ICS Consumer solution is implemented in Go and instead of polling MR itself, it registers as a consumer of the “STD_Fault_Messages” job in ICS.
Requirements for the Non-RT RIC project
Find detailed description of what Non-RT RIC is on this page.
The NONRTRIC project (and the O-RAN Non-RealTime RIC function) can be considered from a number of different viewpoints. This page presents some of these views:
Scope 1: A1 Controller (Mediator, Endpoint)
Southbound: Provide termination point for A1 interface(s) - REST endpoint for messages to/from Near-RealTime RIC
Northbound: Provide a more generic interface for A1 operations - provide interface to rApps, without the need for A1 message generation, addressing, coordination, mediation, etc.
O1 interfaces do not terminate in NONRTRIC function (but may terminate in same controller host/instance)
Scope 2: Coordinate/Host A1 Policy Management Services
Map high level RAN goal/intent directives to finely-scoped A1 Policies towards individual Near-RT RIC instances
Informed by observed RAN context (provided over O1 via OAM functions), and other external context (via other SMO functions)
Dynamically coordinate life cycles of A1 Policies in individual Near-RT RICs as contexts change
Scope 3: Coordinate ML/AI Models - In RAN (“E2 nodes” & Near-RT RICs) and NONRTRIC (future)
Acts as model-training host
May act as model-inference host (others: Near-RT RICs, “E2 nodes”)
Dynamically coordinate ML/AI model lifecycle management (e.g. re-train, re-deploy, etc)
Models are (always?) deployed over O1 interface
Scope 4: Enrichment Data Coordinator
Additional context that is unavailable to Near-RT RICs (e.g. RAN data, SMO context, External context)
Dynamically coordinate access and pass data to appropriate Near-RT RICs (e.g. for use in ML/AI model inference)
Scope 5: rApp Host & rApp Coordinator
rApps may act as, or form part of, NONRTRIC- or SMO-level applications
rApps, via rApp host function, may consume many other services - some from the NONRTRIC platform, some from the SMO platform, and some from other rApps
Dynamically coordinate rApp lifecycle management
Scope 6: Provide R1 interface for rApps
rApps may only consume services over the R1 interface (from NONRTRIC platform, or from SMO platform, or from other rApps)
Platform services and services optionally provided by rApps must be exposed over the R1 Interface
These services may be “standardized” R1 services or R1 extensions (some may be proprietary)
Installation Guide
Abstract
This document describes how to install some of the Non-RT RIC components, their dependencies and required system resources.
Software Installation and Deployment
Install with Helm in Kubernetes
The easiest and preferred way to install NONRTRIC functions is using Kubernetes, with installation instructions provided in Helm Charts. Full details of how to install NONRTRIC functions are provided in Deploy NONRTRIC in Kubernetes.
Helm charts and an example recipe are provided in the it/dep repo, under “nonrtric”. By modifying the variables named “installXXX” in the beginning of the example recipe file, which components that will be installed can be controlled. Then the components can be installed and started by running the following command:
bin/deploy-nonrtric -f nonrtric/RECIPE_EXAMPLE/example_recipe.yaml
Install with Docker
Some NONRTRIC functions, and simpler usecases can be install directly using Docker. Full details of how to use Docker for NONRTRIC functions are provided in Deploy NONRTRIC in Docker.
Install with Docker Compose
Some older docker compose files are provided, in the “docker-compose” folder, to install the components. Run the following command to start the components:
docker-compose -f docker-compose.yaml -f policy-service/docker-compose.yaml -f ics/docker-compose.yaml
The example above is just an example to start some of the components. For more information on running and configuring the functions can be found in the README file in the “docker-compose” folder, and on the wiki page
Release-Notes
This document provides the release notes for the release of the different parts of the Non-RT RIC.
Prior to release F several functions were homed in this repository, and released from here. Currently the only function released from here is the “Auth Token Fetch” utility image (see below).
Functions, previously here, but now with their own repos have their own release notes:
DMaaP/Kafka Information Producer Adapters. DMaaP Adapter. DMaaP Mediator Producer.
Use Cases:
Release-Notes for just the nonrtric repo
Bronze
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/2466f9d370214b578efedd1d3e38b1de17e6ca1c |
Release designation |
Bronze |
Release date |
2020-06-18 |
Purpose of the delivery |
Improved stability |
Bronze Maintenance
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/5d4f252a530a0d9abbf2a363354c5e56e8f2f33e |
Release designation |
Bronze |
Release date |
2020-07-29 |
Purpose of the delivery |
Introduce configuration of certificates |
Cherry
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/90ce16238dd6970153e1c0fbddb15e32c68c504f |
Release designation |
Cherry |
Release date |
2020-12-03 |
Purpose of the delivery |
Introduction of Enrichment Service Coordinator and rAPP Catalogue |
D
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/dd3ebfd784e96919a00ddd745826f8a8e074c66f |
Release designation |
D |
Release date |
2021-06-23 |
Purpose of the delivery |
Improvements Introduction of initial version of Helm Manager |
D Maintenance
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/973ae56894fb29a929fba9e344cae42e7607087b |
Release designation |
D |
Release date |
2021-08-10 |
Purpose of the delivery |
Minor bug fixes |
E Release
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/b472c167413a55a42fc7bfa08d2138f967a204fb |
Release designation |
E |
Release date |
2021-12-13 |
Purpose of the delivery |
Improvements and renaming. Introduction of more usecase implementations. |
E Maintenance Release
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/4df1f9ca4cd1ebc21e0c5ea57bcb0b7ef096d067 |
Release designation |
E |
Release date |
2022-02-09 |
Purpose of the delivery |
Improvements and bug fixes |
F Release
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/46f2c66ed30ceef4cedd7992b88c9563df0f24a5 |
Release designation |
F |
Release date |
2022-08-18 |
Purpose of the delivery |
First version of nonrtric-plt-auth-token-fetch |
H Release
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/3db8626c0900dc391b8e810541de9761c78043d8 |
Release designation |
H |
Release date |
2023-06-16 |
Purpose of the delivery |
nonrtric-plt-auth-token-fetch:1.1.1 Updated Springboot version |
I Release
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric |
Note |
|
Security Architecture Prototyping
Introduction
The O-RAN (Open Radio Access Network) security architecture is a framework for securing the communication between different components of an open system. It is designed to ensure the confidentiality, integrity, and availability of data and services, while also providing protection against potential security threats. This involves securing the communication between different components, including encryption, authentication, and access control. The O-RAN security architecture is designed to be flexible, scalable, and interoperable, enabling different vendors to integrate their solutions into the O-RAN ecosystem while maintaining security.
Here are some key features provided by the platform:
MTLS provides secure encrypted communication and mutual authentication of peers.
Users are authenticated using a client via the OpenID Connect (OIDC) protocol.
OAuth 2.0 is a framework that controls authorization for access of services.
Apps (rApps) need to use Service Management & Orchestration (SMO) services and provide services to other Apps. Apps & SMO services may be multivendor. The goal of the Security Architecture is to provide selective & controlled exposure of these services.
Ensure that services cannot be accessed without a valid token.
Ensure that inter-services communication is done using mTLS.
Ensure the automated setup and configuration of security prior to app deployment.
This product is a part of NONRTRIC.
Components
Istio
App security relies on Istio service mesh to enforce mTLS between applications. The applications running in the cluster are not required to implement mTLS, instead this is done by attaching an Istio sidecar to the running containers. mTLS communication is done between the sidecars.
Keycloak
Keycloak is an open-source identity and access management tool. It is used to issue access tokens to the apps. The access token comes in the form of a JWT which includes claims or fields which are used to determine the access level to grant to a particular app.
Access tokens (JWT) are retrieved using Keycloak clients.
Access token has limited lifetime (needs to be refreshed).
Access token is sent in the HTTP header is each REST call.
This is an example of a JWT payload:
{
"exp": 1683628065,
"iat": 1683627765,
"jti": "b61ae49d-5a73-4e91-96f2-de3b400a5779",
"iss": "https://keycloak:8443/realms/demo",
"sub": "e7709f80-61bd-4440-a265-d51c4fed8ece",
"typ": "Bearer",
"azp": "demoprovider-cli",
"session_state": "89ac7390-2865-4e07-bd1a-aea43c43827a",
"scope": "email",
"sid": "89ac7390-2865-4e07-bd1a-aea43c43827a",
"clientHost": "127.0.0.6",
"clientId": "demoprovider-cli",
"email_verified": false,
"clientRole": [
"provider-viewer"
],
"clientAddress": "127.0.0.6"
}
Postgres
Postgres is used as the back-end database for Keycloak, it will persistent the Keycloak objects that have been created.
Cert Manager
Cert Manager is used to provide both server and client certificates for Keycloak. It also provides certificates for the webhook server.
Chart Museum
Chart museum is used to stores the Helm charts for the apps.
Helm Installer
Helm installer is used to automate the installation of the Helm charts. Each chart contains an app configuration section in the values.yaml file which is used by Istio manager and Keycloak manager.
Istio Manager
Istio manager is used to automate the setup of Gateways, Virtual Services, Authorization Policies and Request Authentication polices for the apps. The exact configuration required is read from the values.yaml file in the Helm chart.
Keycloak Manager
Keycloak manager is used to automate the setup of realms, clients, users, role mappings and authentication flows. Keycloak provides REST API endpoints for creating and deleting these objects. The exact configuration required is read from the values.yaml file in the Helm chart.
JWT Proxy Controller
The Jwt Proxy Admission Controller determines whether to attach a jwt proxy sidecar to the app container based on the app label. If permitted the exact configuration required is read from the values.yaml file in the Helm chart.
Request Flow
Provider App
When a provider app is installed using Helm manager, all the necessary security is automatically setup prior to deployment.
- Helm manager calls Istio manager and sets up the following Istio services:
Gateway: a load balancer operating at the edge of the mesh receiving incoming or outgoing HTTP/TCP connections.
VirtualService: routes request from the gateway to the app.
RequestAuthentication: verifies the issuer and jwksUri of the JWT.
AuthorizationPolicy: authorizes incoming requests based on claims in the JWT.
- Helm manager calls Keycloak manager and sets up the following Keycloak objects:
Realm : represents a set of users, credentials, roles, groups and clients. Realms can be used to isolated different apps from each other.
Client: used to authenticate a user and retrieve a JWT.
Role Mapper: maps the user role(s) to the token. These role(s) are used during app authorization.
- Clients support 4 authenticator types:
Client Secret
x509 certificate
JWT signed with certificate
JWT signed with secret
Depending on the app configuration it will either setup an x509 client, a jwt client or a secret client.
Note
If the app is configured to use the x509 authenticator, a direct flow grant for x509 is also setup to check fields in x509 certificate against some pre-defined value(s).
Invoker App
When an invoker app is installed using Helm manager, the app label is used to determine whether to inject the deployment with a jwt proxy sidecar. If the app label has been whitelisted the proxy is added to the container. The jwt proxy sidecar will automatically retrieve the token required to access the app provider and include it in the request header.
This is an example of a provider and invoker running in a cluster:
Note
Security for service registry and management using the 3GPP Common API framework is available here: Service Management & Exposure (SME) documentation site.