OpenID Connect und SAML-Anmeldung

Neben Microsoft, Google und Facebook kann ein Portal Personen über jeden OpenID Connect oder SAML 2.0-Identitätsanbieter anmelden: Okta, Auth0, Microsoft Entra External ID, den eigenen Entra-Tenant eines Kunden oder Partners, AD FS, Ping, Google Workspace. Jeder konfigurierte Anbieter ist ein Button auf der Anmeldeseite und benötigt keinen Code.

Eine Anmeldung über einen dieser Anbieter wird genau wie eine Microsoft- oder Google-Anmeldung abgeglichen, verknüpft oder als Kontakt registriert. Interne Benutzer (Systemnutzer) melden sich bei Microsoft an – siehe Entra ID Sign-In Setup.

Mach es an

Projekte, die aus den Vorlagen für externe Nutzer erstellt wurden, haben dies bereits in Program.cs. Es liest jeden unter und Authentication:Saml2konfigurierten Authentication:OpenIdConnect Anbieter und fügt keinen hinzu, bis einer konfiguriert ist:

SAML stammt aus dem Paket, auf das PowerPortalsPro.Identity.Saml2 sich diese Projekte beziehen. Ein Projekt, das vor dieser Funktion erstellt wurde, benötigt den Aufruf und das hinzugefügte Paket.

Adressen zur Registrierung beim Anbieter

Jeder Anbieter hat einen Namen – den Schlüssel seines Konfigurationsabschnitts, ContosoOkta wie in den untenstehenden Beispielen – und die Adressen, zu denen der Anbieter die Leute zurückschickt, bestehen aus ihm in Kleinbuchstaben. Registrieren Sie sie genau, einmal für jeden Host, auf dem das Portal läuft.

Die Adressen sind in jeder Sprache gleich. Eine Anmeldung, die auf einer Seite in einer anderen Sprache beginnt – /es/… – geht über die eigene Adresse der Seite zurück und dann auf die Seite, auf der sie in der jeweiligen Sprache begann.

OpenID-Connect-Anbieter

Füge für jeden Anbieter Authentication:OpenIdConnectunter unter einen Abschnitt hinzu. Halte den Client lokal in Benutzergeheimnissen und in Key Vault nach der Bereitstellung geheim.

Das Portal verwendet den Autorisierungscode-Fluss mit PKCE, meldet sich über das externe Cookie von Identity an und speichert keine Token. Es liest die ID der Person aus sub, sowie deren Adresse und Namen aus email, given_name und family_name.

Okta (OpenID Connect)

1. Erstellen Sie eine App-Integration: OIDC - OpenID Connect vom Typ Web Application mit der Genehmigungscode-Gewährung .
2. Fügen Sie die Redirect-URI des Portals als Sign-in-Redirect-URI hinzu, weisen Sie Personen oder Gruppen zu, die sich anmelden dürfen, und kopieren Sie die Client-ID und das Geheimnis.
3. Die Autorität ist der Aussteller Ihres Autorisierungsservers, z. B. https://contoso.okta.com/oauth2/default.

Auth0

1. Erstellen Sie eine Anwendung vom Typ Regular Web Application.
2. Fügen Sie die Redirect-URI des Portals zu Allowed Callback-URLs hinzu und kopieren Sie die Client-ID und das Secret.
3. Die Autorität ist z. https://contoso.us.auth0.com/B. die Domain Ihres Mieters oder Ihre eigene Domain.

Microsoft Entra Externe ID

1. Im externen Tenant registrieren Sie eine Anwendung mit der Redirect-URI des Portals als Web-Redirect-URI und fügen Sie ein Client-Secret hinzu.
2. Erstellen Sie einen Benutzerablauf für Anmeldung und Anmeldung und fügen Sie die Anwendung hinzu.
3. Die Autorität ist https://<tenant subdomain>.ciamlogin.com/<tenant id>/v2.0. Wenn der User Flow jede Adresse vor der Erstellung eines Kontos überprüft – E-Mail mit Passwort und Einmal-Passcode tun es beide – handelt es sich dabei um einen Identitätsanbieter, den Sie für Ihre eigenen Kunden betreiben, und TrustedEmailDomains der auch ...*

Entra-Mieter eines Kunden oder Partners

Für eine Organisation, deren Nutzer sich mit eigenen Arbeitskonten anmelden sollten, ohne den Multi-Tenant-Microsoft-Button:

1. Registrieren Sie in ihrem Tenant eine einzelne Tenant-Anwendung mit der Redirect-URI des Portals als Web-Redirect-URI und fügen Sie ein Client-Secret hinzu.
2. Die Autorität ist https://login.microsoftonline.com/<their tenant id>/v2.0.
3. Listen Sie ihre Domains auf TrustedEmailDomains; eine Adresse wird anderswo zuerst per E-Mail bestätigt. Die ID ihres Tenants erreicht die Sitzung, ebenso wie beim Microsoft-Button. Entras eigene Verifizierungsansprüche (xms_edov, verified_primary_email) stammen nicht von einem Anbieter: Der dahinterstehende Tenant verwaltet die gesendeten Ansprüche.

SAML 2.0-Anbieter

Fügen Sie für jeden Anbieter Authentication:Saml2unter unter einen Abschnitt hinzu. Die Metadaten des Anbieters geben dem Portal seine Anmeldeadresse und die Zertifikate an, mit denen seine Antworten signiert sind; sie werden jeden Tag erneut gelesen, sodass ein Zertifikat, das der Anbieter überträgt, abgerufen wird.

Antworten müssen durch ein Zertifikat in den Metadaten des Anbieters signiert werden, das durch seine Entitäts-ID ausgegeben wird, für die Entitäts-ID des Portals, an den Assertion-Consumer-Service gesendet und als Antwort auf die Anfrage desselben Browsers gesendet werden. Die NameID identifiziert das Konto, daher muss sie persistent sein oder die E-Mail-Adresse; eine vorübergehende wird abgelehnt. Adresse und Name werden aus den Attributen gelesen, die Anbieter häufig verwenden: email, mail, emailaddress und die WS-Federation-Anspruchsnamen, und givenName /oder firstName und surname oder lastName.

Microsoft Entra ID (Unternehmensanwendung)

1. Erstellen Sie eine Unternehmensanwendung, integrieren Sie alle anderen Anwendungen, die Sie nicht in der Galerie finden, und wählen Sie SAML Single Sign-on.
2. Setzen Sie die Identifier (Entitäts-ID) auf die Entitäts-ID des Portals und die Antwort-URL auf den Assertion-Consumer-Service.
3. Kopieren Sie die App Federation Metadata URL in MetadataAddress, und weisen Sie die Benutzer oder Gruppen zu, die sich anmelden können.

Okta (SAML)

1. Erstellen Sie eine App-Integration vom Typ SAML 2.0.
2. Setze die Single Sign-on URL auf den Assertion Consumer Service und Audience URI (SP Entity ID) auf die Entitäts-ID des Portals; wähle ein Persistent- oder EmailAddress-Name ID-Format und füge , firstName sowie lastName Attributanweisungen hinzuemail.
3. Kopiere die Metadaten-URL der Anwendung in MetadataAddress.

AD FS

1. Fügen Sie einen vertrauenden Parteivertrauen hinzu, der die Metadaten des Portals von seiner Adresse importiert.
2. Fügen Sie Anspruchsausgaberegeln hinzu, die die E-Mail-Adresse, den Vor- und Nachnamen sowie eine persistente Namenserkennung senden.
3. MetadataAddress ist https://<your AD FS host>/FederationMetadata/2007-06/FederationMetadata.xml.

Unterschriebene Anfragen und verschlüsselte Behauptungen

Die meisten Anbieter benötigen keines von beidem. Für einen, der signierte Authentifizierungsanfragen erfordert oder seine Behauptungen verschlüsselt, fügen Sie den Anbieter im Code mit den Zertifikaten hinzu; beide werden in den Metadaten des Portals veröffentlicht, damit der Anbieter sie importieren kann.

Welche Adressen sind vertrauenswürdig

Ein Anmeldeformular, dessen Adresse das Portal vertraut, geht direkt in den Kontakt, der es hat, und ein neues Konto beginnt mit bestätigter Adresse. Jede andere Adresse wird zuerst per E-Mail bestätigt, einmal per E-Mail; danach findet der Link zwischen Anmeldung und Kontakt.

• Ein Anbieter wird nur für die in seinem TrustedEmailDomainsaufgeführten Domains vertraut, genau abgestimmt – contoso.com deckt nicht ab. mail.contoso.comListen Sie die Domains auf, deren Mailboxen die Organisation hinter dem Anbieter kontrolliert.
• Ein Anbieter, der behauptet, eine Adresse nicht verifiziert zu haben (die email_verified von OpenID Connect ist falsees), wird dafür nicht vertraut, egal was die Liste sagt.
• Nichts anderes ist das: Ein Anbieter kann keine Adresse garantieren, indem er die eigenen Ansprüche des Portals sendet, und ein auf andere Weise hinzugefügtes Anmeldeschema bürgt nie dafür.

Wichtig

* Vertraut jeder Adresse, die der Anbieter behauptet. Nutze es nur für einen Identitätsanbieter, den du für deine eigenen Nutzer betreibst und der Adressen überprüft, bevor er sie behauptet. Nutze es niemals für einen Anbieter, den ein Kunde oder Partner verwaltet: Jeder, der ihn verwaltet, kann ein Konto mit jeder Adresse erstellen, einschließlich einer zu einem Kontakt einer anderen Organisation, und würde sich als dieser Kontakt anmelden.

Anmelde-Buttons

Jeder Anbieter ist ein Button auf der Anmeldeseite, der mit seinem Anzeigenamen beschriftet ist. Vier weitere Einstellungen im Bereich eines Anbieters verändern, wie der Button aussieht und wo er sich befindet:

Ein Bild ist ein Pfad vom Wurzel der Seite – eine Datei im Portal wwwroot, wie zum /images/contoso-logo.svg Beispiel – oder eine https Adresse. Ein Pfad wird auf jeder Seite und in jeder Sprache vom Root-Grund der Seite bereitgestellt. Alles andere stoppt das Portal beim Start und benennt die Einstellung.

Jeder andere Anbieter-Button, einschließlich der von Microsoft und Google, wird im Code geändert:

Microsoft, Google und Facebook zeigen ihre eigenen "Mit ..."-Buttons an, in hellen und dunklen Versionen, es sei denn, man legt eine dieser Buttons für sie ein.

Fehlerbehebung

• Der Anbieter lehnt die Weiterleitungs-URI oder Antwort-URL ab. Sie muss exakt übereinstimmen – Schema, Host, Port und Pfad. Registrieren https://{host}/signin-{name}Sie – oder die SAML-Adressen – für jeden Host, auf dem das Portal läuft.
• Das Portal startet nicht, sondern nennt eine Authentication:OpenIdConnect oder Authentication:Saml2 Einstellung. Ein konfigurierter Anbieter fehlt ein erforderlicher Wert oder hat einen fehlerhaften. Der MCP-Server listet check_setup jeden Anbieter auf, was ihm fehlt und welche Adressen registriert werden sollen.
• Eine SAML-Anmeldung scheitert mit "Signatur ist ungültig". Die Antwort wurde von einem Zertifikat signiert, das das Portal nicht gesehen hat – meist, weil der Anbieter sein Zertifikat übertragen hat. Das Portal liest die Metadaten innerhalb eines Tages erneut; starte es jetzt neu, um es zu lesen.
• "Publikumsvalidierung fehlgeschlagen" oder "Ungültiger Aussteller". Die beim Anbieter registrierte Entitäts-ID ist nicht die, die das Portal verwendet – so eingestellt EntityId , dass sie übereinstimmt – oder die Antwort kam von einer anderen Entität als IdentityProviderEntityId den Namen.
• Eine SAML-Anmeldung scheitert, weil die NameID vorübergehend ist. Lass den Anbieter eine persistente NameID oder die E-Mail-Adresse schicken.
• Das Öffnen des Portals über die Dashboard-Kachel eines Anbieters führt zurück zur Anmeldeseite. Das Portal hat nicht nach dieser Anmeldung gefragt. Für diesen Anbieter eingestellt AllowIdentityProviderInitiated .
• Jede erste Anmeldung sendet eine Bestätigungs-E-Mail. Die Adressdomain befindet sich nicht in der Domain des Anbieters TrustedEmailDomains. Das ist der sichere Standard; sobald die Adresse bestätigt ist, gehen spätere Anmeldungen direkt ein.