SAML-Autorisierung und Zugriffskontrolle

Anleitung und Methodik zur Festlegung Ihrer Zugriffsrichtlinien und zur Verwaltung von SAML für Ihr Unternehmen.

SAML ermöglicht es Organisationen, die Authentifizierung und Zugriffsrechte von Tulip-Benutzern über ihren bestehenden Identitätsanbieter (IdP) zu verwalten. Dieser Leitfaden beschreibt detailliert die verfügbaren Optionen für die Implementierung einer IdP-Integration auf Unternehmensebene über das SAML-Protokoll.

Vorbereitungen

• Machen Sie sich mit den Tulip -Benutzerrollen vertraut
• Ordnen Sie die voraussichtlichen Tulip-Benutzer nach Rollen ein, damit Sie bereit sind, ein SAML-Attribut mit ihrer Tulip-Rolle zu aktualisieren
• Legen Sie fest, wer in Ihrer Organisation Ihren IdP und Ihr Tulip-Konto konfigurieren wird

IdP-Konfiguration

Wenn Ihre Tulip-Instanz für die Anmeldung über SAML konfiguriert ist, unterhält Tulip eine Verknüpfung zwischen den Benutzern in Tulip und den Benutzern in Ihrem Unternehmens-Identitätsanbieter (IdP). Ein bestimmter Benutzer, der über ein Konto im IdP verfügt, sollte höchstens ein Konto in einer bestimmten Tulip-Instanz haben. Tulip hält diese Verknüpfung mithilfe eines SAML-spezifischen Konzepts aufrecht, das als „NameID“ bezeichnet wird. Eine NameID ist eine undurchsichtige Art von Kennung, die von der SAML-Authentifizierung bereitgestellt und vom IdP definiert wird.

Da die NameID zur Aufrechterhaltung dieser Verknüpfung verwendet wird, erwartet Tulip, dass NameIDs stabil sind, d. h., die NameID, die Tulip für einen bestimmten IdP-Benutzer erhält, sollte sich während der gesamten Lebensdauer des Benutzers nicht ändern. Sollte sich die NameID eines Benutzers doch ändern, wird die Verknüpfung unterbrochen, und es können Fehler bei der Anmeldung auftreten.

Tulip empfiehlt dringend, Ihren IdP so zu konfigurieren, dass er eine NameID bereitstellt, die sich im Laufe der Zeit nicht ändert. Aus diesem Grund rät Tulip davon ab, Namen oder E-Mail-Adressen als NameIDs zu verwenden, da sich diese Werte im Laufe der Zeit ändern können. Wir empfehlen, Ihren IdP so zu konfigurieren, dass interne Objekt-IDs oder Kontonamen verwendet werden, bei denen garantiert ist, dass sie sich niemals ändern.

Beachten Sie, dass NameIDs nicht für Menschen lesbar oder erkennbar sein müssen (tatsächlich ist es aus Sicherheitsgründen im Allgemeinen besser, nicht erkennbare Werte für NameIDs zu verwenden).

Bei der Konfiguration Ihres IdP empfehlen wir Ihnen, das NameID-Format auf „Persistent“ einzustellen. Dies signalisiert Tulip, dass der Wert über die gesamte Lebensdauer eines Benutzers hinweg konstant bleiben soll.

Ordnen Sie den Quellwert des NameID-Attributs einem Wert zu, von dem bekannt ist, dass er unveränderlich ist, wie beispielsweise „Objekt-ID“ oder „Benutzerprinzipalname“.

Microsoft Entra

Kunden, die Microsoft Entra als IdP verwenden, sollten diese spezifischen Anweisungen befolgen, um ihre Tulip-Anwendung für die Verwendung persistenter NameIDs zu konfigurieren:

1. Starten Sie in Entra bei der Unternehmensanwendung, die Ihrer Tulip-Instanz zugeordnet ist.
2. Klicken Sie im linken Navigationsmenü unter der Gruppe „Verwalten“ auf „Single Sign-On“.
3. Bearbeiten Sie den Abschnitt „Attributes & Claims“.
4. Klicken Sie im Abschnitt „Erforderliche Claims“ auf die Zeile für den Claim „Eindeutige Benutzerkennung (Name ID)“.
5. Stellen Sie sicher, dass das „Format der Namenskennung“ auf „Persistent“ eingestellt ist. Setzen Sie die „Quelle“ auf „Attribut“ und wählen Sie ein Attribut aus, das über die gesamte Lebensdauer des Benutzers hinweg stabil bleibt. „user.userprincipalname“ und „user.objectid“ sind gute Optionen.

Konfigurationsoptionen für SAML und Tulip

Steuerungsmodi

Der Tulip-Steuerungsmodus bedeutet, dass die Tulip-Rolle und der Arbeitsbereich eines Benutzers nur bei der ersten Anmeldung bei Tulip aus der SAML-Attributzuordnung übernommen werden .

Benutzer, die in Tulip deaktiviert wurden, können sich nicht anmelden.

Im IdP-Steuerungsmodus werden die Tulip-Rolle und der Arbeitsbereich eines Benutzers bei jeder Anmeldung vom IdP aktualisiert .

Standard-Rollenzuordnung (nur im Tulip-Steuerungsmodus)

Bei der ersten Anmeldung erhalten alle Benutzer eine Standardzugriffsebene (Viewer mit Player-Zugriff). Der Kontoinhaber muss die Rolle anschließend manuell in Tulip auf die entsprechende Ebene anpassen.

Arbeitsbereiche

Erfahren Sie mehr über Arbeitsbereiche

Ähnlich wie beim Rollenattribut haben Sie nun die Möglichkeit, Benutzer bei ihrer erstmaligen Erstellung automatisch einem bestimmten Arbeitsbereich zuzuordnen. Nach der Benutzererstellung können Kontoinhaber Benutzer flexibel zwischen Arbeitsbereichen verschieben.

Benutzerdefinierte SAML-Arbeitsbereichszuordnung

Bei der ersten Anmeldung wird einem Benutzer der Zugriff auf einen Arbeitsbereich basierend auf der in seinem Arbeitsbereichsattribut angegebenen Gruppe zugewiesen. Danach liest Tulip das Arbeitsbereichsattribut dieses Benutzers nicht mehr aus, und alle Änderungen am Arbeitsbereich müssen von einem Kontoinhaber in der Plattform vorgenommen werden.

Standardmäßige Arbeitsbereichszuordnung

Bei der ersten Anmeldung erhalten alle Benutzer Zugriff auf einen von Ihnen ausgewählten Standard-Arbeitsbereich. Ein Kontoinhaber kann den Zugriff auf den Arbeitsbereich anschließend anpassen.

Benutzergruppen

Sie können Benutzer in allen SAML-Konfigurationen der Funktion „ Benutzergruppen“ von Tulip zuordnen.

Benutzergruppen existieren auf Kontoebene. Sobald ein Benutzer einer Benutzergruppe zugeordnet wurde, ist er in allen Arbeitsbereichen Mitglied dieser Benutzergruppe.

Sobald Sie die Option „Benutzergruppen“ aktivieren, können Sie Benutzer aus Ihrem IdP basierend auf dem Wert eines Attributs in SAML den Benutzergruppen in Tulip zuordnen.

Anschließend können Sie bis zu 100 SAML-Attribute benennen und die Werte der einzelnen Attribute einer Benutzergruppe zuordnen. Ein Benutzer kann dann mehreren Benutzergruppen zugeordnet werden.

Zuordnung von Benutzergruppen und Verhalten im Kontrollmodus

Das Verhalten der Benutzergruppenmitgliedschaft hängt von Ihrer Einstellung für den Kontrollmodus ab.

• Tulip-Steuerungsmodus: Die über SAML zugeordneten Gruppen eines Benutzers werden nur bei der ersten Anmeldung angewendet. Danach kann die Gruppenmitgliedschaft innerhalb von Tulip verwaltet werden, und alle manuellen Änderungen bleiben bei nachfolgenden Anmeldungen erhalten.
• IdP-Steuerungsmodus: Die vollständige Gruppenmitgliedschaft eines Benutzers wird bei jeder Anmeldung anhand seiner aktuellen SAML-Attribute neu berechnet. Tulip weist dem Benutzer die Gruppen zu, die sich aus der Zuordnung ergeben, und entfernt ihn aus allen Gruppen, die nicht von der Zuordnung abgedeckt sind – einschließlich der Gruppen, die manuell in Tulip zugewiesen wurden.

Authentifizierungsoptionen

Wenn Sie FIDO-Schlüssel für die Benutzerauthentifizierung verwenden möchten, müssen Sie die Option „Authentifizierungsmethodenabgleich deaktivieren“ aktivieren.

Authentifizierungskontextklasse

Die Authentifizierungskontextklasse ist die festgelegte Methode, mit der sich Benutzer authentifizieren.

Wenn diese Option aktiviert ist, können sich Benutzer nur über die angegebene Methode authentifizieren.

Ist diese Option deaktiviert, wird die Auswahl der Authentifizierungsmethode vollständig an den Identitätsanbieter delegiert.

Authentifizierung erzwingen

Tulip verwendet den SAML-Parameter „forceAuthn“, um zu steuern, ob sich Benutzer bei jeder Anmeldung erneut bei ihrem Identitätsanbieter (IdP) authentifizieren müssen oder ob eine bestehende SAML-Sitzung auf Betriebssystemebene wiederverwendet werden kann. Tulip verwendet den Parameter „isPassive“ nicht. Bei der bestehenden Sitzung handelt es sich hierbei um die SAML-Sitzung auf Betriebssystemebene (z. B. eine mit Ihrem Identitätsanbieter verknüpfte Windows-Sitzung), nicht um eine Tulip-spezifische Sitzung.

Authentifizierung erzwingen EIN (Standard): Tulip sendet „forceAuthn=true“, wodurch der Benutzer bei jeder Anmeldung aktiv bei seinem Identitätsanbieter authentifiziert werden muss, unabhängig von einer eventuell bestehenden SAML-Sitzung auf Betriebssystemebene. Diese Einstellung stellt sicher, dass Benutzer die erneute Authentifizierung nicht umgehen können.

„Force Authentication“ AUS: Tulip sendet „forceAuthn=false“. Verfügt der Benutzer bereits über eine aktive SAML-Sitzung auf Betriebssystemebene, die vom Identitätsanbieter erkannt wird, wird er automatisch bei Tulip angemeldet, ohne dass er seine Anmeldedaten erneut eingeben muss.

Anpassung

Optionale Anpassungsmöglichkeiten für die Benutzeranmeldung.

Bezeichnung der Anmeldeschaltfläche – Passen Sie den Text auf der SAML-Anmeldeschaltfläche auf den Tulip-Anmeldeseiten an.

Benutzerdefinierte Support-E-Mail – Legen Sie eine benutzerdefinierte E-Mail-Adresse fest, die Benutzern angezeigt wird, wenn ein SAML-Anmeldefehler auftritt. Damit können Sie Benutzer an Ihren internen IT-Support weiterleiten. Wenn das Feld leer bleibt, wird die Standard-Support-E-Mail-Adresse „support@tulip.co“ verwendet.

Desktop-Player: Standardbrowser des Betriebssystems für die Authentifizierung

Falls Ihre SSO-Anmeldung oder die Autorisierung über den OAuth-Konnektor eine Integration erfordert, die nur über Ihren Standardbrowser verfügbar ist, kann der Tulip-Player so konfiguriert werden, dass Authentifizierungsabläufe im Standardbrowser des Betriebssystems statt in einem eingebetteten Fenster geöffnet werden.

Versionsanforderungen

Für die Authentifizierung über den Standardbrowser des Betriebssystems müssen die folgenden Tulip-Versionsanforderungen erfüllt sein:* Desktop-Player 2.8 oder höher* Factory-Release 318 oder höher

Funktionsverhalten

Dieses Verhalten gilt sowohl für die Anmeldung beim Desktop-Player über SSO als auch für die Autorisierung von OAuth-Konnektoren innerhalb von Tulip-Apps. In beiden Fällen öffnet sich, wenn ein Benutzer die Authentifizierung initiiert, sein Standardbrowser des Betriebssystems, um den folgenden Ablauf abzuwickeln:

1. Der Systembrowser wird gestartet und navigiert zur Anmeldeseite des Identitätsanbieters (IdP) Ihrer Organisation.
2. Der Benutzer schließt seine Anmeldung (Eingabe der Anmeldedaten, Abschluss der MFA usw.) im Browser genau so ab, wie er es im Web tun würde.
3. Sobald die Authentifizierung abgeschlossen ist, wird auf der Browser-Seite die folgende Meldung angezeigt: „Fertig! Sie können dieses Fenster schließen.“
4. Das Browserfenster bleibt geöffnet. Es wird nicht automatisch geschlossen. Der Benutzer sollte es manuell schließen.
5. Der Tulip Desktop Player erkennt die abgeschlossene Anmeldung und fährt wie gewohnt fort.

Zu erwartende Berechtigungsabfragen

Je nach Betriebssystem und Browserkonfiguration können beim Benutzer ein oder zwei Berechtigungsabfragen erscheinen:

1. Berechtigung für den Desktop Player bezüglich Firewall/lokaler Server (auf Betriebssystemebene)

Wenn die Authentifizierung gestartet wird, erstellt der Desktop Player einen temporären lokalen Server, um die Authentifizierungsantwort zu empfangen. Je nach Betriebssystem und Sicherheitseinstellungen kann eine System-Firewall oder eine Netzwerkzugriffsabfrage erscheinen, in der gefragt wird, ob der Desktop Player eingehende Verbindungen akzeptieren darf.

• Erforderliche Maßnahme: Erlauben Sie die Verbindung. Dies ist ein erwartetes Verhalten und für den Abschluss der Anmeldung erforderlich.
• Je nach Betriebssystemeinstellung erscheint diese Abfrage möglicherweise nur beim ersten Mal oder bei jedem Vorgang.

2. Zugriffsberechtigung für das lokale Netzwerk im Browser (auf Browserebene)

Nachdem der Benutzer die Anmeldung bei seinem Identitätsanbieter abgeschlossen hat, sendet die Seite zur Authentifizierungsbestätigung des Browsers das Ergebnis an den Desktop-Player zurück, indem sie eine Anfrage an den oben beschriebenen lokalen Server stellt. Einige Browser zeigen eine Berechtigungsabfrage an, in der gefragt wird, ob die Seite auf Geräte im lokalen Netzwerk zugreifen darf.

• Erforderliche Maßnahme: Erlauben Sie den Zugriff. Dies ist ein sicherer, erwarteter Schritt im Authentifizierungsablauf.
• Die Anfrage erfolgt ausschließlich an „localhost“ und enthält lediglich die verschlüsselte Authentifizierungsantwort. Zu diesem Zeitpunkt werden keine sensiblen Anmeldedaten übertragen.

Zusammenfassung der für den Benutzer sichtbaren Unterschiede

Die folgende Tabelle vergleicht das Verhalten der Standardauthentifizierung mit der durch den Betriebssystem-Browser ermöglichten Authentifizierung:

Beispiel: Erstellen Sie Zugriffsgruppen innerhalb Ihres IdP

Das folgende Beispiel veranschaulicht, wie die verschiedenen Optionen in den SAML-Einstellungen zusammen genutzt werden können.

Erstellen Sie standardisierte Tulip-Rollen

Jeder Benutzer benötigt ein in Ihrem IdP festgelegtes Rollenattribut, damit Tulip seine Berechtigungen ermitteln kann, sobald er sich mit seinem IdP-Benutzernamen und -Passwort authentifiziert hat.

Sie können dieses Rollenfeld auch nutzen, um anhand einer standardisierten Namenskonvention festzulegen, auf welche Websites der Benutzer Zugriff hat. Zwar kann ein Rollenfeld einfach eine festgelegte Variable sein, es wird jedoch empfohlen, den Benutzer in Ihrem IdP Tulip-spezifischen Gruppen zuzuweisen und diese einem Attribut zuzuordnen.

Rolle

Jedem Benutzer wird in einem Arbeitsbereich eine einzige Rolle zugewiesen.

Wenn Tulip mehrere gültige Rollen für einen Benutzer erhält, wendet es die folgende Logik an:

Wenn die Gruppe integrierte Rollen (Operator, Builder usw.) enthält, wählt Tulip die integrierte Rolle mit dem höchsten Rang basierend auf einer statischen internen Hierarchie aus. Benutzerdefinierte Rollen rangieren immer unterhalb aller integrierten Rollen, sodass sie niemals ausgewählt werden, wenn eine integrierte Rolle vorhanden ist.

Wenn die Gruppe ausschließlich benutzerdefinierte Rollen enthält, wählt Tulip die erste benutzerdefinierte Rolle aus, die in der SAML-Nutzlast empfangen wurde.

Erfahren Sie mehr über Tulip -Benutzerrollen.

Standort

Nehmen wir an, Ihre Organisation verfügt über zwei Standorte mit jeweils einem eigenen „ Tulip Instance “.

Wir können jeden Standort anhand seines Standorts bezeichnen (Texas bzw. London).

Kombination von Standort und Rolle

Wir können diese beiden Eigenschaften kombinieren, um eine Gruppenmatrix für die Zuordnung von Benutzern zu erstellen. Wir empfehlen Organisationen, den Wert mit „Tulip“ voranzustellen oder anzuhängen, damit das Filtern einfacher ist.

Konvention: tulip-siteRole

Wenn Jane Smith die Standortleiterin am Standort Texas ist, würden Sie sie der Gruppe „tulip-texasAccountOwner“ zuweisen. Wenn Jane Smith außerdem Lesezugriff auf den Standort London benötigt, könnte sie der Gruppe „tulip-londonViewer“ hinzugefügt werden.

Stellen Sie diese Gruppen als Attribut für Tulip bereit

In Ihrem IdP sollte Jane über ein Attribut namens „tulip-role“ verfügen, dem alle Gruppen zugeordnet werden, denen sie angehört und die das Präfix „tulip-“ enthalten.

Wenn sie sich bei Tulip anmeldet, hat das Attribut „tulip-role“ zwei Werte: „tulip-texasAccountOwner“ und „tulip-londonViewer“. Sie können die Rollenzuordnung für jeden „ Tulip instance “ individuell konfigurieren, sodass sie in jeder Instanz die richtigen Berechtigungen erhält.

Globale Rollen

Möglicherweise möchten Sie auch globale Zugriffsrollen erstellen, beispielsweise eine „Viewer“-Rolle. Diese Benutzer können sich bei jeder Instanz von Tulip instance mit denselben Berechtigungen anmelden. Das empfohlene Format hierfür lautet:

tulip-globalViewer

Sie müssen diese Rollenzuordnung auf jeder einzelnen Instanz auf der SAML-Konfigurationsseite in den Kontoeinstellungen einrichten, damit dieser Benutzer auf jede Instanz zugreifen kann.

{{snippet.Haben Sie gefunden, wonach Sie gesucht haben?}}