Und dann kommen Sie zurück, nicht in Griechenland, wir werden auf hoher Ebene einen Überblick über Lachs diskutieren.
Salmon steht also für die Markup-Sprache der Security Association und ist ein sicherer
XML-basierter Kommunikationsmechanismus zur Kommunikation der Identitäten zwischen den Organisationen.
Dieser Punkt wird hier gleich besser verstanden.
Dadurch entfällt die Notwendigkeit, mehrere Authentifizierungsdaten wie Passwörter an mehreren Standorten
zu verwalten.
Wenn Sie also den klassischen Weg betrachten, bei dem Sie mehrere Anwendungen und Dienste haben, die
in Ihrem Unternehmen ausgeführt werden und jede Anwendung ihre eigenen Identitäten hat.
Also hat Jenkins einen eigenen Benutzernamen und ein eigenes Passwort.
Der Editor hat einen eigenen Benutzernamen und ein eigenes Passwort im Sinne eines H. R. Verwaltungssoftware hat einen eigenen Benutzernamen und
ein eigenes Passwort usw.
Diese zu haben ist also ein bisschen schmerzhaft.
Schauen wir uns also einige der Herausforderungen auf klassische Weise an, die wir besprochen haben.
Der erste ist, dass der Administrator nicht wirklich die Sichtbarkeit mit der zugrunde liegenden Datenbank
des SAS-Anbieters hat.
Also diskutierten wir gerade über JENKINS'.
Wenn Sie also ein Jenkins' innerhalb Ihres eigenen Dienstes hosten, haben Sie eine gute Sichtbarkeit.
Aber es gibt viele Dienstleister, die Ihnen keine wirkliche Sichtbarkeit der Datenbank geben.
Und tatsächlich hat sich gezeigt, dass viele der Orte, an denen die Benutzernamen und
Passwörter gespeichert sind, der Speicherung im Klartext zugrunde liegen, und sogar große Organisationen sind hier beteiligt.
Das ist also eine große Herausforderung.
Die zweite Herausforderung besteht darin, dass es bei mehreren SaaS-Anbietern schwierig ist, den Überblick zu behalten,
welcher Benutzer Zugriff auf welche SaaS-Anwendung hat.
So kann es passieren, dass der Entwickler Zugriff auf Jenkins hat.
Der Entwickler Steve hat jedoch Zugriff auf die Datenbank und alle Benutzer haben Zugriff darauf.
Wenn also ein bestimmter Benutzer die Organisation verlässt, ist es am Ende schwierig herauszufinden, ob der Benutzer Zugriff auf
diese Anwendung hat, insbesondere wenn Sie möglicherweise eine Anwendung in Ihrer Organisation haben.
Und der dritte Punkt ist, dass der Benutzer, wenn er die Organisation verlässt, aus allen Entitäten
entfernt werden muss.
Es kann Jenkins, ET usw. sein. und so weiter.
Ich erinnere mich also noch daran, dass in der Organisation, mit der ich zusammengearbeitet habe, jeder
Benutzer, der die Organisation an seinem letzten Tag verlässt, ein Formular vorlegt und die Unterschrift der Behörde benötigt.
Er hat zum Beispiel Zugang zu einem VPN und kommt zu unserem Team und wir entfernen seinen Zugang und signieren ihn dann
in dem Dokument, das er an die API senden muss.
In solchen Fällen muss er also von jedem eine Unterschrift nehmen, die besagt, dass sein Benutzer und sein Zugang entfernt
werden, und Post wird dieses Formular an die ATO senden.
In den Organisationen, die nicht wirklich über Single Sign-On verfügen, ist es ein bisschen mühsam, solche Dinge zu tun, da
Sie jetzt seinen Zugriff manuell von allen Anwendungen entfernen müssen.
Schauen wir uns also die verschiedenen Ansichten hier in einem klassischen Ansatz an.
Der Administrator sieht hier im klassischen Ansatz also, dass er sich bei einem anderen Anbieter anmelden muss, um
die Berechtigungen eines einzelnen Benutzers im gesamten Unternehmen zu verwalten und zu kontrollieren.
Und für den Fall, dass er seinen Benutzernamen und sein Passwort vergessen hat und dieses möglicherweise für Amethi
verloren hat, muss der Administrator die neue MFA für alle Anwendungen festlegen.
Das ist also ein bisschen schmerzhaft.
Zweitens muss sich die Benutzeransicht das Kennwort aller Anwendungen innerhalb der Organisation
merken.
Und es könnte auch vorhanden sein, dass die Nutzungsidee der Nutzer über die Anwendungen hinweg unterschiedlich ist.
Dies ist also offener und bietet eine breitere Sicht der Site. Falls der Diensteanbieter den
Benutzernamen und das Passwort speichert, muss der Diensteanbieter die Benutzernamen- und Passwortdatenbank seiner
Kunden pflegen.
Und für den Fall, dass diese Datenbank durchgesickert ist, ist dies ein großes Sicherheitsrisiko dieses Aspirators.
In der klassischen Ansicht sind also der Administrator, der Benutzer sowie der Südflorida nicht alle glücklich.
Jetzt kommt also der bessere Weg, der gleich ist.
Zusammenfassend haben Sie also einen Identitätsanbieter und einen Dienstanbieter, Banzet.
Der Dienstanbieter kann also der von Jenkins sein, es kann EWR sein, es kann ein Setup sein und so weiter.
Und der Identitätsanbieter ist derjenige, der alle Identitäten speichert.
Anstatt also alle Identitäten bei einem Dienstanbieter zu speichern, verschieben wir diese Identität auf die Website des
Identitätsanbieters.
Schauen wir uns also das Workflow-Diagramm an, in dem Sie den Identitätsanbieter haben, alles was das ist.
Und der Dienstleister für ADP.
Was hier also passieren wird, ist die Verwendung seiner ersten Anmeldung beim Identitätsanbieter, der Identitätsanbieter
überprüft, ob die Anmeldeinformationen korrekt sind und eine Antwort wird gesagt.
Der Benutzer wird also fortfahren und diese Antwort an den Dienstanbieter und den Dienstanbieter senden.
Wenn die Antwort wie erwartet ausfällt, wird sie an den Unternehmensberater weitergeleitet.
Denken Sie also daran, dass eine Vertrauensstellung zwischen dem Identitätsanbieter und dem Dienstanbieter
bestehen muss, damit der Dienstanbieter diese Antwort akzeptieren kann, bevor dieser gesamte
Vorgang funktioniert.
Das ist also der Samawi.
Und diese Antwort kann auch als diese Samael-Behauptung bezeichnet werden.
Schauen wir uns also die hohe Ebene an oder so wird der Flow initiiert, wenn der Benutzer besorgt das ADP öffnet und
den Benutzernamen und das Passwort eingibt und die entsprechende Anwendung auswählt oder so kann die Anwendung ein kantiger
Jenkins sein und so weiter.
Der Identitätsanbieter validiert also die Anmeldeinformationen und die zugehörigen Berechtigungen, verwendet sie dann und
erhält eine Samit-Assertion vom Teil der Antwort des IDPs.
Also, wissen Sie, wir haben diese Antwort besprochen.
Dies ist im Grunde diese Samin-Behauptung, die der Benutzer erhält.
Sobald der Benutzer diese Behauptung erhalten hat, führt der Benutzer den größten Teil
dieser Samin-Behauptung auf der Quellsignaturseite aus und der Dienstanbieter validiert diese Behauptung bei der Validierung.
Der Dienstanbieter erstellt relevante temporäre Anmeldeinformationen und erstellt auch einen Unterzeichnungsbefehl für die Konsole und
sendet ihn an den Benutzer zurück.
Das ist also die oberste Ebene, auf der wir uns schnell eine Demo ansehen, damit dies besser verstanden
wird.
Der erste Schritt, den wir diskutieren, besteht darin, dass der Benutzer einen Benutzernamen und ein Kennwort an den
Identitätsanbieter senden muss.
Sie wären also ein Anliegen, etwas Ähnliches, und der Benutzername und das Passwort des Benutzers müssten gesendet
werden.
Versuchen wir es also im Raster.
Die Authentifizierung war also erfolgreich.
Wenn Sie hierher schauen, muss der Benutzer nach erfolgreicher Authentifizierung die
entsprechende Anwendung auswählen, da mehrere Anwendungen vorhanden sein können.
Es kann also eine Datenbank sein, es kann Jenkins' sein, es können andere sein.
Also je nach Anwendung, weil der Dienstanbieter alles ändert, so hat man einen Dienstanbieter von
einem W. S. Jenkins usw..
Das ist also wichtig.
Was also passieren wird, hängt davon ab, welchen Dienstanbieter der Benutzer wählt, die entsprechende Samin-Behauptung
wird gesagt.
Also probieren wir es aus.
Sobald ich also auf die Verwaltungskonsole klicke, die gerade dauerhaft ist, sehen Sie, dass es
Stammen ist und es sich im Grunde anmeldet und es überprüft und Sie im Konto angemeldet sind.
Hinter den Kulissen ist also etwas passiert.
Wie Sie die Lachsbehauptung erhalten haben, wurde die Salmon Association an den Dienstleister weitergeleitet.
Der Dienstanbieter hatte diesen Lachs, wie gesagt, validiert, und er würde umgeleitet an die Management-Konsole
hinzufügen.
Lassen Sie uns also eines tun, um es besser zu verstehen.
Ich habe in meiner Crew einen Sunday Presser installiert, und wir verwenden ihn, um zu sehen, was genau hinter den Kulissen passiert, um
diesen Prozess auf hoher Ebene zu verstehen.
Gut.
Als erstes klickt der Benutzer auf die Verwaltungskonsole.
Es meldet Sie also an und Sie unterschreiben.
So lass uns gehen.
Und.
Also lassen Sie mich jetzt maximieren.
Das erste, was hier also im Grunde genommen wird, ist, dass die Gate-Anfrage gestellt wird.
Dies ist also die Gate-Anfrage, die hier an die ISS gestellt wird.
Nun, wenn Sie hier rüberschauen, gibt es jetzt auch Post, da wir besprochen haben, dass nach Erhalt
dieser Behauptung die Post an den Dienstanbieter gesendet wird.
Wenn Sie sich also diese spezielle Beitragsanfrage ansehen, wurde dieser Beitrag an diese Signierseite von Dawe mit Lachs
gesendet.
Denken Sie also daran, dass Eatables ein separates Büro für die Authentifizierung hat, wenn Sie Lachs verwenden.
Dies ist also genau der Bereich, in dem Sie Ihre Lachsbehauptung versenken müssen, wie Sie besprochen haben,
als Sie eine Lachsbehauptung erhalten haben.
Diese Erklärung muss im Falle eines Geräts an eine bestimmte Adresse gesendet werden.
Es ist diese Eweida.
Hier passiert also der Beitrag.
Und wenn Sie sich den Lachs ansehen, ist dies die Lachsbehauptung, an die gesendet wird, wissen Sie,
wenn Sie untergehen.
Es gibt eine kleine Lesung, die eingeht und in dieser Weiterleitung, wenn Sie sich den Standort ansehen, ist dies
der Standort, der von der AWB geteilt wird.
Ähnlich wie wir es besprechen, wird eine ähnliche Lösung an den Dienstanbieter gesendet, der
Dienstanbieter wird dies überprüfen und dann eine Weiterleitung an die Verwaltungskonsole senden.
Und das ist, was passiert ist.
Das ist also die allgemeine Übersicht über Simon.
Und wir schauen uns auch an, wie die einzelnen Sinon-Anbieter Samin nutzen können, um vorzugehen und Benutzern zu ermöglichen, sich
mit einem bestimmten Dienstanbieter zu verbinden, damit dies dieses Video abschließt.
Ich hoffe, dieses Video war für Sie informativ.
Und ich freue mich, Sie im nächsten Video zu sehen.