| `traffic-influence` | the 5 `traffic-influence:*` scopes |
How it works:
- The list of products and their scopes is `global.apiProducts` in the umbrella `values.yaml`.
Every scope in `camara-scopes.yaml` must belong to exactly one product.
- Every CAMARA scope is a default scope of `oop-portal`, but each has a **role scope mapping**
(client scope → **Scope** tab) to its product's role. Keycloak puts the scope in a token only if
the holder has that role. This holds for people and for a client's service account alike.
- So a user's token carries exactly the scopes of the products they hold. OEG only checks scopes
and knows nothing about products.
- Changes show up in the **next token**: a token already issued keeps its scopes until it expires
(5 minutes).
- The `oeg` client's id is fixed (`realms.oop.oeg.internalId`, default `oeg-client`) so the portal
can be told it. It is an address, not a secret.
To grant a product: admin console → realm `oop` → **Users** → the user → **Role mapping** →
**Assign role** → filter by clients → pick the role under `oeg`.
### Clients
| Client | Kind | Used by | What it does |
|---|---|---|---|
| `oop-portal` | Confidential, Authorization Code + PKCE | Portal | Logs people in. Its tokens name `oeg` in the audience so OEG accepts them, and carry the `organization` claim. |
| `oeg` | No login at all | OEG | Exists only so the audience `oeg` refers to a real client. |
| `oeg` | No login at all | OEG | Makes the audience `oeg` refer to a real client, and owns the API product roles ([API products](#api-products)). |
| `oop-portal-admin` | Service account | Portal backend | Reads and changes users for the Portal's user-management pages. It has only `manage-users`, `view-users`, `query-users` and `view-realm`, so it cannot change realm settings or clients. |
| `oop-portal-provisioner` | Service account | Portal backend | Creates API clients for developers. It has only `create-client`, `view-users` and `query-users`. It does **not** have `view-clients`, which would expose every client's secret. |
`oop-portal` details:
@@ -360,6 +393,7 @@ Everything is generated on the first install and stored in the Secret `keycloak-
| `dev-user-password` | Password of the sample users (only if enabled). |
| `oop-portal-client-secret` | Secret of the Portal's login client. |
| `oop-portal-admin-client-secret` | Secret of the Portal's user-management service account. It can reset any password in realm `oop`: treat it like an admin password. |
| `oop-portal-provisioner-client-secret` | Secret of the Portal's API-client service account. It can register clients in realm `oop`: keep it to the portal backend. |
| `federation-<client id>-secret` | One per partner OP. Federation Manager reads these too. |
Read one:
@@ -552,6 +586,8 @@ existed keeps its old look until you pick it: admin console → realm `oop` →
| Federation Manager checks partner tokens (signature, issuer, audience, scope) | In the FM code; your FM image must include it |
| Portal backend checks bearer tokens and roles | Done (audience check still to switch on) |
| Portal real login (Authorization Code + PKCE, server-side session, logout) | Next: the Portal still has a placeholder login screen |
| API products: roles on `oeg`, scope gate, provisioner client (realm import) | Done for new realms |
| API products: provisioner permissions, registration policies, existing realms | Next: a realm job |
| OEG checks tokens and reads `organization` | Next: OEG does not check tokens yet |
| HTTPS / Ingress for Keycloak | Not yet: `http` + NodePort today; `keycloak.hostname` can already point at an HTTPS address behind your own ingress |