Wie geht es Ihnen?
Und willkommen zurück.
Nun, im heutigen Video werden wir über das Konzept der Föderation diskutieren.
Bevor Sie sich nun genauer damit befassen, lassen Sie uns einen einfachen Anwendungsfall
betrachten, um die Herausforderung zu verstehen, vor der viele Millionen und die meisten großen Unternehmen stehen.
Nehmen wir also an, dass es 500 Benutzer in Ihrer Organisation gibt und diese Organisation drei primäre
Dienste aktiv nutzt.
Erstens Hilfe, zumindest für die Infrastruktur.
Der zweite ist Jenkins und der dritte ist die altersbezogene Anwendung.
Und Ihre Rolle besteht im Wesentlichen darin, den Benutzern Zugriff auf alle drei Dienste zu gewähren.
Nehmen wir also an, dass alle Benutzer, alle 500 Benutzer innerhalb der Organisation Zugriff auf alle
diese drei Systeme haben müssen.
Nun, eine der Herausforderungen, die wir zuerst sehen werden, ist, dass Sie in allen diesen drei
Systemen individuelle Benutzer erstellen müssen.
Sie müssen also in beiden Listen einen IAM-Benutzer im HIV-Verwaltungssystem erstellen.
Auch hier müssen Sie Benutzer erstellen und so weiter.
Angenommen, ein neuer Benutzer ist Ihrer Organisation beigetreten oder ein neuer Benutzer verlässt Ihre Organisation.
Im Wesentlichen müssen Sie sich also bei allen diesen drei Anwendungen anmelden, um Benutzer hinzuzufügen oder zu entfernen.
Nehmen wir nun an, dass es zwei neue Anwendungen gibt, die in der Organisation eingehen.
Im Wesentlichen müssen Sie also wieder alle 500 Benutzer zu dem kommenden neuen Zwei-System hinzufügen, das geplant
ist.
Das ist also nicht wirklich eine sehr effiziente Art, Dinge zu tun.
Dies ist also eine der Herausforderungen, denen Sie in mittleren bis großen Organisationen wirklich begegnen werden.
Insbesondere wenn Sie über große Organisationen mit Tausenden von Benutzern sprechen, wird in
einem solchen Fall die Verwaltung der Benutzer über jedes einzelne System sowie die Identität nicht empfohlen.
Um dies zu überwinden, dient das System im Wesentlichen dazu, das Benutzerzentrum zu speichern.
Nehmen wir also an, Sie haben ein System.
In dieser alten App haben Sie also alle Benutzeridentitäten gespeichert.
Alle Benutzernamen und alle Passwörter werden also in diesem zentralen Verzeichnis gespeichert.
Und dieses einzelne Verzeichnis ist mit allen Systemen so verbunden, dass sich Benutzer aus der Zentrale direkt
mit Benutzername und Passwort bei allen diesen drei Systemen anmelden können.
Dies wird also zu einer viel effizienteren Architektur, da es nur einen einzigen Satz aus
Benutzername und Passwort gibt, der auf der Endebene und von Anfang an gespeichert wird.
Da zwischen all diesen Systemen eine Vertrauensstellung besteht, kann sich der Benutzer einfach anmelden.
Jedes Mal, wenn ein neuer Benutzer der Organisation beitritt, muss der Administrator lediglich seinen Benutzer als Teil
der alten App hinzufügen, und das war es auch schon.
Sie können sich bei all diesen drei Systemen anmelden, und vielleicht ist geplant, dass morgen ein neues System in
Ihrer Organisation hinzugefügt wird.
Alles, was Sie tun müssen, ist, entweder zwischen Ihrer alten App und diesem neuen System zu vertrauen, und alle
vorhandenen Benutzer können sich auch bei den neuen Systemen anmelden.
Mittlerweile gibt es viele Lösungen, die es uns ermöglichen, den Benutzer zentral zu speichern.
Einer der wichtigsten, von denen Sie vielleicht gehört haben, ist das Microsoft Active Directory.
Dies ist eine sehr beliebte Lösung, die es Ihnen ermöglicht, das Benutzerzentrum zu speichern und Ihnen auch eine geordnete
Verwaltung zu ermöglichen.
Die zweite beliebte speziell für Linux ist das Red Hat Identity Management, das auch als kostenlose App
bezeichnet wird.
Wenn Sie sich also den Screenshot ansehen, ist dies mit Active Directory verbunden und
Sie sehen, dass hier mehrere Benutzer hinzugefügt wurden und die Reihenfolge der Benutzerausgabe sehr einfach ist.
Sie sehen, dass Sie auf Neu klicken können und Sie können auf Benutzer klicken und ein neuer Benutzer wird zu Ihrem Active Directory hinzugefügt.
Nehmen wir nun an, Sie haben Active Directory und diese drei Systeme.
Was Sie tun müssen, müssen Sie entweder zwischen Ihrem Active Directory und diesen drei
Systemen so vertrauen, dass sich die Benutzer, die Teil Ihres Active Directory sind, je nach Richtlinie bei
allen diesen drei Systemen anmelden können du hast eingestellt.
Toll.
Lassen Sie uns damit fortfahren und die Grundlagen der Föderation aus idealistischer Perspektive verstehen.
Im Grunde ermöglicht der Verbund also externen Identitäten, die auch als Verbundbenutzer bezeichnet werden, ein gesichertes Zugangskonto
für innere Esswaren zu haben, ohne dass Benutzer und Benutzer erstellt werden müssen.
Wir haben also bereits besprochen, dass die Identitäten nicht an einem Ort gespeichert werden, diese werden
auf einem zentralen Server wie Active Directory gespeichert und alle diese Benutzer können sich bei Ihrem Konto anmelden.
Das ist es also, was das Federation-Konzept wirklich ins Spiel bringt.
Diese externen Identitäten können also aus verschiedenen Quellen stammen, z. B. kann der Anbieter von Unternehmensidentitäten
Active Directory IPA oder Webidentitätsanbieter sein.
Facebook.
Google.
Amazonas.
Inkognito oder mit offenem Ende, je nachdem, welchen Anwendungsfall Sie erreichen möchten.
Lassen Sie uns jetzt schnell einen Blick auf den High-Level-Workflow werfen, wenn wir über Federation sprechen.
Es gibt also drei primäre Einheiten, die beteiligt sind.
Der erste ist der Benutzer.
Der zweite ist der Dienstanbieter und der dritte der Identitätsanbieter.
Kein Dienstanbieter ist im Grunde diese Anwendung auf der rechten Seite, die wir besprochen haben, wie
Jenkins EAW ein Datenverwaltungssystem usw. ist.
Dies sind auch die Anbieter, die einige Dienste anbieten.
Dann haben Sie einen Identitätsanbieter aus dem Namen selbst.
Wir können erkennen, was genau das bewirkt.
Das schafft Identität.
Das bedeutet also im Grunde, dass die Benutzer auf der Ebene des Identitätsanbieters gespeichert werden und
zwischen dem Dienstanbieter und dem Identitätsanbieter eine Vertrauensbeziehung besteht.
Dieser Dienstanbieter vertraut also dem Identitätsanbieter, und daher können sich die Benutzer,
die von diesem Identitätsanbieter kommen, je nach den von Ihnen angegebenen Richtlinien beim Dienstanbieter
anmelden.
Gut.
Wenn Sie also in das Diagramm schauen, authentifiziert sich der Benutzer zunächst beim Identitätsanbieter.
Er authentifiziert sich nicht bei einem Dienstanbieter.
Das bedeutet also im Grunde genommen, dass dieser Workflow der von EWR ist.
Es ist also ein Dienstanbieter und es gibt einen Identitätsanbieter wie Okta.
Die Benutzer werden also auf der Oktanzahl gespeichert.
Benutzer werden nicht auf Datenbankebene gespeichert.
Der Benutzer authentifiziert sich also zuerst beim Identitätsanbieter.
Da nun eine Beziehung, eine Vertrauensbeziehung zwischen dem IDP und dem
Dienstanbieter besteht, kann der Benutzer, sobald er sich erfolgreich beim Identitätsanbieter authentifiziert hat, eine
erfolgreiche Anfrage an den Dienstanbieter von EWR stellen.
Lassen Sie uns also weitermachen und die Dinge schnell im Detail verstehen.
Das erste wichtige Konzept hier ist der Identitätsmakler.
Identity Broker ist also ein Zwischendienst, der hier mehrere Anbieter verbindet.
Unter Identität haben Sie also eine Idlis.
Auf der linken Seite haben Sie ein Active Directory, das alle Benutzernamen und Passwörter
für alle Mitarbeiter Ihrer Organisation enthält.
Also was willst du?
Sie möchten einen Dienst einschüchtern, der beides verbinden kann.
Dies wird also als Identitätsmakler bezeichnet.
Also lasst uns weitermachen und in das funktionierende Video schauen.
Auf der rechten Seite haben Sie den Ort, auf der linken Seite haben Sie das Active Directory und doch an
Ort und Stelle.
Daher müssen sich die Benutzer zunächst beim Identity Broker anmelden.
Dieser Identity Broker ist also mit dem Microsoft Active Directory verbunden.
Welcher Benutzername und welches Kennwort, die der Benutzer dem Identitätsbroker übermittelt hat, stimmen also im Grunde mit denen
überein, die in Active Directory gespeichert sind?
Hier findet also wirklich die Authentifizierung statt.
Der erste Schritt ist die Anmeldung.
Der zweite Schritt besteht darin, den Benutzer mit dem Active Directory zu authentifizieren.
Sobald die Authentifizierung erfolgreich ist, ruft dieser Identitätsbroker den A-Spear-Dienst auf und erhält
ein bestimmtes Token, und dann sendet der Identitätsbroker die entsprechende Antwort an den Client
zurück.
Und dieser Token wird wieder verwendet, um eine Verbindung zu den Amazon-Webdiensten herzustellen.
Also, wenn wir über diesen Autor diskutieren, ist dieser ein Token.
Dies ist nichts anderes als eine Reihe von Zugangs- und Geheimschlüsseln.
Somit werden den Benutzern Zugang und geheime Schlüssel bereitgestellt, und Benutzer können diese geheimen Zugangsschlüssel verwenden, um sich mit der
EWG zu verbinden.
Das ist also der übergeordnete Workflow, wie die Dinge aus föderierter Sicht funktionieren würden, denke ich.
Lassen Sie uns also fortfahren und die Schritte schnell überarbeiten.
Zuerst melden sich die Benutzer mit dem Benutzernamen und dem Passwort an, und diese Anmeldeinformationen werden an
den Identitätsbroker weitergegeben.
Jetzt validiert Identity Broker diese Anmeldeinformationen anhand des Active Directory.
In diesem Beispiel haben wir Active Directory genommen.
Wenn die Anmeldeinformationen gültig sind.
Wenn der Benutzername und das Passwort gültig sind, kontaktiert der Broker grundsätzlich den SDR-Dienst, da dieser
fortfahren und die Zugangssicherheit zurückgeben wird.
Und dieser geheime Zugangsschlüssel wird dem Benutzer vom Identitätsbroker bereitgestellt, und der Benutzer kann sich bei der
Datenbankkonsole anmelden oder diesen Satz von geheimen Zugangsschlüsseln zusammen mit dem spezifischen Token, das eine
bestimmte Dauer hat, sicher verwenden.
Wenn Sie sich also nicht erinnern können, wann wir über Identitäten diskutiert haben, Identitäten, nichts als die Benutzer.
Wenn wir also über unsere externen Identitäten sprechen, bedeutet das im Grunde, dass die Benutzer in einem externen
System gespeichert werden, nicht in IEM.
Zweitens ist Identity Broker, bei dem es sich im Grunde um Middleware handelt, die den Benutzer von Punkt B führt und ihm hilft, sich
mit Punkt B zu verbinden.
Und das dritte wichtige Konzept ist die gespeicherte Identität, die im Grunde ein Ort ist, an dem sich die Benutzer befinden,
aber wie andere Benutzer gespeichert werden.
Also Active Directory oder IP oder vielleicht Facebook.
Dies sind also im Grunde die gespeicherten Identitäten.
Nun, bevor wir zum Schluss kommen, sehr wichtige Dinge, die ich mitteilen wollte.
Der erste ist, dass dieser Dienstanbieter diese Funktionalität auch unterstützen sollte, damit die Föderation funktioniert, da wir
letztendlich über eine diskutiert haben.
Der Identitätsanbieter speichert die Identitäten und es entsteht eine Vertrauensbeziehung zwischen der bereitgestellten Identität und
der des Dienstanbieters.
Nun, wenn der Dienstanbieter diese Funktionalität überhaupt nicht wirklich unterstützt, dann können Sie nicht wirklich eine
Föderation haben.
Dies ist also ein wichtiger Teil, an den Sie sich erinnern sollten.
Wenn wir jetzt über Idlis sprechen, haben Sie beim Aufrufen der IAM-Konsole eine spezifische Option für
die des Identitätsanbieters.
Hier können Sie also fortfahren und mehrere Identitätsanbieter hinzufügen.
So müssen Sie im Menü Gordon-Identität grundsätzlich einen Anbietertyp sowie das Metadatendokument
Ihres Identitätsanbieters angeben.
Nehmen wir zum Beispiel an, Sie haben den Identitätsanbieter von OCTA ausgewählt.
OCTA ist also eine sehr beliebte Plattform für Identitätsanbieter.
Dieses Metadatendokument, über das wir gesprochen haben, stammt also von OCTA.
Nachdem Sie also die Anforderungseinstellungen in OCTA konfiguriert haben, können Sie fortfahren und dieses Metadatendokument
hochladen, nachdem Sie es von OCTA heruntergeladen haben.
Und so entsteht bei einem High-Level-Audit das Vertrauen wirklich zwischen einem Dienstanbieter und
dem des Identitätsanbieters.
Das ist also ein Teil.
Als zweites sprachen wir auch darüber, nehmen wir ein Beispiel von Jenkins.
Gehen wir schnell zu Manager Jenkins und konfigurieren die globale Sicherheit.
Was wir also in diesen Konten besprechen, die sich darauf beziehen, wie die Daten des Benutzers zentral in einem Labor gespeichert
werden, sollte in der Lage sein, sich bei einer bestimmten Anwendung wie Jenkins anzumelden.
Nun, wenn Jenkins das nicht veröffentlicht oder einfügt, dann wird dieses gesamte Konzept nicht wirklich funktionieren.
Daher muss Jenkins auch eine LDAP-spezifische Sichtweise unterstützen.
Wenn Sie also unter URI zu den Jenkins-Einstellungen gehen, haben Sie im Grunde zwei wichtige Optionen.
Die erste ist Jenkins eigene Benutzerdatenbank.
Das bedeutet im Grunde, dass Sie, wenn Sie fortfahren und einen Benutzer hinzufügen, ihn zur Jenkins-Datenbank hinzufügen und auch die Option haben,
dem Benutzer zu erlauben, zu sagen, nein, das ist einer.
Lassen Sie uns nun sehen, wie wir diskutieren, Sie möchten den Benutzer nicht wirklich individuell in einem individuellen System
erstellen.
Was willst du?
Du willst enden?
Sie haben hier also auch eine Option für ein Dashboard, in dem Sie die Wortdetails der Endepisode angeben
müssen.
Sobald Sie diesen Server haben, geben Sie die Details für Jenkins an, und sobald Sie die erforderliche
Konfiguration haben, können sich die Benutzer, die Teil eines LDAP sind, bei Jenkins Audio anmelden.
Recht.
Dies ist also die Übersicht auf hoher Ebene.
Falls Sie das wirklich interessiert, dann ist Okta eine beliebte Plattform, die Sie ausprobieren
können.
Sie haben auch mehrere damit verbundene Zertifizierungen, die ziemlich gut sind.
Darauf können Sie sich also freuen.
Das ist also die grobe Übersicht über Federation.
Und damit endet das heutige Video.