Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Von Bedeutung
Ab dem 1. Mai 2025 steht Azure AD B2C nicht mehr für neue Kunden zur Verfügung. Weitere Informationen finden Sie in unseren HÄUFIG gestellten Fragen.
In "Einrichten eines Registrierungs- und Anmeldeablaufs mithilfe des benutzerdefinierten Azure Active Directory B2C-Richtlinienartikels" richten wir den Anmeldeablauf für ein lokales Konto mithilfe von Azure Active Directory B2C (Azure AD B2C) ein.
In diesem Artikel fügen wir einen Anmeldeablauf für ein externes Konto hinzu, z. B. ein soziales Konto wie Facebook. In diesem Fall ermöglicht Azure AD B2C einem Benutzer, sich mit Anmeldeinformationen von einem externen Anbieter für soziale Netzwerke (IdP) bei Ihrer Anwendung anzumelden.
Bei lokalen Konten wird ein Benutzerkonto mithilfe des objectIdBenutzerattributes eindeutig identifiziert. Für den externen Identitätsanbieter verwenden Sie das alternativeSecurityId-Benutzerattribut, obwohl noch objectId vorhanden ist.
Voraussetzungen
Wenn Sie noch keins haben, erstellen Sie einen Azure AD B2C-Mandanten , der mit Ihrem Azure-Abonnement verknüpft ist.
Sie müssen Visual Studio Code (VS Code) auf Ihrem Computer installiert haben.
Führen Sie die Schritte im Einrichten eines Registrierungs- und Anmeldeflusses für lokale Konten mithilfe der benutzerdefinierten Azure Active Directory B2C-Richtlinie aus. Dieser Artikel ist Teil von Create and run your own custom policies how-to guide series.
Hinweis
Dieser Artikel ist Teil der Anleitungsreihe "Erstellen und Ausführen eigener benutzerdefinierter Richtlinien" in Azure Active Directory B2C. Es wird empfohlen, diese Reihe aus dem ersten Artikel zu starten.
Schritt 1 – Erstellen einer Facebook-Anwendung
Führen Sie die unter "Erstellen einer Facebook-Anwendung " beschriebenen Schritte aus, um die Facebook-App-ID und das App-Geheimnis abzurufen. Überspringen Sie die Voraussetzungen und die restlichen Schritte im Artikel Einrichten der Anmeldung und Anmeldung mit einem Facebook-Konto.
Schritt 2 : Erstellen eines Facebook-Richtlinienschlüssels
Führen Sie die unter Erstellen des Facebook-Schlüssels beschriebenen Schritte aus, um einen Richtlinienschlüssel in Ihrem Azure AD B2C-Mandanten zu speichern. Überspringen Sie die Voraussetzungen und die restlichen Schritte im Artikel Einrichten der Anmeldung und Anmeldung mit einem Facebook-Konto.
Schritt 3 : Konfigurieren der Anmeldung mit Facebook
Um die Anmeldung mit Facebook zu konfigurieren, müssen Sie die folgenden Schritte ausführen:
- Deklarieren weiterer Ansprüche
- Definieren Sie weitere Anspruchstransformationen, um Anspruchsbearbeitungen wie das Erstellen von
AlternativeSecurityIdzu erleichtern. - Konfigurieren von Facebook-Anspruchsanbietern
- Konfigurieren Sie technische Profile von Microsoft Entra, um das soziale Konto aus der Microsoft Entra-Datenbank zu lesen und in diese zu schreiben.
- Konfigurieren Sie ein selbstbestätigtes technisches Profil (zum Akzeptieren zusätzlicher Benutzereingaben oder Aktualisieren von Benutzerdetails) und dessen Inhaltsdefinition.
Schritt 3.1 – Deklarieren weiterer Ansprüche
Suchen Sie in der ContosoCustomPolicy.XML Datei den ClaimsSchema Abschnitt, und deklarieren Sie dann weitere Ansprüche mithilfe des folgenden Codes:
<!--<ClaimsSchema>-->
...
<ClaimType Id="issuerUserId">
<DisplayName>Username</DisplayName>
<DataType>string</DataType>
<UserHelpText/>
<UserInputType>TextBox</UserInputType>
<Restriction>
<Pattern RegularExpression="^[a-zA-Z0-9]+[a-zA-Z0-9_-]*$" HelpText="The username you provided is not valid. It must begin with an alphabet or number and can contain alphabets, numbers and the following symbols: _ -" />
</Restriction>
</ClaimType>
<ClaimType Id="identityProvider">
<DisplayName>Identity Provider</DisplayName>
<DataType>string</DataType>
<UserHelpText/>
</ClaimType>
<ClaimType Id="authenticationSource">
<DisplayName>AuthenticationSource</DisplayName>
<DataType>string</DataType>
<UserHelpText>Specifies whether the user was authenticated at Social IDP or local account.</UserHelpText>
</ClaimType>
<ClaimType Id="upnUserName">
<DisplayName>UPN User Name</DisplayName>
<DataType>string</DataType>
<UserHelpText>The user name for creating user principal name.</UserHelpText>
</ClaimType>
<ClaimType Id="alternativeSecurityId">
<DisplayName>AlternativeSecurityId</DisplayName>
<DataType>string</DataType>
<UserHelpText/>
</ClaimType>
<ClaimType Id="mailNickName">
<DisplayName>MailNickName</DisplayName>
<DataType>string</DataType>
<UserHelpText>Your mail nick name as stored in the Azure Active Directory.</UserHelpText>
</ClaimType>
<ClaimType Id="newUser">
<DisplayName>User is new or not</DisplayName>
<DataType>boolean</DataType>
<UserHelpText/>
</ClaimType>
<!--</ClaimsSchema>-->
Schritt 3.2 – Definieren von Anspruchstransformationen
Suchen Sie in der ContosoCustomPolicy.XML-Datei das Element ClaimsTransformations, und fügen Sie mithilfe des folgenden Codes Anspruchstransformationen hinzu:
<!--<ClaimsTransformations>-->
...
<ClaimsTransformation Id="CreateRandomUPNUserName" TransformationMethod="CreateRandomString">
<InputParameters>
<InputParameter Id="randomGeneratorType" DataType="string" Value="GUID" />
</InputParameters>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="upnUserName" TransformationClaimType="outputClaim" />
</OutputClaims>
</ClaimsTransformation>
<ClaimsTransformation Id="CreateAlternativeSecurityId" TransformationMethod="CreateAlternativeSecurityId">
<InputClaims>
<InputClaim ClaimTypeReferenceId="issuerUserId" TransformationClaimType="key" />
<InputClaim ClaimTypeReferenceId="identityProvider" TransformationClaimType="identityProvider" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="alternativeSecurityId" TransformationClaimType="alternativeSecurityId" />
</OutputClaims>
</ClaimsTransformation>
<ClaimsTransformation Id="CreateUserPrincipalName" TransformationMethod="FormatStringClaim">
<InputClaims>
<InputClaim ClaimTypeReferenceId="upnUserName" TransformationClaimType="inputClaim" />
</InputClaims>
<InputParameters>
<InputParameter Id="stringFormat" DataType="string" Value="cpim_{0}@{RelyingPartyTenantId}" />
</InputParameters>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="userPrincipalName" TransformationClaimType="outputClaim" />
</OutputClaims>
</ClaimsTransformation>
<!--</ClaimsTransformations>-->
Wir haben drei Anspruchstransformationen definiert, mit denen wir Werte für alternativeSecurityId und userPrincipalName Ansprüche generieren. Diese ClaimsTransformations werden im technischen OAuth2-Profil in Schritt 3.3 aufgerufen.
Schritt 3.3 – Konfigurieren des Facebook-Anspruchsanbieters
Damit sich Benutzer mit einem Facebook-Konto anmelden können, müssen Sie das Konto als Anspruchsanbieter definieren, mit dem Azure AD B2C über einen Endpunkt kommunizieren kann. Sie können ein Facebook-Konto als Anspruchsanbieter definieren.
Suchen Sie im ContosoCustomPolicy.XML-Datei das ClaimsProviders-Element, um einen neuen Leistungsanbieter mithilfe des folgenden Codes hinzuzufügen.
<!--<ClaimsProviders>-->
...
<ClaimsProvider>
<!-- The following Domain element allows this profile to be used if the request comes with domain_hint
query string parameter, e.g. domain_hint=facebook.com -->
<Domain>facebook.com</Domain>
<DisplayName>Facebook</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="Facebook-OAUTH">
<!-- The text in the following DisplayName element is shown to the user on the claims provider
selection screen. -->
<DisplayName>Facebook</DisplayName>
<Protocol Name="OAuth2" />
<Metadata>
<Item Key="ProviderName">facebook</Item>
<Item Key="authorization_endpoint">https://www.facebook.com/dialog/oauth</Item>
<Item Key="AccessTokenEndpoint">https://graph.facebook.com/oauth/access_token</Item>
<Item Key="HttpBinding">GET</Item>
<Item Key="UsePolicyInRedirectUri">0</Item>
<Item Key="client_id">facebook-app-id</Item>
<Item Key="scope">email public_profile</Item>
<Item Key="ClaimsEndpoint">https://graph.facebook.com/me?fields=id,first_name,last_name,name,email</Item>
<Item Key="AccessTokenResponseFormat">json</Item>
</Metadata>
<CryptographicKeys>
<Key Id="client_secret" StorageReferenceId="facebook-policy-key" />
</CryptographicKeys>
<InputClaims />
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="id" />
<OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="first_name" />
<OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="last_name" />
<OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
<OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="facebook.com" AlwaysUseDefaultValue="true" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
</OutputClaims>
<OutputClaimsTransformations>
<OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
<OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
<OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
</OutputClaimsTransformations>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
<!--</ClaimsProviders>-->
Ersetzen:
-
facebook-app-iddurch den Wert des Facebook-ElementsappID, das Sie in Schritt 1 abgerufen haben. -
facebook-policy-keymit dem Namen des Facebook-Richtlinienschlüssels, den Sie in Schritt 2 abgerufen haben.
Beachten Sie die Forderungstransformationen, die wir in Schritt 3.2 in der OutputClaimsTransformations Auflistung definiert haben.
Schritt 3.4 – Erstellen von technischen Microsoft Entra-Profilen
Genau wie bei der Anmeldung mit einem lokalen Konto müssen Sie die technischen Profile von Microsoft Entra konfigurieren, die Sie zum Herstellen einer Verbindung mit microsoft Entra ID-Speicher verwenden, um ein Konto für soziale Netzwerke zu speichern oder zu lesen.
Suchen Sie in der
ContosoCustomPolicy.XMLDatei dasAAD-UserReadtechnische Profil, und fügen Sie dann ein neues technisches Profil darunter hinzu, indem Sie den folgenden Code verwenden:<TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId"> <DisplayName>Azure Active Directory technical profile for handling social accounts</DisplayName> <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" /> <Metadata> <Item Key="Operation">Write</Item> <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item> </Metadata> <CryptographicKeys> <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" /> </CryptographicKeys> <InputClaims> <InputClaim ClaimTypeReferenceId="alternativeSecurityId" PartnerClaimType="alternativeSecurityId" Required="true" /> </InputClaims> <PersistedClaims> <!-- Required claims --> <PersistedClaim ClaimTypeReferenceId="alternativeSecurityId" /> <PersistedClaim ClaimTypeReferenceId="userPrincipalName" /> <PersistedClaim ClaimTypeReferenceId="mailNickName" DefaultValue="unknown" /> <PersistedClaim ClaimTypeReferenceId="displayName" DefaultValue="unknown" /> <!-- Optional claims --> <PersistedClaim ClaimTypeReferenceId="givenName" /> <PersistedClaim ClaimTypeReferenceId="surname" /> </PersistedClaims> <OutputClaims> <OutputClaim ClaimTypeReferenceId="objectId" /> <OutputClaim ClaimTypeReferenceId="newUser" PartnerClaimType="newClaimsPrincipalCreated" /> </OutputClaims> </TechnicalProfile>Wir haben ein neues technisches Microsoft Entra-Profil
AAD-UserWriteUsingAlternativeSecurityIdhinzugefügt, das ein neues soziales Konto in die Microsoft Entra ID schreibt.Ersetzen Sie B2C_1A_TokenSigningKeyContainer durch den Tokensignaturschlüssel, den Sie unter "Signieren" erstellt haben.
Fügen Sie in der
ContosoCustomPolicy.XMLDatei ein weiteres technisches Profil von Microsoft Entra nach demAAD-UserWriteUsingAlternativeSecurityIdtechnischen Profil hinzu, indem Sie den folgenden Code verwenden:<TechnicalProfile Id="AAD-UserReadUsingAlternativeSecurityId"> <DisplayName>Azure Active Directory</DisplayName> <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" /> <Metadata> <Item Key="Operation">Read</Item> <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item> </Metadata> <CryptographicKeys> <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" /> </CryptographicKeys> <InputClaims> <InputClaim ClaimTypeReferenceId="alternativeSecurityId" PartnerClaimType="alternativeSecurityId" Required="true" /> </InputClaims> <OutputClaims> <!-- Required claims --> <OutputClaim ClaimTypeReferenceId="objectId" /> <!-- Optional claims --> <OutputClaim ClaimTypeReferenceId="userPrincipalName" /> <OutputClaim ClaimTypeReferenceId="displayName" /> <OutputClaim ClaimTypeReferenceId="givenName" /> <OutputClaim ClaimTypeReferenceId="surname" /> </OutputClaims> </TechnicalProfile>Wir haben ein neues technisches Microsoft Entra-Profil
AAD-UserReadUsingAlternativeSecurityIdhinzugefügt, das ein neues konto für soziale Netzwerke aus der Microsoft Entra-ID liest. Es wirdalternativeSecurityIdals eindeutiger Bezeichner für das Konto für soziale Netzwerke verwendet.Ersetzen Sie B2C_1A_TokenSigningKeyContainer durch den Tokensignaturschlüssel, den Sie unter "Signieren" erstellt haben.
Schritt 3.5 – Konfigurieren der Inhaltsdefinition
Nachdem sich ein Benutzer angemeldet hat, können Sie einige Informationen von ihm sammeln, indem Sie ein selbst bestätigtes technisches Profil verwenden. Daher müssen Sie die Inhaltsdefinition für das selbstbehauptete technische Profil konfigurieren.
Suchen Sie in der ContosoCustomPolicy.XML Datei das ContentDefinitions Element, und fügen Sie dann eine neue Inhaltsdefinition in der ContentDefinitions Auflistung hinzu, indem Sie den folgenden Code verwenden:
<ContentDefinition Id="socialAccountsignupContentDefinition">
<LoadUri>~/tenant/templates/AzureBlue/selfAsserted.cshtml</LoadUri>
<RecoveryUri>~/common/default_page_error.html</RecoveryUri>
<DataUri>urn:com:microsoft:aad:b2c:elements:contract:selfasserted:2.1.7</DataUri>
<Metadata>
<Item Key="DisplayName">Collect information from user page alongside those from social Idp.</Item>
</Metadata>
</ContentDefinition>
Wir verwenden diese Inhaltsdefinition als Metadaten in einem selbst bestätigten technischen Profil im nächsten Schritt (Schritt 3.6).
Schritt 3.6 – Konfigurieren eines selbst bestätigten technischen Profils
Das selbst bestätigte technische Profil, das Sie in diesem Schritt konfigurieren, wird verwendet, um weitere Informationen vom Benutzer zu sammeln oder ähnliche Informationen zu aktualisieren, die aus dem sozialen Konto abgerufen wurden.
Suchen Sie in der ContosoCustomPolicy.XML Datei den ClaimsProviders Abschnitt, und fügen Sie dann einen neuen Anspruchsanbieter hinzu, indem Sie den folgenden Code verwenden:
<!--<ClaimsProviders>-->
...
<ClaimsProvider>
<DisplayName>Self Asserted for social sign in</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="SelfAsserted-Social">
<DisplayName>Collect more info during social signup</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="ContentDefinitionReferenceId">socialAccountsignupContentDefinition</Item>
</Metadata>
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
</CryptographicKeys>
<InputClaims>
<!-- These claims ensure that any values retrieved in the previous steps (e.g. from an external IDP) are prefilled.
Note that some of these claims may not have any value, for example, if the external IDP did not provide any of
these values, or if the claim did not appear in the OutputClaims section of the IDP.
In addition, if a claim is not in the InputClaims section, but it is in the OutputClaims section, then its
value will not be prefilled, but the user will still be prompted for it (with an empty value). -->
<InputClaim ClaimTypeReferenceId="displayName" />
<InputClaim ClaimTypeReferenceId="givenName" />
<InputClaim ClaimTypeReferenceId="surname" />
</InputClaims>
<!---User will be asked to input or update these values-->
<DisplayClaims>
<DisplayClaim ClaimTypeReferenceId="displayName"/>
<DisplayClaim ClaimTypeReferenceId="givenName"/>
<DisplayClaim ClaimTypeReferenceId="surname"/>
</DisplayClaims>
<OutputClaims>
<!-- These claims are not shown to the user because their value is obtained through the "ValidationTechnicalProfiles"
referenced below, or a default value is assigned to the claim. A claim is only shown to the user to provide a
value if its value cannot be obtained through any other means. -->
<OutputClaim ClaimTypeReferenceId="objectId" />
<OutputClaim ClaimTypeReferenceId="newUser" />
<!---<OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />-->
<!-- Optional claims. These claims are collected from the user and can be modified. If a claim is to be persisted in the directory after having been
collected from the user, it needs to be added as a PersistedClaim in the ValidationTechnicalProfile referenced below, i.e.
in AAD-UserWriteUsingAlternativeSecurityId. -->
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surname" />
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
</ValidationTechnicalProfiles>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
<!--</ClaimsProviders>-->
Der hinzugefügte Anspruchsanbieter enthält das selbstbestätigte technische Profil SelfAsserted-Social. Das selbst deklarierte technische Profil verwendet das AAD-UserWriteUsingAlternativeSecurityId technische Profil als Validierungstechnisches Profil. Das technische Profil wird also ausgeführt, AAD-UserWriteUsingAlternativeSecurityId wenn der Benutzer die Schaltfläche " Weiter " auswählt (siehe Screenshot in Schritt 7).
Beachten Sie außerdem, dass wir die Inhaltsdefinition hinzugefügt haben, socialAccountsignupContentDefinitiondie wir in Schritt 3.5 im Metadatenabschnitt konfiguriert haben.
Schritt 4 – Aktualisieren der Schritte zur Benutzerreise-Orchestrierung
Suchen Sie in der ContosoCustomPolicy.XML Datei den HelloWorldJourney Benutzerablauf, und ersetzen Sie alle Orchestrierungsschritte durch die Schritte, die im folgenden Code gezeigt werden:
<!--<OrchestrationSteps>-->
...
<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp">
<ClaimsProviderSelections>
<ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" />
</ClaimsProviderSelections>
</OrchestrationStep>
<OrchestrationStep Order="2" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="FacebookExchange"
TechnicalProfileReferenceId="Facebook-OAUTH" />
</ClaimsExchanges>
</OrchestrationStep>
<!-- For social IDP authentication, attempt to find the user account in the
directory. -->
<OrchestrationStep Order="3" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId" />
</ClaimsExchanges>
</OrchestrationStep>
<!-- Show self-asserted page only if the directory does not have the user account
already (i.e. we don't have an objectId). -->
<OrchestrationStep Order="4" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>objectId</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="5" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>objectId</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="6" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
<!--</OrchestrationSteps>-->
In der Orchestrierung haben Sie auf technische Profile verwiesen, die es Benutzenden ermöglichen, sich mit einem Social Media-Konto anzumelden.
Wenn die benutzerdefinierte Richtlinie ausgeführt wird:
Orchestrierungsschritt 1 – Dieser Schritt enthält ein
ClaimsProviderSelectionsElement, das die verfügbaren Anmeldeoptionen auflistet, aus denen ein Benutzer auswählen kann. In diesem Fall haben wir nur eine Option,FacebookExchangesodass Benutzer, wenn die Richtlinie ausgeführt wird, direkt zu Facebook.com in Schritt 2 weitergeleitet werden, wie dasTargetClaimsExchangeIdAttribut zeigt.Orchestrierung Schritt 2 – Das
Facebook-OAUTHtechnische Profil wird ausgeführt, sodass der Benutzer zu Facebook umgeleitet wird, um sich anzumelden.Orchestrierungsschritt 3: In Schritt 3 wird das technische Profil
AAD-UserReadUsingAlternativeSecurityIdausgeführt, um zu versuchen, das Social Media-Konto der benutzenden Person aus dem Microsoft Entra ID-Speicher zu lesen. Wenn das soziale Konto gefunden wird, wirdobjectIdals Ausgabeanspruch zurückgegeben.Orchestrierungsschritt 4 – Dieser Schritt wird ausgeführt, wenn der Benutzer noch nicht vorhanden ist (
objectIdnicht vorhanden). Es zeigt das Formular, das weitere Informationen vom Benutzer sammelt oder ähnliche Informationen aktualisiert, die aus dem Konto für soziale Netzwerke abgerufen wurden.Orchestrierungsschritt 5 – Dieser Schritt wird ausgeführt, wenn der Benutzer noch nicht vorhanden ist (
objectIdnicht vorhanden), sodass dasAAD-UserWriteUsingAlternativeSecurityIdtechnische Profil ausgeführt wird, um das soziale Konto in die Microsoft Entra-ID zu schreiben.Orchestrierungsschritt 6 – Schließlich fasst Schritt 6 zusammen und gibt das JWT am Ende der Ausführung der Richtlinie zurück.
Schritt 5: Aktualisieren von Ausgabeansprüchen der vertrauenden Seite
Suchen Sie in der ContosoCustomPolicy.XML Datei das RelyingParty Element, und ersetzen Sie dann alle Ausgabeansprüchesammlung durch den folgenden Code:
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surname" />
<OutputClaim ClaimTypeReferenceId="email" />
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
<OutputClaim ClaimTypeReferenceId="identityProvider" />
Wir haben den Identitätsanbieter (IdentityProvider) als Ausgabeanspruch hinzugefügt, sodass er in der JWT enthalten ist, die an die Anwendung der vertrauenden Seite zurückgegeben wird.
Schritt 6 : Uploadrichtlinie
Befolgen Sie die Schritte in Benutzerdefinierte Richtliniendatei hochladen, um Ihre Richtliniendatei hochzuladen. Wenn Sie eine Datei mit demselben Namen wie die datei hochladen, die sich bereits im Portal befindet, stellen Sie sicher, dass Sie die benutzerdefinierte Richtlinie überschreiben, falls sie bereits vorhanden ist.
Schritt 7 – Testrichtlinie
Führen Sie die Schritte unter "Testen der benutzerdefinierten Richtlinie " aus, um Ihre benutzerdefinierte Richtlinie zu testen.
Sie werden zu einer Facebook-Anmeldeseite weitergeleitet. Geben Sie Ihre Facebook-Anmeldeinformationen ein, und wählen Sie dann "Anmelden" aus. Sie werden direkt zu Facebook umgeleitet, da wir es in unseren Orchestrierungsschritten festlegen, da wir nicht über mehrere Anmeldeoptionen verfügen, aus denen Sie auswählen können. In einer App fügen Sie in der Regel eine Schaltfläche wie "Mit Facebook anmelden" hinzu, die bei Auswahl die Richtlinie ausführt.
Wenn diese Richtlinie zum ersten Mal ausgeführt wird (das Konto für soziale Netzwerke ist im Microsoft Entra-Speicher noch nicht vorhanden), wird ein Screenshot wie die unten gezeigte angezeigt. Dieser Bildschirm wird in nachfolgenden Richtlinienausführungen nicht angezeigt, da das konto für soziale Netzwerke bereits im Microsoft Entra-Speicher vorhanden ist.
Geben Sie den Anzeigenamen, den Vornamen und den Nachnamen ein, oder aktualisieren Sie ihn, und wählen Sie dann die Schaltfläche " Weiter" aus.
Nachdem die Ausführung der Richtlinie abgeschlossen ist, werden Sie zu https://jwt.ms weitergeleitet, und es wird ein decodiertes JWT angezeigt. Es sieht ähnlich wie der folgende JWT-Codeausschnitt aus:
{
"typ": "JWT",
"alg": "RS256",
"kid": "pxLOMWFgP4T..."
}.{
...
"acr": "b2c_1a_contosocustompolicy",
...
"given_name": "Maurice",
"family_name": "Paulet",
"name": "Maurice Paulet",
"email": "maurice.p@contoso.com",
"idp": "facebook.com"
}.[Signature]
Beachten Sie, "idp": "facebook.com"dass der Identitätsanbieter im JWT enthalten ist.
Eine kombinierte lokale und soziale Anmeldung
In diesem Artikel verweisen unsere Schritte zur Benutzerreise-Orchestrierung nur auf technische Profile, die es einem Benutzer ermöglichen, sich mit einem sozialen Konto anzumelden. Wir können die Orchestrierungsschritte ändern, damit sich ein Benutzer entweder über ein lokales Konto oder ein soziales Konto anmelden kann. Dazu listet das Element des ersten Orchestrierungsschritts ClaimsProviderSelections die Anmeldeoptionen auf, die dem Benutzer zur Verfügung stehen.
Führen Sie die folgenden Schritte aus, um ein kombiniertes lokales und soziales Konto hinzuzufügen:
Suchen Sie in der
ContosoCustomPolicy.XML-Datei nach dem selbstbestätigten technischen ProfilAccountTypeInputCollector, und fügen Sie dann denauthenticationSource-Anspruch der Ausgabeanspruchsauflistung hinzu, indem Sie den folgenden Code verwenden:<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localIdpAuthentication" AlwaysUseDefaultValue="true" />Stellen Sie sicher, dass Sie den
authenticationSourceAnspruch auch in der Ausgabeanspruchssammlung desUserSignInCollectorselbst bestätigten technischen Profils hinzufügen.Fügen Sie im
UserJourneysAbschnitt mithilfe des folgenden Codes eine neue BenutzerreiseLocalAndSocialSignInAndSignUphinzu:<!--<UserJourneys>--> ... <UserJourney Id="LocalAndSocialSignInAndSignUp"> <OrchestrationSteps> <!--Orchestration steps will be added here--> </OrchestrationSteps> </UserJourney> <!--</UserJourneys>-->Fügen Sie Orchestrierungsschritte in den von Ihnen erstellten Benutzerpfad hinzu, indem Sie den folgenden Code verwenden:
LocalAndSocialSignInAndSignUp<!--<UserJourneys> ... <UserJourney Id="LocalAndSocialSignInAndSignUp"> <OrchestrationSteps>--> <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="SignupOrSigninContentDefinition"> <ClaimsProviderSelections> <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" /> <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" /> </ClaimsProviderSelections> <ClaimsExchanges> <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="UserSignInCollector" /> </ClaimsExchanges> </OrchestrationStep> <!-- Check if the user has selected to sign in using one of the social providers --> <OrchestrationStep Order="2" Type="ClaimsExchange"> <Preconditions> <Precondition Type="ClaimsExist" ExecuteActionsIf="true"> <Value>objectId</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> </Preconditions> <ClaimsExchanges> <ClaimsExchange Id="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" /> <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/> </ClaimsExchanges> </OrchestrationStep> <!--For Local sign in option start--> <OrchestrationStep Order="3" Type="ClaimsExchange"> <Preconditions> <Precondition Type="ClaimsExist" ExecuteActionsIf="true"> <Value>objectId</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> <Value>accountType</Value> <Value>work</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> <Value>authenticationSource</Value> <Value>socialIdpAuthentication</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> </Preconditions> <ClaimsExchanges> <ClaimsExchange Id="GetAccessCodeClaimsExchange" TechnicalProfileReferenceId="AccessCodeInputCollector" /> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="4" Type="ClaimsExchange"> <Preconditions> <Precondition Type="ClaimsExist" ExecuteActionsIf="true"> <Value>objectId</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> <Value>authenticationSource</Value> <Value>socialIdpAuthentication</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> </Preconditions> <ClaimsExchanges> <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="UserInformationCollector" /> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="5" Type="ClaimsExchange"> <Preconditions> <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> <Value>authenticationSource</Value> <Value>socialIdpAuthentication</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> </Preconditions> <ClaimsExchanges> <ClaimsExchange Id="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/> </ClaimsExchanges> </OrchestrationStep> <!--For Local sign in option end--> <!--For social sign in option start--> <!-- For social IDP authentication, attempt to find the user account in the directory. --> <OrchestrationStep Order="6" Type="ClaimsExchange"> <Preconditions> <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> <Value>authenticationSource</Value> <Value>localIdpAuthentication</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> </Preconditions> <ClaimsExchanges> <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId" /> </ClaimsExchanges> </OrchestrationStep> <!-- Show self-asserted page only if the directory does not have the user account already (i.e. we do not have an objectId). --> <OrchestrationStep Order="7" Type="ClaimsExchange"> <Preconditions> <Precondition Type="ClaimsExist" ExecuteActionsIf="true"> <Value>objectId</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> <Value>authenticationSource</Value> <Value>localIdpAuthentication</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> </Preconditions> <ClaimsExchanges> <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" /> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="8" Type="ClaimsExchange"> <Preconditions> <Precondition Type="ClaimsExist" ExecuteActionsIf="true"> <Value>objectId</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> <Value>authenticationSource</Value> <Value>localIdpAuthentication</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> </Preconditions> <ClaimsExchanges> <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" /> </ClaimsExchanges> </OrchestrationStep> <!--For social sign in option end--> <OrchestrationStep Order="9" Type="ClaimsExchange"> <ClaimsExchanges> <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="10" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" /> <!-- </OrchestrationSteps> </UserJourney> </UserJourneys>-->Im ersten Schritt geben wir die Optionen an, die ein Benutzer in seiner Reise, lokalen oder sozialen Authentifizierung auswählen muss. In den folgenden Schritten verwenden wir Vorbedingungen, um die vom Benutzer ausgewählte Option oder die Phase der Reise zu verfolgen, in der der Benutzer sich befindet. Beispielsweise verwenden wir den
authenticationSourceAnspruch, um zwischen einer lokalen Authentifizierungsreise und einer Reise für die soziale Authentifizierung zu unterscheiden.Ändern Sie im
RelyingParty-Abschnitt den Wert der DefaultUserJourney‘sReferenceIdinLocalAndSocialSignInAndSignUpVerwenden Sie das Verfahren in Schritt 6 und Schritt 7 , um Ihre Richtlinie hochzuladen und auszuführen. Nachdem Sie die Richtlinie ausgeführt haben, wird ein Bildschirm angezeigt, der dem folgenden Screenshot ähnelt.
Sie können feststellen, dass sich ein Benutzer registrieren oder sich anmelden kann, indem Sie entweder ein lokales Konto oder ein soziales Konto verwenden.
Verwandte Inhalte
- Erfahren Sie mehr darüber, wie Sie ein technisches OAuth2-Profil in einer benutzerdefinierten Azure Active Directory B2C-Richtlinie definieren.