Zum Hauptinhalt springen
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 .NET Core (MVC) und Logto aufzubauen.

Voraussetzungen

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:

  1. Ö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. Erste Schritte
  2. 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 ".NET Core (MVC)" Framework-Karte, um mit der Erstellung deiner Anwendung zu beginnen. Frameworks
  3. 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.

.NET Core (MVC) SDK integrieren​

tipp:
  • Die folgende Demonstration basiert auf .NET Core 8.0. Das SDK ist kompatibel mit .NET 6.0 oder höher.
  • Die .NET Core-Beispielprojekte sind im GitHub-Repository verfügbar.

Installation​

Füge das NuGet-Paket zu deinem Projekt hinzu:

dotnet add package Logto.AspNetCore.Authentication

Logto-Authentifizierung hinzufügen​

Öffne Startup.cs (oder Program.cs) und füge den folgenden Code hinzu, um die Logto-Authentifizierungsdienste zu registrieren:

Program.cs
using Logto.AspNetCore.Authentication;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddLogtoAuthentication(options =>
{
  options.Endpoint = builder.Configuration["Logto:Endpoint"]!;
  options.AppId = builder.Configuration["Logto:AppId"]!;
  options.AppSecret = builder.Configuration["Logto:AppSecret"];
});

Die Methode AddLogtoAuthentication wird Folgendes tun:

  • Das Standard-Authentifizierungsschema auf LogtoDefaults.CookieScheme setzen.
  • Das Standard-Challenge-Schema auf LogtoDefaults.AuthenticationScheme setzen.
  • Das Standard-Abmeldeschema auf LogtoDefaults.AuthenticationScheme setzen.
  • Cookie- und OpenID Connect-Authentifizierungs-Handler zum Authentifizierungsschema hinzufügen.

Anmelde- und Abmeldeflüsse​

Bevor wir fortfahren, gibt es zwei verwirrende Begriffe im .NET Core Authentifizierungs-Middleware, die wir klären müssen:

  1. CallbackPath: Die URI, zu der Logto den Benutzer zurückleitet, nachdem der Benutzer sich angemeldet hat (die "Redirect-URI" in Logto)
  2. RedirectUri: Die URI, zu der weitergeleitet wird, nachdem die notwendigen Aktionen im Logto Authentifizierungs-Middleware durchgeführt wurden.

Der Anmeldeprozess kann wie folgt veranschaulicht werden:


Ähnlich hat .NET Core auch SignedOutCallbackPath und RedirectUri für den Abmeldefluss.

Zur Klarheit werden wir sie wie folgt bezeichnen:

Begriff, den wir verwenden.NET Core Begriff
Logto Redirect-URICallbackPath
Logto Post-Abmeldung Redirect-URISignedOutCallbackPath
Anwendungs-Redirect-URIRedirectUri

Bezüglich der umleitungsbasierten Anmeldung​

  1. Dieser Authentifizierungsprozess folgt dem OpenID Connect (OIDC) Protokoll, und Logto erzwingt strenge Sicherheitsmaßnahmen, um die Benutzeranmeldung zu schützen.
  2. Wenn du mehrere Apps hast, kannst du denselben Identitätsanbieter (Logto) verwenden. Sobald sich der Benutzer bei einer App anmeldet, wird Logto den Anmeldeprozess automatisch abschließen, wenn der Benutzer auf eine andere App zugreift.

Um mehr über die Gründe und Vorteile der umleitungsbasierten Anmeldung zu erfahren, siehe Logto-Anmeldeerfahrung erklärt.

Umleitungs-URIs konfigurieren​

hinweis:

In den folgenden Code-Snippets gehen wir davon aus, dass deine App unter http://localhost:3000/ läuft.

Zuerst konfigurieren wir die Logto-Umleitungs-URI. Füge die folgende URI zur Liste der "Umleitungs-URIs" auf der Logto-Anwendungsdetailseite hinzu:

http://localhost:3000/Callback

Um die Logto-Post-Sign-Out-Umleitungs-URI zu konfigurieren, füge die folgende URI zur Liste der "Post-Sign-Out-Umleitungs-URIs" auf der Logto-Anwendungsdetailseite hinzu:

http://localhost:3000/SignedOutCallback

Ändere die Standardpfade​

Die Logto-Umleitungs-URI hat einen Standardpfad von /Callback, und die Logto-Post-Sign-Out-Umleitungs-URI hat einen Standardpfad von /SignedOutCallback.

Du kannst sie so belassen, wenn es keine besonderen Anforderungen gibt. Wenn du sie ändern möchtest, kannst du die Eigenschaften CallbackPath und SignedOutCallbackPath für LogtoOptions festlegen:

Program.cs
builder.Services.AddLogtoAuthentication(options =>
{
  // Andere Konfigurationen...
  options.CallbackPath = "/Foo";
  options.SignedOutCallbackPath = "/Bar";
});

Denke daran, den Wert auf der Logto-Anwendungsdetailseite entsprechend zu aktualisieren.

Anmelde-/Abmelde-Buttons implementieren​

Zuerst füge Aktionsmethoden zu deinem Controller hinzu, zum Beispiel:

Controllers/HomeController.cs
public class HomeController : Controller
{
  public IActionResult SignIn()
  {
    // Dies wird den Benutzer zur Logto-Anmeldeseite umleiten.
    return Challenge(new AuthenticationProperties { RedirectUri = "/" });
  }

  // Verwende das `new` Schlüsselwort, um Konflikte mit der `ControllerBase.SignOut` Methode zu vermeiden
  new public IActionResult SignOut()
  {
    // Dies wird das Authentifizierungs-Cookie löschen und den Benutzer zur Logto-Abmeldeseite umleiten,
    // um auch die Logto-Sitzung zu löschen.
    return SignOut(new AuthenticationProperties { RedirectUri = "/" });
  }
}

Füge dann die Links zu deiner View hinzu:

Views/Home/Index.cshtml
<p>Ist authentifiziert: @User.Identity?.IsAuthenticated</p>
@if (User.Identity?.IsAuthenticated == true) {
  <a asp-controller="Home" asp-action="SignOut">Abmelden</a>
} else {
  <a asp-controller="Home" asp-action="SignIn">Anmelden</a>
}

Es wird den "Anmelden"-Link anzeigen, wenn der Benutzer nicht authentifiziert ist, und den "Abmelden"-Link anzeigen, wenn der Benutzer authentifiziert ist.

Checkpoint: Teste deine Anwendung​

Jetzt kannst du deine Anwendung testen:

  1. Starte deine Anwendung, du wirst den Anmeldebutton sehen.
  2. Klicke auf den Anmeldebutton, das SDK wird den Anmeldeprozess initiieren und dich zur Logto-Anmeldeseite weiterleiten.
  3. Nachdem du dich angemeldet hast, wirst du zurück zu deiner Anwendung geleitet und siehst den Abmeldebutton.
  4. 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 .NET Core (MVC) 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:

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

Connector-Tab

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​

NameTypErforderlichStandardwert
signInEndpointstringtrue
x509certificatestringtrue
idpMetadataXmlstringtrue
entityIDstringtrue
assertionConsumerServiceUrlstringtrue
messageSigningOrderencrypt-then-sign | sign-then-encryptfalsesign-then-encrypt
requestSignatureAlgorithmhttp://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-sha512falsehttp://www.w3.org/2001/04/xmldsig-more#rsa-sha256
signAuthnRequestbooleanfalsefalse
encryptAssertionbooleanfalsefalse
privateKeystringfalse
privateKeyPassstringfalse
nameIDFormaturn: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:transientfalseurn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
timeoutnumberfalse5000
profileMapProfileMapfalse
ProfileMap-FelderTypErforderlichStandardwert
idstringfalseid
namestringfalsename
avatarstringfalseavatar
emailstringfalseemail
phonestringfalsephone

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.

SAML Connector in der Anmeldeerfahrung aktivieren​

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

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

Anmeldeerfahrungs-Tab

Testen und Validieren​

Kehre zu deiner .NET Core (MVC)-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.