What this is about
The CIAS portal (cias-frontend) is CIAS’s own user interface. It is built like the CDMS portal: Nuxt, sign-in via Keycloak, a BFF, the same colors with an accent of its own. It answers one question: Which services of which projects are connected to CIAS, and how?
A service (in the hub also module) is an application created in a hub project, for example a CDMS backend for a customer.
The page map
flowchart LR
HUB["Hub<br/>project → module"] -- "?moduleId=…" --> IDX
DIR["opened directly"] --> IDX["/<br/>overview of services"]
IDX -. "no session" .-> LOGIN["/login<br/>redirect to Keycloak"]
LOGIN --> KC["Keycloak<br/>login pages"]
KC --> IDX
IDX -- "Sign out" --> OUT["/api/logout<br/>→ /login?loggedOut=1"]
IDX -- "To the hub" --> HUB2["Hub"]
The portal has two pages:
/login: forwards to Keycloak on its own and comes back to the original target afterwards. After signing out it stays put with “Signed out” and a button “Sign in again”. The behavior is the same as in the hub, see Sign in in the browser and Signing out./: the overview of services.
The header shows the CIAS mark, the navigation and Sign out on the right. In the navigation only “Overview” is a link. The other entries are greyed out and lead nowhere. If the portal was opened from the hub, there is also To the hub.
The overview of services
The portal asks hub-backend for the services, through the generic CDMS API (POST /cdms/module/query, with the project name). The CDMS portal reads the same source. The services appear grouped by project, projects in alphabetical order, services without a project under “No project”. At the top right it says how many of them use CIAS (“3 of 7 with CIAS”), next to a Reload button.
Every service card carries badges:
| Badge | Meaning |
|---|---|
embedded | CIAS runs in the same process as the service (cias-tenancy is inside the service) |
remote | The service reaches CIAS through an address (cias-tenancy-client) |
kein CIAS (no CIAS) | The service does not ask CIAS about the standing of its tenants |
abgeleitet (derived) | The service says nothing about it. The generator derives the connection when building |
auth OIDC / auth NONE | Whether the service signs in through CIAS and Keycloak |
v…, core … | Version of the service and of the platform it is built on |
| “aus dem Hub” (from the hub) | The hub passed this service along when opening the portal |
The terms embedded and standalone are explained in Operating modes. A service counts as “with CIAS” if it signs in via OIDC or has a connection other than kein CIAS.
The status check
While loading, the portal also asks GET /api/cias/status. Its BFF calls GET /cias/admin/roles on hub-backend, with the session’s token, and translates the answer into one of four states:
| Answer from /cias/admin/roles | State |
|---|---|
| 200 | ready: CIAS answers, and this session may read the role catalog |
| 401 or 403 | forbidden: CIAS answers but refuses this access |
| 404 | not-migrated: the path is not served |
| no answer or another status | unreachable: no answer from hub-backend |
In every state other than ready, the overview shows a yellow notice at the top with the text for the state. The list of services still stands, because it comes from the hub’s meta model and not from CIAS.
Because /cias/admin/roles only answers platform administrators, every other signed-in person sees forbidden here.
The variants
When: Someone opens the portal directly.
Without a session it goes via /login to Keycloak and back, for a deeper address with ?redirect= to exactly that page. The overview shows all services, no service is highlighted, and there is no “To the hub” button.
Result: Overview of services.
When: In the hub, someone jumps from a module into the CIAS portal.
The hub appends ?moduleId=<ID of the module instance> to the portal address. The portal highlights this service with a colored border and the badge “aus dem Hub” and shows To the hub at the top. The button leads to the hub address from NUXT_PUBLIC_HUB_BASE_URL and only appears if it is set.
Result: Overview with the service marked.
When: The status check returns ready.
No notice.
Result: Just the list.
When: forbidden, typical for people without the platform administrator role.
Yellow notice saying that CIAS answers but refuses this access.
Result: The list still stands.
When: not-migrated: hub-backend does not answer /cias/admin/….
Yellow notice that hub-backend does not serve this path.
Result: The list still stands.
When: unreachable: no answer.
Yellow notice “No answer from hub-backend.”
Result: If the list does not come either, the list's error message appears as well.
When: A service signs in via OIDC and is explicitly set to kein CIAS.
The card gets a red border and “Will not start: cias = NONE with CIAS authentication”. Above the list there is a red box with all affected services. Reason: wherever cias-authentication is present, there must be a way to ask for a tenant's standing. Without it, the service does not start.
Result: See Admitting the tenant (tenant gate).
When: There are no services, or the query fails.
Empty: “No service has been created yet” with the hint that services are created in the hub. Error: the backend's message and “Try again”. If the person lacks read permission on the model, it reads “Missing permission – required role: …”.
Result: No crash, an understandable message.
Who sees the portal
Every signed-in person reaches the overview. The portal itself checks no role. What the person sees there is decided by the backends:
- CDMS returns the list of services only if the person may read the model
cdms.module. - The status check reports
readyonly for platform administrators.
Sign-in and cookies
Sign-in works as in all user interfaces via Keycloak and a BFF, see Session in the BFF and cookies. The portal names its cookies with the prefix cias-auth. instead of the default name next-auth.. That way the hub, the CDMS portal and the CIAS portal do not disturb each other when they run on the same machine under localhost: the browser separates cookies by host name, not by port.