Wie man SAML-Anmeldung mit Go erstellt

Für unsere neuen Freunde:

Logto ist eine Auth0-Alternative, die für moderne Apps und SaaS-Produkte entwickelt wurde. Es bietet sowohl Cloud als auch Open-Source Dienste, um dir zu helfen, dein Identity and Management (IAM) System schnell zu starten. Genieße Authentifizierung, Autorisierung und Multi-Tenant-Management alles in einem.

Wir empfehlen, mit einem kostenlosen Entwicklungsmieter auf Logto Cloud zu beginnen. Dies ermöglicht es dir, alle Funktionen einfach zu erkunden.

In diesem Artikel werden wir die Schritte durchgehen, um schnell die SAML Anmeldeerfahrung (Benutzerauthentifizierung) mit Go und Logto aufzubauen.

Voraussetzungen

Eine laufende Logto-Instanz. Sieh dir die Einführungsseite an, um loszulegen.
Grundkenntnisse in Go.
Ein nutzbares SAML Konto.

Eine Anwendung in Logto erstellen

Logto basiert auf OpenID Connect (OIDC) Authentifizierung und OAuth 2.0 Autorisierung. Es unterstützt föderiertes Identitätsmanagement über mehrere Anwendungen hinweg, was allgemein als Single Sign-On (SSO) bezeichnet wird.

Um deine Traditionelle Webanwendung Anwendung zu erstellen, folge einfach diesen Schritten:

Öffne die Logto Console. Klicke im Abschnitt "Erste Schritte" auf den Link "Alle anzeigen", um die Liste der Anwendungs-Frameworks zu öffnen. Alternativ kannst du zu Logto Console > Applications navigieren und auf die Schaltfläche "Anwendung erstellen" klicken.
Klicke im sich öffnenden Modal auf den Abschnitt "Traditionelle Webanwendung" oder filtere alle verfügbaren "Traditionelle Webanwendung" Frameworks mit den Schnellfilter-Checkboxen auf der linken Seite. Klicke auf die "Go" Framework-Karte, um mit der Erstellung deiner Anwendung zu beginnen.
Gib den Anwendungsnamen ein, z. B. "Buchladen", und klicke auf "Anwendung erstellen".

🎉 Ta-da! Du hast gerade deine erste Anwendung in Logto erstellt. Du wirst eine Glückwunschseite sehen, die einen detaillierten Integrationsleitfaden enthält. Folge dem Leitfaden, um zu sehen, wie die Erfahrung in deiner Anwendung sein wird.

Go SDK integrieren

tipp:

Die folgende Demonstration basiert auf dem Gin Web Framework. Du kannst Logto auch in andere Frameworks integrieren, indem du die gleichen Schritte befolgst.
Das Go-Beispielprojekt ist in unserem Go SDK-Repo verfügbar.

Installation

Führe im Stammverzeichnis des Projekts aus:

go get github.com/logto-io/go

Füge das github.com/logto-io/go/client-Paket zu deinem Anwendungscode hinzu:

main.go
// main.go
package main

import (
	"github.com/gin-gonic/gin"
	// Abhängigkeit hinzufügen
	"github.com/logto-io/go/client"
)

func main() {
	router := gin.Default()
	router.GET("/", func(c *gin.Context) {
		c.String(200, "Hello Logto!")
	})
	router.Run(":3000")
}

Erstelle einen Sitzungspeicher

In traditionellen Webanwendungen werden die Benutzer-Authentifizierungsinformationen in der Benutzersitzung gespeichert.

Das Logto SDK bietet eine Storage-Schnittstelle, mit der du einen Storage-Adapter basierend auf deinem Web-Framework implementieren kannst, sodass das Logto SDK die Benutzer-Authentifizierungsinformationen in der Sitzung speichern kann.

hinweis:

Wir empfehlen NICHT die Verwendung von cookie-basierten Sitzungen, da die von Logto gespeicherten Benutzer-Authentifizierungsinformationen die Cookie-Größenbeschränkung überschreiten können. In diesem Beispiel verwenden wir speicherbasierte Sitzungen. Du kannst Redis, MongoDB und andere Technologien in der Produktion verwenden, um Sitzungen nach Bedarf zu speichern.

Der Storage-Typ im Logto SDK sieht wie folgt aus:

github.com/logto-io/client/storage.go
package client

type Storage interface {
	GetItem(key string) string
	SetItem(key, value string)
}

Wir verwenden die github.com/gin-contrib/sessions Middleware als Beispiel, um diesen Prozess zu demonstrieren.

Wende die Middleware auf die Anwendung an, damit wir die Benutzersitzung durch den Benutzeranforderungskontext im Routen-Handler erhalten können:

main.go
package main

import (
	"github.com/gin-contrib/sessions"
	"github.com/gin-contrib/sessions/memstore"
	"github.com/gin-gonic/gin"
	"github.com/logto-io/go/client"
)

func main() {
	router := gin.Default()

	// Wir verwenden speicherbasierte Sitzungen in diesem Beispiel
	store := memstore.NewStore([]byte("dein Sitzungsschlüssel"))
	router.Use(sessions.Sessions("logto-session", store))

	router.GET("/", func(ctx *gin.Context) {
		// Benutzersitzung abrufen
		session := sessions.Default(ctx)
		// ...
		ctx.String(200, "Hallo Logto!")
	})
	router.Run(":3000")
}

Erstelle eine session_storage.go-Datei, definiere eine SessionStorage und implementiere die Storage-Schnittstellen des Logto SDK:

session_storage.go
package main

import (
	"github.com/gin-contrib/sessions"
)

type SessionStorage struct {
	session sessions.Session
}

func (storage *SessionStorage) GetItem(key string) string {
	value := storage.session.Get(key)
	if value == nil {
		return ""
	}
	return value.(string)
}

func (storage *SessionStorage) SetItem(key, value string) {
	storage.session.Set(key, value)
	storage.session.Save()
}

Jetzt kannst du im Routen-Handler einen Sitzungs-Speicher für Logto erstellen:

session := sessions.Default(ctx)
sessionStorage := &SessionStorage{session: session}

Init LogtoClient

Zuerst erstelle eine Logto-Konfiguration:

main.go
func main() {
	// ...
	logtoConfig := &client.LogtoConfig{
		Endpoint:  "<your-logto-endpoint>", // Z.B. http://localhost:3001
		AppId:     "<your-application-id>",
		AppSecret: "<your-application-secret>",
	}
	// ...
}

tipp:

Du kannst das "App Secret" auf der Anwendungsdetailseite in der Admin-Konsole finden und kopieren:

Dann kannst du einen LogtoClient für jede Benutzeranfrage mit der obigen Logto-Konfiguration erstellen:

main.go
func main() {
	// ...

	router.GET("/", func(ctx *gin.Context) {
		// LogtoClient erstellen
		session := sessions.Default(ctx)
		logtoClient := client.NewLogtoClient(
			logtoConfig,
			&SessionStorage{session: session},
		)

		// Verwende Logto, um den Inhalt der Startseite zu steuern
		authState := "Du bist nicht auf dieser Website angemeldet. :("

		if logtoClient.IsAuthenticated() {
			authState = "Du bist auf dieser Website angemeldet! :)"
		}

		homePage := `<h1>Hallo Logto</h1>` +
			"<div>" + authState + "</div>"

		ctx.Data(http.StatusOK, "text/html; charset=utf-8", []byte(homePage))
	})

	// ...
}

Nachdem die Redirect-URI konfiguriert wurde, fügen wir eine sign-in-Route hinzu, um die Anmeldeanfrage zu bearbeiten, und fügen auch einen Anmeldelink auf der Startseite hinzu:

main.go
func main() {
	// ...

	// Füge einen Link hinzu, um eine Anmeldeanfrage auf der Startseite durchzuführen
	router.GET("/", func(ctx *gin.Context) {
		// ...
		homePage := `<h1>Hello Logto</h1>` +
			"<div>" + authState + "</div>" +
			// Link hinzufügen
			`<div><a href="/sign-in">Sign In</a></div>`

		ctx.Data(http.StatusOK, "text/html; charset=utf-8", []byte(homePage))
	})

	// Füge eine Route hinzu, um Anmeldeanfragen zu bearbeiten
	router.GET("/sign-in", func(ctx *gin.Context) {
		session := sessions.Default(ctx)
		logtoClient := client.NewLogtoClient(
			logtoConfig,
			&SessionStorage{session: session},
		)

		// Die Anmeldeanfrage wird von Logto bearbeitet.
		// Der Benutzer wird zur Redirect-URI weitergeleitet, nachdem er sich angemeldet hat.
		signInUri, err := logtoClient.SignIn("http://localhost:3000/callback")
		if err != nil {
			ctx.String(http.StatusInternalServerError, err.Error())
			return
		}

		// Leite den Benutzer zur Logto-Anmeldeseite weiter.
		ctx.Redirect(http.StatusTemporaryRedirect, signInUri)
	})

	// ...
}

Jetzt, wenn dein Benutzer http://localhost:3000/sign-in besucht, wird der Benutzer zur Logto-Anmeldeseite weitergeleitet.

Implementiere die Callback-Route

Wenn sich der Benutzer erfolgreich auf der Logto-Anmeldeseite anmeldet, wird Logto den Benutzer zur Redirect-URI weiterleiten.

Da die Redirect-URI http://localhost:3000/callback ist, fügen wir die Route /callback hinzu, um den Callback nach der Anmeldung zu bearbeiten.

main.go
func main() {
	// ...

	// Füge eine Route hinzu, um Anmelde-Callback-Anfragen zu bearbeiten
	router.GET("/callback", func(ctx *gin.Context) {
		session := sessions.Default(ctx)
		logtoClient := client.NewLogtoClient(
			logtoConfig,
			&SessionStorage{session: session},
		)

		// Die Anmelde-Callback-Anfrage wird von Logto bearbeitet
		err := logtoClient.HandleSignInCallback(ctx.Request)
		if err != nil {
			ctx.String(http.StatusInternalServerError, err.Error())
			return
		}

		// Springe zur Seite, die vom Entwickler angegeben wurde.
		// In diesem Beispiel wird der Benutzer zur Startseite zurückgeführt.
		ctx.Redirect(http.StatusTemporaryRedirect, "/")
	})

	// ...
}

Implementiere die Abmelderoute

Ähnlich wie beim Anmeldefluss wird Logto den Benutzer nach dem Abmelden zur Post-Sign-out-Redirect-URI weiterleiten.

Fügen wir nun die sign-out-Route hinzu, um die Abmeldeanfrage zu bearbeiten, und fügen wir auch einen Abmeldelink auf der Startseite hinzu:

main.go
func main() {
	// ...

	// Füge einen Link hinzu, um eine Abmeldeanfrage auf der Startseite durchzuführen
	router.GET("/", func(ctx *gin.Context) {
		// ...
		homePage := `<h1>Hello Logto</h1>` +
			"<div>" + authState + "</div>" +
			`<div><a href="/sign-in">Sign In</a></div>` +
			// Link hinzufügen
			`<div><a href="/sign-out">Sign Out</a></div>`

		ctx.Data(http.StatusOK, "text/html; charset=utf-8", []byte(homePage))
	})

	// Füge eine Route hinzu, um Abmeldeanfragen zu bearbeiten
	router.GET("/sign-out", func(ctx *gin.Context) {
		session := sessions.Default(ctx)
		logtoClient := client.NewLogtoClient(
			logtoConfig,
			&SessionStorage{session: session},
		)

		// Die Abmeldeanfrage wird von Logto bearbeitet.
		// Der Benutzer wird zur Post-Sign-out-Redirect-URI weitergeleitet, nachdem er abgemeldet wurde.
		signOutUri, signOutErr := logtoClient.SignOut("http://localhost:3000")

		if signOutErr != nil {
			ctx.String(http.StatusOK, signOutErr.Error())
			return
		}

		ctx.Redirect(http.StatusTemporaryRedirect, signOutUri)
	})

	// ...
}

Nachdem der Benutzer eine Abmeldeanfrage gestellt hat, wird Logto alle Benutzer-Authentifizierungsinformationen in der Sitzung löschen.

Checkpoint: Teste deine Anwendung

Jetzt kannst du deine Anwendung testen:

Starte deine Anwendung, du wirst den Anmeldebutton sehen.
Klicke auf den Anmeldebutton, das SDK wird den Anmeldeprozess initiieren und dich zur Logto-Anmeldeseite weiterleiten.
Nachdem du dich angemeldet hast, wirst du zurück zu deiner Anwendung geleitet und siehst den Abmeldebutton.
Klicke auf den Abmeldebutton, um den Token-Speicher zu leeren und dich abzumelden.

SAML Connector hinzufügen

Um eine schnelle Anmeldung zu ermöglichen und die Benutzerkonversion zu verbessern, verbinde dich mit Go als Identitätsanbieter (IdP). Der Logto Social Connector hilft dir, diese Verbindung in wenigen Minuten herzustellen, indem er mehrere Parameter-Eingaben ermöglicht.

Um einen Social Connector hinzuzufügen, folge einfach diesen Schritten:

Navigiere zu Console > Connectors > Social Connectors.
Klicke auf "Add social connector" und wähle "SAML".
Folge der README-Anleitung und fülle die erforderlichen Felder aus und passe die Einstellungen an.

hinweis:

Wenn du der In-Place Connector-Anleitung folgst, kannst du den nächsten Abschnitt überspringen.

Standard SAML-App einrichten

Konto des sozialen IdP erstellen und SAML-Anwendung registrieren (IdP)

Lassen Sie uns die Konfigurationen des SAML-Connectors durchgehen.

Bevor wir beginnen, können Sie zu einem sozialen Identitätsanbieter gehen, der das SAML-Protokoll unterstützt, und Ihr eigenes Konto erstellen. Okta, OneLogin, Salesforce und einige andere Plattformen unterstützen Authentifizierung basierend auf dem SAML-Protokoll.

Wenn Ihr IdP die Verschlüsselung der SAML-Assertion und den Empfang von signierten Authentifizierungsanfragen vorschreibt, sollten Sie Ihren privaten Schlüssel und das entsprechende Zertifikat mit dem RSA-Algorithmus generieren. Bewahren Sie den privaten Schlüssel für Ihre SP-Nutzung auf und laden Sie das Zertifikat zum IdP hoch.

Sie müssen auch die ACS (Assertion Consumer Service) URL als ${your_logto_origin}/api/authn/saml/${connector_id} konfigurieren, um die SAML-Assertion des IdP zu verarbeiten. Ihren connectorId finden Sie auf der Detailseite des SAML-Connectors in der Logto Admin-Konsole.

hinweis:

Nach dem aktuellen Design von Logto unterstützen wir nur Redirect-Binding für das Senden von Authentifizierungsanfragen und POST-Binding für den Empfang von SAML-Assertionen. Obwohl das nicht besonders cool klingt, glauben wir, dass das aktuelle Design die meisten Ihrer Anwendungsfälle abdecken kann. Wenn Sie Probleme haben, zögern Sie nicht, uns zu kontaktieren!

SAML-Connector konfigurieren (SP)

In diesem Abschnitt werden wir jedes Attribut im Detail vorstellen.

entityID `Erforderlich`

entityID (d. h. issuer) ist der Entitätsbezeichner. Es wird verwendet, um Ihre Entität (SAML SP-Entität) zu identifizieren und die Gleichwertigkeit in jeder SAML-Anfrage/-Antwort abzugleichen.

signInEndpoint `Erforderlich`

Der Endpunkt des IdP, an den Sie SAML-Authentifizierungsanfragen senden. Normalerweise finden Sie diesen Wert auf der Detailseite des IdP (d. h. SSO URL oder Login URL des IdP).

x509Certificate `Erforderlich`

Das x509-Zertifikat, das aus dem privaten Schlüssel des IdP generiert wurde. Der IdP sollte diesen Wert verfügbar haben.

Der Inhalt des Zertifikats beginnt mit dem Header -----BEGIN CERTIFICATE----- und endet mit dem Abschluss -----END CERTIFICATE-----.

idpMetadataXml `Erforderlich`

Dieses Feld wird verwendet, um Inhalte aus Ihrer IdP-Metadaten-XML-Datei zu platzieren.

hinweis:

Der von uns verwendete XML-Parser unterstützt keine benutzerdefinierten Namespaces. Wenn die IdP-Metadaten mit einem Namespace versehen sind, sollten Sie diese manuell entfernen. Für den Namespace der XML-Datei siehe Referenz.

assertionConsumerServiceUrl `Erforderlich`

Die Assertion Consumer Service (ACS) URL ist der Endpunkt des SP, um die SAML-Assertion POST-Anfragen des IdP zu empfangen. Wie im vorherigen Teil erwähnt, wird sie normalerweise in den IdP-Einstellungen konfiguriert, aber einige IdP erhalten diesen Wert aus SAML-Authentifizierungsanfragen, daher fügen wir diesen Wert auch als ERFORDERLICHES Feld hinzu. Sein Wert sollte wie ${your_logto_origin}/api/authn/saml/${connector_id} aussehen.

signAuthnRequest

Der boolesche Wert, der steuert, ob die SAML-Authentifizierungsanfrage signiert werden soll, dessen Standardwert false ist.

encryptAssertion

encryptAssertion ist ein boolescher Wert, der angibt, ob der IdP die SAML-Assertion verschlüsseln wird, mit dem Standardwert false.

hinweis:

Die Attribute signAuthnRequest und encryptAssertion sollten mit den entsprechenden Parametern der IdP-Einstellung übereinstimmen, andernfalls wird ein Fehler angezeigt, der zeigt, dass die Konfiguration nicht übereinstimmt. Alle SAML-Antworten müssen signiert sein.

requestSignatureAlgorithm

Dies sollte mit den Signaturalgorithmen des IdP übereinstimmen, damit Logto die Signatur der SAML-Assertion überprüfen kann. Sein Wert sollte entweder http://www.w3.org/2000/09/xmldsig#rsa-sha1, http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 oder http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 sein und der Standardwert ist http://www.w3.org/2001/04/xmldsig-more#rsa-sha256.

messageSigningOrder

messageSigningOrder gibt die Signier- und Verschlüsselungsreihenfolge des IdP an, sein Wert sollte entweder sign-then-encrypt oder encrypt-then-sign sein und der Standardwert ist sign-then-encrypt.

privateKey und privateKeyPass

privateKey ist ein OPTIONALER Wert und wird benötigt, wenn signAuthnRequest true ist.

privateKeyPass ist das Passwort, das Sie beim Erstellen von privateKey festgelegt haben, erforderlich, wenn nötig.

Wenn signAuthnRequest true ist, wird das entsprechende Zertifikat, das aus privateKey generiert wurde, vom IdP benötigt, um die Signatur zu überprüfen.

encPrivateKey und encPrivateKeyPass

encPrivateKey ist ein OPTIONALER Wert und wird benötigt, wenn encryptAssertion true ist.

encPrivateKeyPass ist das Passwort, das Sie beim Erstellen von encPrivateKey festgelegt haben, erforderlich, wenn nötig.

Wenn encryptAssertion true ist, wird das entsprechende Zertifikat, das aus encPrivateKey generiert wurde, vom IdP benötigt, um die SAML-Assertion zu verschlüsseln.

hinweis:

Für die Generierung von Schlüsseln und Zertifikaten ist openssl ein hervorragendes Werkzeug. Hier ist eine Beispiel-Befehlszeile, die hilfreich sein könnte:

openssl genrsa -passout pass:${privateKeyPassword} -out ${encryptPrivateKeyFilename}.pem 4096
openssl req -new -x509 -key ${encryptPrivateKeyFilename}.pem -out ${encryptionCertificateFilename}.cer -days 3650

privateKey- und encPrivateKey-Dateien müssen im pkcs1-Schema als PEM-String codiert sein, was bedeutet, dass die privaten Schlüsseldateien mit -----BEGIN RSA PRIVATE KEY----- beginnen und mit -----END RSA PRIVATE KEY----- enden sollten.

nameIDFormat

nameIDFormat ist ein OPTIONALES Attribut, das das Name-ID-Format deklariert, das antworten würde. Der Wert kann unter urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified, urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName, urn:oasis:names:tc:SAML:2.0:nameid-format:persistent und urn:oasis:names:tc:SAML:2.0:nameid-format:transient sein, und der Standardwert ist urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified.

timeout

timeout ist die Zeitdifferenz für die Zeitvalidierung, da die Zeit zwischen Ihrer SP-Entität und der IdP-Entität unterschiedlich sein könnte und die Netzwerkverbindung auch einige Verzögerungen mit sich bringen kann. Die Einheit ist in Millisekunden, und der Standardwert ist 5000 (d. h. 5s).

profileMap

Logto bietet auch ein profileMap-Feld, mit dem Benutzer die Zuordnung von den sozialen Anbieterprofilen, die normalerweise nicht standardisiert sind, anpassen können. Jeder profileMap-Schlüssel ist der standardmäßige Benutzerprofil-Feldname von Logto und der entsprechende Wert sollte der soziale Profilfeldname sein. In der aktuellen Phase interessiert sich Logto nur für 'id', 'name', 'avatar', 'email' und 'phone' aus dem sozialen Profil, nur 'id' ist ERFORDERLICH und andere sind optionale Felder.

Konfigurationstypen

Name	Typ	Erforderlich	Standardwert
signInEndpoint	string	true
x509certificate	string	true
idpMetadataXml	string	true
entityID	string	true
assertionConsumerServiceUrl	string	true
messageSigningOrder	`encrypt-then-sign` \| `sign-then-encrypt`	false	`sign-then-encrypt`
requestSignatureAlgorithm	`http://www.w3.org/2000/09/xmldsig#rsa-sha1` \| `http://www.w3.org/2001/04/xmldsig-more#rsa-sha256` \| `http://www.w3.org/2001/04/xmldsig-more#rsa-sha512`	false	`http://www.w3.org/2001/04/xmldsig-more#rsa-sha256`
signAuthnRequest	boolean	false	false
encryptAssertion	boolean	false	false
privateKey	string	false
privateKeyPass	string	false
nameIDFormat	`urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified` \| `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress` \| `urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName` \| `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent` \| `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`	false	`urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified`
timeout	number	false	5000
profileMap	ProfileMap	false

ProfileMap-Felder	Typ	Erforderlich	Standardwert
id	string	false	id
name	string	false	name
avatar	string	false	avatar
email	string	false	email
phone	string	false	phone

Referenz

Konfiguration speichern

Überprüfe, ob du alle notwendigen Werte im Logto Connector-Konfigurationsbereich ausgefüllt hast. Klicke auf "Speichern und Fertig" (oder "Änderungen speichern") und der SAML Connector sollte jetzt verfügbar sein.

Sobald du einen sozialen Connector erfolgreich erstellt hast, kannst du ihn als "Weiter mit SAML"-Button in der Anmeldeerfahrung aktivieren.

Navigiere zu Konsole > Anmeldeerfahrung > Registrierung und Anmeldung.
(Optional) Wähle "Nicht zutreffend" für das Registrierungskennzeichen, wenn du nur die soziale Anmeldung benötigst.
Füge den konfigurierten SAML Connector zum Abschnitt "Soziale Anmeldung" hinzu.

Anmeldeerfahrungs-Tab

Testen und Validieren

Kehre zu deiner Go-App zurück. Du solltest dich jetzt mit SAML anmelden können. Viel Spaß!

Weiterführende Lektüre

Endbenutzerflüsse: Logto bietet sofort einsatzbereite Authentifizierungsflüsse, einschließlich Multi-Faktor-Authentifizierung (MFA) und Enterprise SSO, zusammen mit leistungsstarken APIs für die flexible Implementierung von Kontoeinstellungen, Sicherheitsüberprüfung und Multi-Tenant-Erfahrung.

Autorisierung: Autorisierung (Authorization) definiert die Aktionen, die ein Benutzer ausführen kann, oder die Ressourcen, auf die er nach der Authentifizierung zugreifen kann. Erfahre, wie du deine API für native und Single-Page-Anwendungen schützen und rollenbasierte Zugangskontrolle (RBAC) implementieren kannst.

Organisationen: Besonders effektiv in Multi-Tenant-SaaS- und B2B-Anwendungen, ermöglicht die Organisationsfunktion die Erstellung von Mandanten, das Mitgliedermanagement, organisationsweite RBAC und Just-in-Time-Bereitstellung.

Kunden-IAM-Serie: Unsere Blogserie über Customer (oder Consumer) Identity and Access Management, von den Grundlagen bis zu fortgeschrittenen Themen und darüber hinaus.

Eine Anwendung in Logto erstellen​

Go SDK integrieren​

Installation​

Erstelle einen Sitzungspeicher​

Init LogtoClient​

Implementiere die Anmelderoute​

Implementiere die Callback-Route​

Implementiere die Abmelderoute​

Checkpoint: Teste deine Anwendung​

SAML Connector hinzufügen​

Standard SAML-App einrichten​

Konto des sozialen IdP erstellen und SAML-Anwendung registrieren (IdP)​

SAML-Connector konfigurieren (SP)​

entityID Erforderlich​

signInEndpoint Erforderlich​

x509Certificate Erforderlich​

idpMetadataXml Erforderlich​

assertionConsumerServiceUrl Erforderlich​

signAuthnRequest​

encryptAssertion​

requestSignatureAlgorithm​

messageSigningOrder​

privateKey und privateKeyPass​

encPrivateKey und encPrivateKeyPass​

nameIDFormat​

timeout​

profileMap​

Konfigurationstypen​

Referenz​

Konfiguration speichern​

SAML Connector in der Anmeldeerfahrung aktivieren​

Testen und Validieren​

Weiterführende Lektüre​

Eine Anwendung in Logto erstellen

Go SDK integrieren

Installation

Erstelle einen Sitzungspeicher

Init LogtoClient

Implementiere die Anmelderoute

Implementiere die Callback-Route

Implementiere die Abmelderoute

Checkpoint: Teste deine Anwendung

SAML Connector hinzufügen

Standard SAML-App einrichten

Konto des sozialen IdP erstellen und SAML-Anwendung registrieren (IdP)

SAML-Connector konfigurieren (SP)

entityID `Erforderlich`

signInEndpoint `Erforderlich`

x509Certificate `Erforderlich`

idpMetadataXml `Erforderlich`

assertionConsumerServiceUrl `Erforderlich`

signAuthnRequest

encryptAssertion

requestSignatureAlgorithm

messageSigningOrder

privateKey und privateKeyPass

encPrivateKey und encPrivateKeyPass

nameIDFormat

timeout

profileMap

Konfigurationstypen

Referenz

Konfiguration speichern

SAML Connector in der Anmeldeerfahrung aktivieren

Testen und Validieren

Weiterführende Lektüre