[5SP] 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.

[vimpostor]

Some addendums from the meeting:

• To avoid the worker having to iterate through potentially a lot of public keys while validating an mdp message, the client should probably also include an id or hash of the used public key in the mdp message. The ID of the key pair should be generated server side (to ensure uniqueness) as soon as the initial OAuth authorization request succeeds and sent back to the client in the response. The private/public key pair is obviously still generated client-side. This implies that the public key storage looks a little something more like this:

  {
  "role1": [
  {
    "uuid": "UUID_1",
    "publicKey": "PUBLIC_KEY_1_DATA",
    "expiresAt": "2024-12-31T23:59:59Z"
  },
  {
    "uuid": "UUID_3849384",
    "publicKey": "PUBLIC_KEY_2_DATA",
    "expiresAt": "2025-06-30T23:59:59Z"
  }
  ],
  "role2": [
  {
    "uuid": "UUID_3284938",
    "publicKey": "PUBLIC_KEY_3_DATA",
    "expiresAt": "2024-11-30T23:59:59Z"
  }
  ]
  }

• The public key of the client should be sent on the initial OAuth request already. This is the only way to guarantee that the OAuth callback corresponds to the actually sent key (which means that we put the correct key into storage, instead of an attacker spoofing their own public key inbetween), as we can put the public key into the extra state field of the OAuth request, which will be included in the callback from the OAuth compliant implementation (at the moment, read: Keycloak).
• In our workflow the actual OAuth access token only plays a minor role and probably doesn't even need to be transmitted back to the client. In fact, it is probably better to remove this as any adversaries listening in on the channel also get the token and by leaving it in the protocol we create a false sense of security associated to the access token. In our usecase the access token is only necessary on the OAuth worker side to make sure that the client is authenticated. Every further authentication from that point on is based on the private/public key pair, and the integrity of the public key storage is already secured by means of that access token.
• The connection between the OAuth worker and the public key storage MUST be a secure channel, as there is no further authentication happening between the two and it is very easy to mess this up by accidentally allowing any random adversarial worker to add a public key to the storage. This means that we likely want the public key storage to just be another thread in the same process as the OAuth worker, where we can then just not add any external interface to add keys from the outside at all, mitigating this attack completely.
• For the private/public key cryptography libsodium probably makes the most sense, as it provides state-of-the-art elliptic curve cryptography (which usually requires smaller key sizes than RSA to be just as secure) and it provides fewer settings to configure than lower-level libraries like openssl, so there is less room to do something wrong. Bonus recommended reading: https://github.com/elikaski/ECC_Attacks and https://www.latacora.com/blog/2024/07/29/crypto-right-answers-pq/#pqc-right-answers