Zugang zur Konsole
Die Konsole hat Schreibrechte auf den Anlagen Ihrer Kunden. Entsprechend streng ist der Zugang gebaut. Diese Seite beschreibt, wie die Anmeldung funktioniert und welche Fehler dabei bewusst vermieden wurden.
Drei Wege hinein
| Weg | Beschreibung |
|---|---|
| Lokales Konto | E-Mail-Adresse und Passwort, im Controller selbst hinterlegt. Funktioniert immer, auch ohne Internet. |
| Microsoft Entra ID | Anmeldung über Ihr Microsoft-365-Verzeichnis |
| Google Workspace | Anmeldung über Ihr Google-Workspace-Verzeichnis |
Ein weiterer Anbieter, die STARFACE ID, ist vorbereitet und lässt sich konfigurieren, sobald die Ausstellerdaten vorliegen.
Lokale Konten existieren immer, auch wenn ein Identitätsanbieter eingerichtet ist. Das ist kein Zugeständnis, sondern eine Bedingung: Ein Partner, der den Controller selbst betreibt, muss sich ohne Internetanbindung anmelden können. Passwörter lokaler Konten werden mit BCrypt gespeichert.
Ist ein Identitätsanbieter beim Start nicht erreichbar oder falsch konfiguriert, wird er übersprungen und protokolliert. Der Controller startet trotzdem, die übrigen Anmeldewege und das lokale Konto funktionieren weiter. Eine optionale Anmeldemethode darf keine Plattform lahmlegen, die mehrere hundert Telefonanlagen führt.
Kein Auto-Provisioning
Das ist die wichtigste Eigenschaft der Anmeldung: Eine erfolgreiche Anmeldung beim Identitätsanbieter erzeugt kein Konto.
Gibt es zur angemeldeten Adresse kein Konto im Controller, wird die Anmeldung abgewiesen – mit dem Hinweis, dass ein Administrator das Konto anlegen muss.
Eine erfolgreiche Anmeldung bei Microsoft beweist, wer jemand ist – nicht, dass er die Telefonanlagen Ihrer Kunden sehen darf. Ohne diese Regel käme jedes Mitglied Ihres Verzeichnisses herein. In Entra schließt das je nach Konfiguration auch Gastkonten ein – also Personen, die Sie für ein einzelnes Projekt eingeladen haben.
Der Ablauf ist damit immer derselbe: Erst legt ein Administrator das Konto an, dann bestätigt der Identitätsanbieter, dass die Person auch wirklich diese Person ist.
Bindung an die Identität hinter der Adresse
Konten werden über die E-Mail-Adresse zugeordnet – das ist der Wert, den ein Administrator beim Anlegen kennt. Bei der ersten Anmeldung merkt sich der Controller zusätzlich die eindeutige Kennung, unter der der Identitätsanbieter diese Person führt.
Ab dann wird das Paar geprüft. Gehört dieselbe Adresse später zu einer anderen Kennung, wird die Anmeldung abgewiesen statt das bestehende Konto zu übergeben.
Zwei reale Fälle: ein neu aufgebautes Verzeichnis und ein wiederverwendetes Postfach. In beiden Fällen stimmt die Adresse, aber dahinter steht jemand anderes. Ohne diese Prüfung bekäme diese Person stillschweigend das alte Konto – samt dessen Rechten auf Ihrer Flotte.
Die Kennung wird dabei je Anbieter getrennt geführt. Dieselbe Adresse bei Microsoft und bei Google sind zwei verschiedene Identitäten.
Rollen kommen nie aus dem Verzeichnis
Die Rolle eines Benutzers steht ausschließlich im Controller. Sie wird niemals aus einer Angabe des Identitätsanbieters übernommen – auch nicht aus Gruppen.
Gruppenangaben stehen unter der Kontrolle des Verzeichnisses. Wer dort Gruppen verwalten darf, könnte sich sonst selbst Rechte in Ihrer Flotte geben. Diese Konsole kann hunderte Telefonanlagen verändern; das ist keine Entscheidung, die man in einem fremden Verzeichnis treffen lässt.
Die vier Rollen
| Rolle | Gedacht für |
|---|---|
| OWNER | Inhaber des Partnerzugangs |
| ADMIN | Administratoren des Partnerzugangs |
| TECHNICIAN | Techniker, die auf Anlagen arbeiten |
| VIEWER | Reine Beobachter |
Heute wirksam unterschieden wird an den Stellen, die über das Lesen der eigenen Flotte hinausgehen:
- Einrichtungscodes ausstellen – nur OWNER und ADMIN. Ein Code ist eine Einladung in die Flotte.
- Partnerportal-Abgleich starten – nur OWNER und ADMIN. Diese Abfrage legt den gesamten Kundenbestand offen: Namen, Orte, Adressen, Lizenzstände. Das ist keine Leseoperation auf der eigenen Flotte und gehört nicht in eine reine Beobachterrolle.
Sitzung und Browser
- Das Sitzungscookie ist HttpOnly – JavaScript im Browser kommt nicht daran.
- Es ist auf Secure gesetzt und wird nur über HTTPS übertragen.
- Es trägt SameSite=Lax: Bei seitenfremden schreibenden Anfragen wird es nicht mitgeschickt. Das ist der Schutz gegen untergeschobene Anfragen aus fremden Seiten.
- Die Oberfläche und die Schnittstelle liegen für den Browser unter einer Herkunft. Dadurch bleibt das Cookie ein First-Party-Cookie. Der sonst übliche Ausweg – ein Token im JavaScript-Speicher – wäre für eine Konsole mit Schreibrechten auf hunderten Telefonanlagen die schlechtere Variante.
Die Sitzungen liegen im Arbeitsspeicher des Controllers. Ein Neustart meldet alle Bediener ab. Das ist unkritisch, aber gut zu wissen, wenn Sie den Controller selbst betreiben und aktualisieren.
Kurz zusammengefasst
| Maßnahme | Verhindert |
|---|---|
| Kein Auto-Provisioning | Dass jedes Verzeichnis-Konto, auch Gastkonten, Zugang bekommt |
| Prüfung der Identität hinter der Adresse | Übernahme eines Kontos über eine recycelte Adresse |
| Rollen nur lokal | Rechtevergabe durch Verzeichnisadministratoren |
| Codes und Portalabgleich nur für OWNER/ADMIN | Dass ein Beobachter Einladungen ausstellt oder Kundenbestände abzieht |
| Lokale Konten immer vorhanden | Aussperrung bei Ausfall des Identitätsanbieters |
| HttpOnly, Secure, SameSite=Lax | Cookie-Diebstahl per Skript und untergeschobene Schreibanfragen |
Weiter mit Daten, Protokoll und Datenhoheit.