[3SP] Add RBAC integration to OpenCMW and integrate with GNU Radio

[ivan-cukic]

1. Goal: Extend Keycloak's OAuth2 infrastructure to use public-private key pairs associated with roles, enabling message signing and authentication across multiple services without the need for services to handle sensitive user information or require privileged Keycloak admin access. Note: services are developed by various contributors, can run independently (w/o further privileged access to other infrastructure), and only operational deployment is secured.
2. Process:
   • Key Generation: Users generate public-private key pairs, retain the private key for signing requests, and forward the public key and username to the service-OAuth endpoint.
   • Token Issuance: The service issues OAuth2 tokens via Keycloak, embedding the user’s roles. User identity is securely managed by Keycloak.
   • Public Key Storage: The service stores role-mapped public keys in a secure key registry managed externally or by a dedicated service. The registry must only be modifiable by authorised services to prevent unauthorised additions.
   • Request Signing: Users sign requests using their private key and include the hash, role, public key, expiry, and other meta-information in the RBAC field of the MDP message protocol.
   • Verification: The service retrieves (with appropriate caching, invalidation, and expiry mechanisms) the relevant public keys from the role-based key registry. It verifies both the OAuth2 token and the signed message. If the public key is unavailable in the registry, the request is immediately rejected. Initially, the service may also implement a local/private key-cache that is later shared with other services (N.B. similar to the DNS info).
3. Public Key Registry Example:

   {
   "role1": [
   {
     "publicKey": "PUBLIC_KEY_1",
     "expiresAt": "2024-12-31T23:59:59Z"
   },
   {
     "publicKey": "PUBLIC_KEY_2",
     "expiresAt": "2025-06-30T23:59:59Z"
   }
   ],
   "role2": [
   {
     "publicKey": "PUBLIC_KEY_3",
     "expiresAt": "2024-11-30T23:59:59Z"
   }
   ]
   }

4. Security:
   • The key registry is secured using strong authentication mechanisms, such as location-based access control, shared secrets, or mutual TLS (mTLS).
   • Key rotation and expiry mechanisms ensure the security and integrity of the keys.
   • Logging and monitoring are implemented to detect and address unauthorised access attempts promptly.

[RalphSteinhagen]

N.B. most of the work should be tackled in opencmw-cpp. GNU Radio is secured via the OpenCMW service property as entry points but does internally not need to be changed.

There may be some follow-up w.r.t. the UI integration/client in OpenDigitizer.