Worum es geht
Das CIAS-Portal (cias-frontend) ist die eigene Oberfläche von CIAS. Es ist gebaut wie das CDMS-Portal: Nuxt, Anmeldung über Keycloak, ein BFF, dieselben Farben mit einem eigenen Akzent. Es beantwortet eine Frage: Welche Dienste welcher Projekte hängen an CIAS, und wie?
Ein Dienst (im Hub auch Modul oder Service) ist eine Anwendung, die in einem Hub-Projekt angelegt ist, etwa ein CDMS-Backend für einen Kunden.
Die Seitenkarte
flowchart LR
HUB["Hub<br/>Projekt → Modul"] -- "?moduleId=…" --> IDX
DIR["direkt geöffnet"] --> IDX["/<br/>Übersicht der Dienste"]
IDX -. "keine Sitzung" .-> LOGIN["/login<br/>Weiterleitung zu Keycloak"]
LOGIN --> KC["Keycloak<br/>Login-Seiten"]
KC --> IDX
IDX -- "Abmelden" --> OUT["/api/logout<br/>→ /login?loggedOut=1"]
IDX -- "Zum Hub" --> HUB2["Hub"]
Das Portal hat zwei Seiten:
/login: leitet von selbst zu Keycloak weiter und kommt danach zum ursprünglichen Ziel zurück. Nach dem Abmelden bleibt sie mit „Abgemeldet“ und einem Knopf „Erneut anmelden“ stehen. Das Verhalten ist dasselbe wie im Hub, siehe Anmelden im Browser und Abmelden./: die Übersicht der Dienste.
Die Kopfzeile zeigt das CIAS-Zeichen, die Navigation und rechts Abmelden. In der Navigation ist nur „Übersicht“ ein Link. Die übrigen Einträge sind ausgegraut und führen nirgendwohin. Wurde das Portal aus dem Hub geöffnet, steht dort zusätzlich Zum Hub.
Die Übersicht der Dienste
Das Portal fragt die Dienste beim hub-backend ab, über die allgemeine CDMS-API (POST /cdms/module/query, mit Projektname). Dieselbe Quelle liest auch das CDMS-Portal. Die Dienste erscheinen nach Projekt gruppiert, Projekte alphabetisch, Dienste ohne Projekt unter „Ohne Projekt“. Oben rechts steht, wie viele davon CIAS benutzen („3 von 7 mit CIAS“), und ein Knopf Neu laden.
Jede Dienstkarte trägt Kennzeichen:
| Kennzeichen | Bedeutung |
|---|---|
embedded | CIAS läuft im selben Prozess wie der Dienst (cias-tenancy liegt im Dienst) |
remote | Der Dienst erreicht CIAS über eine Adresse (cias-tenancy-client) |
kein CIAS | Der Dienst fragt CIAS nicht nach dem Stand seiner Mandanten |
abgeleitet | Der Dienst sagt nichts dazu. Der Generator leitet die Anbindung beim Bauen ab |
auth OIDC / auth NONE | Ob sich der Dienst über CIAS und Keycloak anmeldet |
v…, core … | Version des Dienstes und der Plattform, auf der er steht |
| „aus dem Hub“ | Diesen Dienst hat der Hub beim Öffnen mitgegeben |
Die Begriffe eingebettet und getrennt erklärt Betriebsarten. Ein Dienst zählt als „mit CIAS“, wenn er sich über OIDC anmeldet oder eine Anbindung außer kein CIAS hat.
Die Statusprüfung
Beim Laden fragt das Portal zusätzlich GET /api/cias/status. Dessen BFF ruft GET /cias/admin/roles beim hub-backend auf, mit dem Token der Sitzung, und übersetzt die Antwort in einen von vier Zuständen:
| Antwort von /cias/admin/roles | Zustand |
|---|---|
| 200 | ready: CIAS antwortet, und diese Sitzung darf den Rollenkatalog lesen |
| 401 oder 403 | forbidden: CIAS antwortet, weist diesen Zugang aber ab |
| 404 | not-migrated: Der Pfad wird nicht bedient |
| keine Antwort oder anderer Status | unreachable: keine Antwort vom hub-backend |
Bei jedem Zustand außer ready zeigt die Übersicht oben einen gelben Hinweis mit dem Text zum Zustand. Die Liste der Dienste steht trotzdem, denn sie kommt aus dem Metamodell des Hubs und nicht aus CIAS.
Weil /cias/admin/roles nur Plattform-Administratoren antwortet, sehen alle anderen angemeldeten Personen hier forbidden.
Die Ausprägungen
Wann: Jemand öffnet das Portal direkt.
Ohne Sitzung geht es über /login zu Keycloak und zurück, bei einer tieferen Adresse mit ?redirect= zu genau dieser Seite. Die Übersicht zeigt alle Dienste, kein Dienst ist hervorgehoben, es gibt keinen Knopf „Zum Hub“.
Ergebnis: Übersicht der Dienste.
Wann: Im Hub springt jemand von einem Modul in das CIAS-Portal ab.
Der Hub hängt ?moduleId=<ID der Modul-Instanz> an die Portal-Adresse. Das Portal hebt diesen Dienst mit einem farbigen Rahmen und dem Kennzeichen „aus dem Hub“ hervor und zeigt oben Zum Hub. Der Knopf führt zur Adresse des Hubs aus NUXT_PUBLIC_HUB_BASE_URL und erscheint nur, wenn sie gesetzt ist.
Ergebnis: Übersicht mit markiertem Dienst.
Wann: Die Statusprüfung ergibt ready.
Kein Hinweis.
Ergebnis: Nur die Liste.
Wann: forbidden, typisch für Personen ohne Plattform-Administrator-Rolle.
Gelber Hinweis mit „CIAS antwortet, weist diesen Zugang aber ab.“
Ergebnis: Die Liste steht trotzdem.
Wann: not-migrated: Das hub-backend beantwortet /cias/admin/… nicht.
Gelber Hinweis, dass hub-backend diesen Pfad nicht bedient.
Ergebnis: Die Liste steht trotzdem.
Wann: unreachable: keine Antwort.
Gelber Hinweis „Keine Antwort von hub-backend.“
Ergebnis: Kommt auch die Liste nicht, erscheint zusätzlich die Fehlermeldung der Liste.
Wann: Ein Dienst meldet sich über OIDC an und ist ausdrücklich auf kein CIAS gestellt.
Die Karte bekommt einen roten Rahmen und „Startet nicht: cias = NONE bei CIAS-Authentifizierung“. Über der Liste steht ein roter Kasten mit allen betroffenen Diensten. Grund: Wo cias-authentication liegt, muss es einen Weg geben, den Stand eines Mandanten nachzufragen. Fehlt er, startet der Dienst nicht.
Ergebnis: Siehe Den Mandanten zulassen (Mandanten-Tor).
Wann: Es gibt keine Dienste, oder die Abfrage scheitert.
Leer: „Es ist noch kein Service angelegt“ mit dem Hinweis, dass Dienste im Hub entstehen. Fehler: die Meldung des Backends und „Erneut versuchen“. Fehlt der Person das Leserecht auf das Modell, lautet sie „Fehlende Berechtigung – benötigte Rolle: …“.
Ergebnis: Kein Absturz, eine verständliche Meldung.
Wer das Portal sieht
Jede angemeldete Person kommt auf die Übersicht. Das Portal selbst prüft keine Rolle. Was sie dort sieht, entscheiden die Backends:
- Die Liste der Dienste liefert CDMS nur, wenn die Person das Modell
cdms.modulelesen darf. - Die Statusprüfung meldet
readynur für Plattform-Administratoren.
Anmeldung und Cookies
Die Anmeldung läuft wie in allen Oberflächen über Keycloak und einen BFF, siehe Sitzung im BFF und Cookies. Das Portal benennt seine Cookies mit dem Präfix cias-auth., statt des Standardnamens next-auth.. So stören sich Hub, CDMS-Portal und CIAS-Portal nicht, wenn sie auf demselben Rechner unter localhost laufen: Cookies trennt der Browser nach Rechnername, nicht nach Port.