🤳🏼 🤚🏼 🌜 Die Geschichte, wie ich Azure AD B2C für React and React Native konfiguriert habe Teil 2 (Tutorial) 👨 🏒 🚶

Vorwort

Fortsetzung des Arbeitszyklus mit Azure B2C. In diesem Artikel werde ich über den schwierigsten und nicht offensichtlichsten Punkt sprechen, nämlich das Identity Experience Framework.

Das Hauptziel ist es, ein Bild für diejenigen zusammenzustellen, die sich überhaupt nicht mit dem Thema befassen, und dabei zu helfen, einige grundlegende Funktionen einzurichten.

Links zu verwandten Beiträgen

Teil 1: Erstellen und Konfigurieren von Anwendungen in Azure AD B2C
Teil 2: Arbeiten mit dem Identity Framework Experience
Teil 3: Reaktionsverbindung reagieren
Teil 4: Anschließen der React Native App
Teil 5: Verbinden und Konfigurieren des Backends unter .NET Core 3

Grundeinstellung

Bevor Sie mit der Grundeinstellung beginnen, möchte ich Ihnen erklären, wie das Laden neuer Regeln abläuft:

Wechseln Sie zum Identity Experience Framework
Klicken Sie auf Benutzerrichtlinie senden
Wählen Sie eine Datei aus (vergessen Sie nicht, auf "Benutzerdefinierte Richtlinie überschreiben, falls bereits vorhanden" zu klicken).
Wir senden

Tatsächlich hat sich seit dem letzten Mal nichts geändert, ABER:

Wenn Sie die Datei TrustFrameworkExtension.xml oder TrustFrameworkBase.xml ändern, laden Sie regelmäßig die Datei herunter, die auf sie verweist.
Wenn Sie Änderungen an einer dieser Dateien vornehmen, kommt es manchmal vor, dass Ihre Änderungen nicht angezeigt werden. Dies liegt daran, dass
Sie etwas in der Basisdatei geändert haben, sodass die untergeordnete Datei während der Überprüfung zu einem Fehler führt.

Im letzten Artikel haben wir uns darauf geeinigt, dass wir die folgenden Dateien hinzugefügt haben:

a.TrustFrameworkBase.xml
b.TrustFrameworkExtensions.xml
c.SignUpOrSignin. XML
d.ProfileEdit. XML
e.PasswordReset. XML

Jetzt möchte ich ausführlich über jeden von ihnen erzählen.

TrustFrameworkBase.xml

Diese Datei enthält die Grundeinstellung. Tatsächlich ist es die Grundlage der Grundlagen, aber in den Tutorials heißt es meistens: "Berühren Sie diese Datei besser nicht." Dies ist teilweise richtig, aber es gibt einige Punkte, über die nicht gesprochen wird:

In jedem Lernprogramm, in dem Änderungen an TrustFrameworkExtensions.xml vorgenommen werden sollen, werden die Regeln aus TrustFrameworkBase.xml im Wesentlichen neu geschrieben
Es gibt Situationen, in denen es bequemer ist, etwas in TrustFrameworkBase.xml zu ändern .
Wenn Sie in anderen Dateien einen Link zu einem Objekt finden, das nicht in diesen Dateien enthalten ist, liegt dieser zu 100% in TrustFrameworkBase.xml und Sie können ihn öffnen und anzeigen

Aus meiner Erfahrung werde ich sagen - ich habe nur zwei Dinge in dieser Datei geändert (Lokalisierung und ein Feld gelöscht).

TrustFrameworkExtension.xml

Mit dieser Datei verbringen Sie viel Zeit miteinander. In der Tat ist dies die Hauptdatei für Ihre Einstellungen. Er wird ständig in Tutorials erwähnt.

SignUpOrSignin. XML, ProfileEdit. XML, PasswordReset. XML

Diese Dateien sind Blattseiten. Sie möchten wahrscheinlich Ihre hinzufügen. Sie werden die geringste Veränderung haben.

Lassen Sie uns nun über die Dateistruktur sprechen . Alle Dateien haben eine ähnliche Struktur, daher werde ich sie anhand der Datei TrustFrameworkExtension.xml beschreiben .

Die Datei ist in mehrere Hauptblöcke unterteilt

<TrustFrameworkPolicy>
  <BasePolicy> <!--     -->
      <TenantId>customtenant.onmicrosoft.com</TenantId>
      <PolicyId>B2C_1A_TrustFrameworkBase</PolicyId>
  </BasePolicy>

  <BuildingBlocks> <!--       UI -->
  </BuildingBlocks>

  <ClaimsProviders> <!--        JWT token) -->
  </ClaimsProviders>
  
  <UserJourneys> <!--       -->
  </UserJourneys>
</TrustFrameworkPolicy>

Nun zu jedem Block einzeln.

Bausteine

In diesem Block fügen wir „Werkzeuge“ hinzu, die wir in zukünftigen Arbeiten verwenden können.

ClaimsSchema-

Element ClaimsSchema bestimmt die Arten von Anweisungen, auf die innerhalb der Richtlinie verwiesen werden kann.

  <BuildingBlocks>
    <ClaimsSchema>
      <ClaimType Id="picture"><!--      UI     -->
        <DisplayName>Picture</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="country"><!--     -->
        <DisplayName>Country</DisplayName>
        <DataType>string</DataType>
        <UserInputType>DropdownSingleSelect</UserInputType>
        <Restriction>
          <Enumeration Text="Russia" Value="russia" SelectByDefault="false" />
          <Enumeration Text="Other" Value="other" SelectByDefault="false" />
        </Restriction>
      </ClaimType>
           ...
    </ClaimsSchema>

Prädikate

Prädikate und Prädikatvalidierungselemente ermöglichen die Validierung, um sicherzustellen, dass nur korrekt geformte Daten in den Azure Active Directory B2C-Client (Azure AD B2C) eingegeben werden.

    <Predicates> <!--     ,       -->
      <Predicate Id="LengthRange" Method="IsLengthRange">
        <UserHelpText>The password must be between 6 and 64 characters.</UserHelpText>
        <Parameters>
          <Parameter Id="Minimum">6</Parameter>
          <Parameter Id="Maximum">64</Parameter>
        </Parameters>
      </Predicate>
      <Predicate Id="Lowercase" Method="IncludesCharacters">
        <UserHelpText>a lowercase letter</UserHelpText>
        <Parameters>
          <Parameter Id="CharacterSet">a-z</Parameter>
        </Parameters>
      </Predicate>
          ...
    </Predicates>

PredicateValidations

Während Prädikate bestimmen, ob ein Assertionstyp validiert wird,gruppiert PredicateValidations eine Reihe von Prädikaten, um eine Benutzereingabeprüfung zu bilden, die dem Assertionstyp entspricht.

    <PredicateValidations> <!--       -->
      <PredicateValidation Id="CustomPassword">
        <PredicateGroups>
          <PredicateGroup Id="LengthGroup">
            <PredicateReferences MatchAtLeast="1">
              <PredicateReference Id="LengthRange" />
            </PredicateReferences>
          </PredicateGroup>
          <PredicateGroup Id="CharacterClasses">
            <UserHelpText>The password must have at least 1 of the following:</UserHelpText>
            <PredicateReferences MatchAtLeast="2">
              <PredicateReference Id="Lowercase" /> <!--   ,    -->
              <PredicateReference Id="Uppercase" />
                    ...
            </PredicateReferences>
          </PredicateGroup>
        </PredicateGroups>
      </PredicateValidation>
    </PredicateValidations>

ClaimsTransformations-

Element ClaimsTransformations enthält eine Liste von Assertions-Transformationsfunktionen, die im Rahmen einer benutzerdefinierten Richtlinie für die Benutzerinteraktion verwendet werden können.

    <ClaimsTransformations> <!--      -->
      <ClaimsTransformation Id="GenerateSendGridRequestBody" TransformationMethod="GenerateJson">
        <InputClaims>
          <InputClaim ClaimTypeReferenceId="email" TransformationClaimType="personalizations.0.to.0.email" />
          <InputClaim ClaimTypeReferenceId="otp" TransformationClaimType="personalizations.0.dynamic_template_data.otp" />
          <InputClaim ClaimTypeReferenceId="email" TransformationClaimType="personalizations.0.dynamic_template_data.email" />
        </InputClaims>
        <InputParameters>
          <InputParameter Id="template_id" DataType="string" Value="d-b0000000000000000000000000000000" /> <!-- Template ID SendGrid (    ) -->
          <InputParameter Id="from.email" DataType="string" Value="custom@email.com" />
          <InputParameter Id="personalizations.0.dynamic_template_data.subject" DataType="string" Value="Welcome to Habr!"/>
        </InputParameters>
        <OutputClaims>
          <OutputClaim ClaimTypeReferenceId="sendGridReqBody" TransformationClaimType="outputClaim" />
        </OutputClaims>
      </ClaimsTransformation>
            ...
    </ClaimsTransformations>

ContentDefinitions

Ermöglicht das Definieren von Vorlagen für jede Ihrer Seiten.

    <ContentDefinitions> <!--         -->
      <ContentDefinition Id="api.signuporsignin">
        <LoadUri>https://azure.blob.core.windows.net/yourblobstorage/pagelayoutfile.html</LoadUri>
        <RecoveryUri>~/common/default_page_error.html</RecoveryUri>
        <DataUri>urn:com:microsoft:aad:b2c:elements:contract:unifiedssp:1.2.0</DataUri>
      </ContentDefinition>
          ...
    </ContentDefinitions>

DisplayControls

Das Display-Steuerelement ist ein Benutzeroberflächenelement mit besonderen Funktionen, das mit dem Azure Active Directory B2C-Serverdienst (Azure AD B2C) interagiert.

    <DisplayControls> <!--      -->
      <DisplayControl Id="emailVerificationControl" UserInterfaceControlType="VerificationControl">
        <DisplayClaims> <!--   -->
          <DisplayClaim ClaimTypeReferenceId="email" Required="true" />
          <DisplayClaim ClaimTypeReferenceId="verificationCode" ControlClaimType="VerificationCode" Required="true" />
        </DisplayClaims>
        <OutputClaims> <!--   (     ) -->
          <OutputClaim ClaimTypeReferenceId="email" />
        </OutputClaims>
        <Actions>
          <Action Id="SendCode"> <!--        -->
            <ValidationClaimsExchange>
              <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="GenerateOtp" />
              <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="SendGrid" />
            </ValidationClaimsExchange>
          </Action>
            ...
        </Actions>
      </DisplayControl>
          ...
    </DisplayControls>
  </BuildingBlocks>

ClaimsProviders

In diesem Block erstellen wir die Seiten selbst bzw. deren Inhalt. Hier geben wir an, welche Eingabe- und Ausgabedaten die Seite enthält.

ClaimsProvider verknüpft technische Profile mit dem Schadenanbieter.

  <ClaimsProviders>
    <ClaimsProvider> <!--   -          -->
      <DisplayName>Self Asserted</DisplayName>

Das TechnicalProfiles- Element enthält eine Reihe von technischen Profilen, die vom Anspruchsanbieter unterstützt werden.

      <TechnicalProfiles>
        <TechnicalProfile Id="SelfAsserted-Social">
          <DisplayName>User ID 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">api.selfasserted</Item> <!--  . (        ,   )-->
          </Metadata>
          <CryptographicKeys>
            <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" /> <!--       -->
          </CryptographicKeys>
          <InputClaims> <!--   ..          -->
            <InputClaim ClaimTypeReferenceId="givenName" />
            <InputClaim ClaimTypeReferenceId="surname" />
          </InputClaims>
          <OutputClaims> <!--  .       ,      (   ) -->
              <!-- 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). -->
            <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="givenName" Required="true"/>
            <OutputClaim ClaimTypeReferenceId="surname" Required="true"/>
            <OutputClaim ClaimTypeReferenceId="country" Required="true"/>
          </OutputClaims>
        </TechnicalProfile>
      </ClaimsProvider>

Beispiel für das Hinzufügen von Facebook-Identitätsanbietern

    <ClaimsProvider> <!--    .       -->
      <DisplayName>Facebook</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="Facebook-OAUTH">
          <Metadata>
            <Item Key="client_id">FACEBOOK_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,picture</Item>
          </Metadata>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="picture" PartnerClaimType="picture" />
          </OutputClaims>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>

TrustFrameworkBase.xml

      <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>
  
              <!-- The Facebook required HTTP GET method, but the access token response is in JSON format from 3/27/2017 -->
              <Item Key="AccessTokenResponseFormat">json</Item>
            </Metadata>
            <CryptographicKeys>
              <Key Id="client_secret" StorageReferenceId="B2C_1A_FacebookSecret" />
            </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>
            <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
          </TechnicalProfile>
        </TechnicalProfiles>
      </ClaimsProvider>

Benutzerreisen

Die UserJourneys des Benutzers geben explizite Pfade an, über die die Richtlinie es der anspruchsbasierten Anwendung ermöglicht, dem Benutzer die erforderlichen Ansprüche bereitzustellen.

Unten habe ich ein paar einfache Dinge hinzugefügt, der Rest ist leicht in den Tutorials zu finden, die ich unten hinzufügen werde.

  <UserJourneys>
    <UserJourney Id="SignUp"> <!--  ID UserJourney.       ,     TrustFrameworkExtension.xml-->
      <OrchestrationSteps><!--  .   -->
        <OrchestrationStep Order="1" Type="ClaimsExchange" ContentDefinitionReferenceId="api.localaccountsignup">
          <ClaimsExchanges> <!--       TechnicalProfileReferenceId. Id   ,       -->
            <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail-2" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="2" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" /> <!--     -->
      </OrchestrationSteps>
      <ClientDefinition ReferenceId="DefaultWeb" />
    </UserJourney>
    <UserJourney Id="PasswordReset">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="PasswordResetUsingEmailAddressExchange" TechnicalProfileReferenceId="LocalAccountDiscoveryUsingEmailAddress" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="NewCredentials" TechnicalProfileReferenceId="LocalAccountWritePasswordUsingObjectId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
      </OrchestrationSteps>
      <ClientDefinition ReferenceId="DefaultWeb" />
    </UserJourney>
       ...
  </UserJourneys>

ClaimsExchange Exchange-Beispiel

ClaimsExchanges .

    <ClaimsProviderSelections>
      <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" />
      <ClaimsProviderSelection TargetClaimsExchangeId="GoogleExchange" />
      <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
    </ClaimsProviderSelections>
    <ClaimsExchanges>
      <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
    </ClaimsExchanges>

Typische Aufgaben

Infolgedessen ist es für Sie einfacher, die folgenden Tutorials zu verstehen.

SignUpOrSignin.XML, ProfileEdit.XML, PasswordReset.XML

Dies sind die endgültigen Dateien, in denen Sie BuildingBlocks überschreiben \ hinzufügen können und in denen wir angeben, welche Daten dem Token hinzugefügt werden sollen.

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TrustFrameworkPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
  xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06" PolicySchemaVersion="0.3.0.0" TenantId="antekesd.onmicrosoft.com" PolicyId="B2C_1A_signup_signin" PublicPolicyUri="http://antekesd.onmicrosoft.com/B2C_1A_signup_signin">

  <BasePolicy>
    <TenantId>antekesd.onmicrosoft.com</TenantId>
    <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
  </BasePolicy>
  <BuildingBlocks>
    <ContentDefinitions>
      <ContentDefinition Id="api.signuporsignin"> <!--        -->
        <LoadUri>https://some.blob.core.windows.net/some/some.html</LoadUri>
        <RecoveryUri>~/common/default_page_error.html</RecoveryUri>
        <DataUri>urn:com:microsoft:aad:b2c:elements:contract:unifiedssp:1.2.0</DataUri>
      </ContentDefinition>
    </ContentDefinitions>
  </BuildingBlocks>
  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpOrSignIn" /> <!--  ,     -->
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="OpenIdConnect" />
      <OutputClaims> <!--    JWT Token.        -->
        <OutputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email"/>
        <OutputClaim ClaimTypeReferenceId="givenName" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="surname" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="email" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
        <OutputClaim ClaimTypeReferenceId="identityProvider" />
        <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
        <OutputClaim ClaimTypeReferenceId="picture" />
        <OutputClaim ClaimTypeReferenceId="country" Required="true"/>
      </OutputClaims>
      <SubjectNamingInfo ClaimType="sub" />
    </TechnicalProfile>
  </RelyingParty>
</TrustFrameworkPolicy>

Testen

Um die neuesten Änderungen zu testen, benötigen Sie:

Wechseln Sie zum Identity Experience Framework
Wählen Sie die Richtlinie aus, die Sie testen möchten.
Klicken Sie auf "Jetzt ausführen".

Fazit

Als Ergebnis erhalten Sie ein Autorisierungsformular, das die Anforderungen Ihres Kunden vollständig (oder fast) erfüllt.

Vielen Dank für Ihre Aufmerksamkeit!

Die Geschichte, wie ich Azure AD B2C für React and React Native konfiguriert habe Teil 2 (Tutorial)