Zum Hauptinhalt springen

Konzepte der Zugriffsverwaltung

Organisation und Projekte​

  • Die Organisation steht für Ihr Unternehmen. Sie bündelt Ihre Mitglieder und Ihre Projekte.
  • Ein Projekt ist ein isolierter Bereich der Organisation: Dort befinden sich Ihre VMs, Cluster und Datenbanken.
  • Ein Rang auf der Organisation gilt für alle ihre Projekte. Ein Rang auf einem Projekt kommt dort hinzu.

Die vier Ränge​

RangWertWas er erlaubt
ReadreadDie Ressourcen einsehen
UsewriteRead, dazu die Nutzung der Ressourcen
AdminadminRessourcen erstellen, ändern und löschen; Mitglieder verwalten
Super adminsuperadminAlle Rechte, einschließlich der Vergabe dieses Rangs; die SSO-Verbindung verwalten

Ein Rang schließt die Rechte der niedrigeren Ränge ein. Ein Mitglied, das mehrere Ränge auf demselben Geltungsbereich hält, wird mit dem höchsten angezeigt.

Kein Super admin auf Projektebene

Super admin ist ausschließlich ein Rang der Organisation. Auf einem Projekt ist der höchste Rang Admin.

Wer was in der Organisation tun darf​

AktionReadUseAdminSuper admin
Die Mitglieder, ihre E-Mail-Adresse und ihren Rang sehenjajajaja
Einladen; Einladungen stornieren und erneut sendenneinneinjaja
Read, Use, Admin vergeben oder entziehenneinneinjaja
Den Zugriff eines Mitglieds entziehenneinneinjaja
Die Zugriffsüberprüfung exportieren; die Domains verwaltenneinneinjaja
Auf ein Mitglied mit höherem Rang als dem eigenen einwirkenneinneinneinja
Super admin vergeben oder entziehenneinneinneinja
Die SSO-Verbindung und ihre Role Bindings verwaltenneinneinneinja
Den eigenen Rang herabsetzenneinneinneinnein
Die Organisation verlassenjajajaja

Regeln, die die Organisation schützen:

  • Niemand vergibt einen höheren Rang als den eigenen;
  • niemand setzt den eigenen Rang herab oder entzieht ihn sich: Wer gehen möchte, verlässt die Organisation;
  • die Organisation behält immer mindestens einen Super-Administrator, der sich mit einem Passwort anmeldet;
  • Super admin geht nur an ein Konto mit Passwort und zweitem Faktor, ohne Verknüpfung mit einem Identitätsanbieter. So behält die Organisation einen Zugang, wenn ihre SSO-Verbindung ausfällt.

Mitgliedstypen​

MitgliedWem das Konto gehörtWas Ihre Administratoren tun können
OrganisationskontoIhrer Organisation, nach einer ÜbertragungSeine Zugriffe vergeben und entziehen; alles Weitere über den Support
SSO-KontoIhrer Organisation, erstellt durch Ihre SSO-VerbindungSeine Zugriffe vergeben und entziehen (oder Ihre Role Bindings)
Persönliches Konto (externes Mitglied)Der PersonSeine Zugriffe in Ihrer Organisation vergeben und entziehen, sonst nichts
Konto einer anderen Organisation (externes Mitglied)Der anderen OrganisationSeine Zugriffe in Ihrer Organisation vergeben und entziehen, sonst nichts

Ein externes Mitglied behält sein Konto, seine Zugangsdaten und seine Zugriffe anderswo. Das Entziehen seines Zugriffs bei Ihnen berührt den Rest nicht.

Ein Mitglied nur eines Projekts hält Ränge auf einem oder mehreren Projekten und keinen auf der Organisation. Die Mitgliederseite zeigt es mit dem Badge Projects only an. Es sieht den Namen der Organisation und ihre Projekte, sonst nichts. Sein Zugriff endet mit dem Projekt.

Standardmäßig kann ein Konto, das einer Organisation gehört, keiner anderen Organisation beitreten: Die externe Zusammenarbeit ist abgelehnt.

Zweiter Faktor​

Jedes Konto, das sich mit einem Hikube-Passwort anmeldet, legt zusätzlich einen zweiten Faktor vor. Ein SSO-Konto hat in Hikube weder Passwort noch zweiten Faktor: Seine MFA ist die Ihres Identitätsanbieters. Siehe Zweiter Faktor.

Verifizierte Domain​

Eine verifizierte Domain weist nach, dass die Organisation eine Domain besitzt, zum Beispiel acme.com, mithilfe eines DNS-Eintrags vom Typ TXT namens _hikube-challenge.acme.com. Eine Domain gehört nur einer Organisation. Eine Subdomain ist eine eigene Domain. Der Eintrag muss veröffentlicht bleiben. Siehe Eine Domain verifizieren.

SSO-Verbindung​

Mit Single Sign-on (SSO) melden sich die Personen Ihrer Organisation mit dem Konto ihres Unternehmens bei Ihrem Identitätsanbieter an, statt mit einem Hikube-Passwort.

  • Eine einzige Verbindung pro Organisation, über OpenID Connect. SAML wird nicht unterstützt.
  • Nur verifizierte Domains. Nur die Adressen der zulässigen Domains der Verbindung, die alle verifiziert sind, können sie verwenden.
  • Ein SSO-Konto wird bei der ersten Anmeldung einer Person erstellt. Es gehört der Organisation.
  • Konten mit Passwort melden sich weiterhin damit an und werden nie zu Ihrem Anbieter weitergeleitet.

Technische Anforderungen​

Einstellung bei Ihrem AnbieterWert
AnwendungstypWebanwendung, vertraulich, Authorization-Code-Flow
Redirect-URIDie von der Konsole angezeigte, die auf /broker/org-<Organisation>/endpoint endet
Client-AuthentifizierungClient-Secret
Scopesopenid, email, profile
Claimsemail, Vorname, Nachname und, falls Sie ihn verwenden, der Rollen-Claim, im ID-Token (ID token)
Signatur des ID-TokensAsymmetrisch (RS256, ES256 …). HS256 allein wird abgelehnt
PKCES256, standardmäßig aktiviert

Anbieter​

AnbieterStatus
OktaVon Hikube verifiziert
Microsoft Entra IDVon Hikube verifiziert
Google WorkspaceNicht verifiziert
Auth0Nicht verifiziert

Jeder andere OpenID-Connect-Anbieter, der die obigen Anforderungen erfüllt, kann geeignet sein. Er wurde nicht von Hikube verifiziert: Wenden Sie sich an den Support, bevor Sie ihn produktiv einsetzen.

Role Bindings: eine einzige Quelle für Rechte​

Ein Role Binding ordnet einen Wert des Rollen-Claims Ihres Anbieters (eine Gruppe oder eine Rolle Ihres Verzeichnisses) einem Hikube-Rang zu, auf der Organisation oder auf einem Projekt. Jede SSO-Verbindung hat eine einzige Quelle für Rechte:

Rollen-ClaimWoher die Ränge der SSO-Konten stammen
GesetztAusschließlich aus den Role Bindings, bei jeder Anmeldung. Sie lassen sich in Hikube nicht mehr ändern
LeerAus Hikube: Ein Administrator vergibt sie auf der Mitgliederseite

Ein Role Binding vergibt nie Super admin. Siehe Ränge über Ihren Identitätsanbieter vergeben.