Konfigurowanie przepływu rejestracji i logowania przy użyciu konta społecznościowego przy użyciu niestandardowych zasad usługi Azure Active Directory B2C
W artykule Konfigurowanie przepływu rejestracji i logowania przy użyciu niestandardowego zasad usługi Azure Active Directory B2C skonfigurujemy przepływ logowania dla konta lokalnego przy użyciu usługi Azure Active Directory B2C (Azure AD B2C).
W tym artykule dodamy przepływ logowania dla konta zewnętrznego, takiego jak konto społecznościowe, takie jak Facebook. W takim przypadku usługa Azure AD B2C umożliwia użytkownikowi logowanie się do aplikacji przy użyciu poświadczeń od zewnętrznego dostawcy tożsamości społecznościowych (IdP).
W przypadku kont lokalnych konto użytkownika jest jednoznacznie identyfikowane przy użyciu atrybutu objectIdużytkownika. W przypadku zewnętrznego objectId dostawcy tożsamości używamy alternativeSecurityId atrybutu użytkownika, choć nadal istnieje.
Wymagania wstępne
Jeśli jeszcze go nie masz, utwórz dzierżawę usługi Azure AD B2C połączoną z subskrypcją platformy Azure.
Zarejestruj aplikację internetową i włącz niejawne przyznanie tokenu identyfikatora. W przypadku identyfikatora URI przekierowania użyj polecenia https://jwt.ms.
Na komputerze musi być zainstalowany program Visual Studio Code (VS Code ).
Wykonaj kroki opisane w temacie Konfigurowanie przepływu rejestracji i logowania dla konta lokalnego przy użyciu niestandardowych zasad usługi Azure Active Directory B2C. Ten artykuł jest częścią serii Instrukcje tworzenia i uruchamiania własnych zasad niestandardowych.
Uwaga
Ten artykuł jest częścią serii Instrukcje tworzenia i uruchamiania własnych zasad niestandardowych w usłudze Azure Active Directory B2C. Zalecamy rozpoczęcie tej serii od pierwszego artykułu.
Krok 1. Tworzenie aplikacji serwisu Facebook
Wykonaj kroki opisane w temacie Tworzenie aplikacji serwisu Facebook, aby uzyskać identyfikator aplikacji w serwisie Facebook i wpis tajny aplikacji. Pomiń wymagania wstępne i pozostałe kroki opisane w artykule Konfigurowanie rejestracji i logowanie się przy użyciu konta w serwisie Facebook.
Krok 2. Tworzenie klucza zasad serwisu Facebook
Wykonaj kroki opisane w temacie Tworzenie klucza serwisu Facebook jako klucza zasad w dzierżawie usługi Azure AD B2C. Pomiń wymagania wstępne i pozostałe kroki opisane w artykule Konfigurowanie rejestracji i logowanie się przy użyciu konta w serwisie Facebook.
Krok 3. Konfigurowanie logowania przy użyciu serwisu Facebook
Aby skonfigurować logowanie się za pomocą serwisu Facebook, należy wykonać następujące kroki:
- Deklarowanie większej liczby oświadczeń
- Zdefiniuj więcej przekształceń oświadczeń, aby ułatwić manipulowanie oświadczeniami, takie jak tworzenie
AlternativeSecurityIdelementu . - Konfigurowanie dostawcy oświadczeń serwisu Facebook
- Skonfiguruj profile techniczne firmy Microsoft Entra, aby odczytywać i zapisywać konto społecznościowe z i do bazy danych Firmy Microsoft Entra.
- Skonfiguruj własny profil techniczny (w celu akceptowania dodatkowych danych wejściowych od użytkownika lub aktualizowania szczegółów użytkownika) i jego definicji zawartości.
Krok 3.1 . Deklarowanie większej liczby oświadczeń
ContosoCustomPolicy.XML W pliku znajdź sekcjęClaimsSchema, a następnie zadeklaruj więcej oświadczeń przy użyciu następującego kodu:
<!--<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>-->
Krok 3.2 . Definiowanie przekształceń oświadczeń
ContosoCustomPolicy.XML W pliku znajdź ClaimsTransformations element i dodaj przekształcenia oświadczeń przy użyciu następującego kodu:
<!--<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>-->
Zdefiniowaliśmy trzy przekształcenia oświadczeń, których używamy do generowania wartości dla alternativeSecurityId i userPrincipalName oświadczeń. Te oświadczeniaTransformatacje są wywoływane w profilu technicznym OAuth2 w kroku 3.3.
Krok 3.3 — Konfigurowanie dostawcy oświadczeń serwisu Facebook
Aby umożliwić użytkownikom logowanie się przy użyciu konta w serwisie Facebook, musisz zdefiniować konto jako dostawcę oświadczeń, z którym usługa Azure AD B2C może komunikować się za pośrednictwem punktu końcowego. Konto w serwisie Facebook można zdefiniować jako dostawcę oświadczeń.
ContosoCustomPolicy.XML W pliku znajdź ClaimsProviders element, dodaj nowego dostawcę oświadczeń przy użyciu następującego kodu:
<!--<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>-->
Wymiana:
facebook-app-idz wartością serwisu FacebookappIDuzyskanego w kroku 1.facebook-policy-keyprzy użyciu nazwy klucza zasad serwisu Facebook uzyskanego w kroku 2.
Zwróć uwagę na przekształcenia oświadczeń zdefiniowane w kroku 3.2 w kolekcji OutputClaimsTransformations .
Krok 3.4 — Tworzenie profilów technicznych firmy Microsoft
Podobnie jak w przypadku logowania się przy użyciu konta lokalnego, należy skonfigurować profile techniczne firmy Microsoft, których używasz do łączenia się z magazynem Microsoft Entra ID, do przechowywania lub odczytywania konta społecznościowego użytkownika.
ContosoCustomPolicy.XMLW pliku znajdźAAD-UserUpdateprofil techniczny, a następnie dodaj nowy profil techniczny przy użyciu następującego kodu:<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>Dodaliśmy nowy profil
AAD-UserWriteUsingAlternativeSecurityIdtechniczny firmy Microsoft Entra, który zapisuje nowe konto społecznościowe w usłudze Microsoft Entra ID.Zastąp B2C_1A_TokenSigningKeyContainer kluczem podpisywania tokenu utworzonym w sekcji Konfigurowanie podpisywania.
ContosoCustomPolicy.XMLW pliku dodaj kolejny profil techniczny firmy Microsoft Entra poAAD-UserWriteUsingAlternativeSecurityIdprofilu technicznym przy użyciu następującego kodu:<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>Dodaliśmy nowy profil
AAD-UserReadUsingAlternativeSecurityIdtechniczny firmy Microsoft Entra, który odczytuje nowe konto społecznościowe z witryny Microsoft Entra ID. Jest on używanyalternativeSecurityIdjako unikatowy identyfikator konta społecznościowego.Zastąp B2C_1A_TokenSigningKeyContainer kluczem podpisywania tokenu utworzonym w sekcji Konfigurowanie podpisywania.
Krok 3.5 — Konfigurowanie definicji zawartości
Po zalogowaniu się użytkownika możesz zebrać z nich pewne informacje przy użyciu własnego profilu technicznego. Dlatego należy skonfigurować definicję zawartości dla własnego profilu technicznego.
ContosoCustomPolicy.XML W pliku znajdź ContentDefinitions element, a następnie dodaj nową definicję zawartości w ContentDefinitions kolekcji przy użyciu następującego kodu:
<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>
Używamy tej definicji zawartości jako metadanych w profilu technicznym asertywnego w następnym kroku (krok 3.6).
Krok 3.6 . Konfigurowanie samodzielnego profilu technicznego
Profil techniczny skonfigurowany w tym kroku jest używany do zbierania dodatkowych informacji od użytkownika lub aktualizowania podobnych informacji uzyskanych z konta społecznościowego.
ContosoCustomPolicy.XML W pliku znajdź sekcjęClaimsProviders, a następnie dodaj nowego dostawcę oświadczeń przy użyciu następującego kodu:
<!--<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>-->
Dodany dostawca oświadczeń zawiera własny profil techniczny, SelfAsserted-Social. Profil techniczny z potwierdzeniem własnym używa AAD-UserWriteUsingAlternativeSecurityId profilu technicznego jako profilu technicznego weryfikacji. AAD-UserWriteUsingAlternativeSecurityId Dlatego profil techniczny jest wykonywany, gdy użytkownik wybierze przycisk Kontynuuj (zobacz zrzut ekranu w kroku 7).
Zwróć również uwagę, że dodaliśmy definicję zawartości , socialAccountsignupContentDefinitionktóra została skonfigurowana w kroku 3.5 w sekcji metadanych.
Krok 4. Aktualizowanie kroków orkiestracji podróży użytkownika
ContosoCustomPolicy.XML W pliku znajdź HelloWorldJourney podróż użytkownika i zastąp wszystkie kroki orkiestracji krokami przedstawionymi w poniższym kodzie:
<!--<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>-->
W orkiestracji użyto odwołania do profilów technicznych, które umożliwiają użytkownikowi logowanie się przy użyciu konta społecznościowego.
Po uruchomieniu zasad niestandardowych:
Aranżacja Krok 1 — ten krok zawiera
ClaimsProviderSelectionselement, który zawiera listę dostępnych opcji logowania, które użytkownik może wybrać. W tym przypadku mamy tylko jedną opcję,FacebookExchangewięc po uruchomieniu zasad użytkownicy są bezpośrednio przekierowani do Facebook.com w kroku 2, jak pokazano w atrybucieTargetClaimsExchangeId.Orchestration Step 2 —
Facebook-OAUTHprofil techniczny jest wykonywany, aby użytkownik został przekierowany do serwisu Facebook w celu zalogowania się.Aranżacja krok 3 — w kroku 3 profil techniczny jest wykonywany,
AAD-UserReadUsingAlternativeSecurityIdaby spróbować odczytać konto społecznościowe użytkownika z magazynu Microsoft Entra ID. Jeśli konto społecznościowe zostanie znalezione,objectIdzostanie zwrócone jako oświadczenie wyjściowe.Orkiestracja Krok 4 — ten krok jest uruchamiany, jeśli użytkownik jeszcze nie istnieje (
objectIdnie istnieje). Przedstawia formularz, który zbiera więcej informacji od użytkownika lub aktualizuje podobne informacje uzyskane z konta społecznościowego.Orkiestracja Krok 5 — ten krok jest uruchamiany, jeśli użytkownik jeszcze nie istnieje (
objectIdnie istnieje), dlategoAAD-UserWriteUsingAlternativeSecurityIdprofil techniczny jest wykonywany w celu zapisania konta społecznościowego w identyfikatorze Entra firmy Microsoft.Aranżacja krok 6 — na koniec krok 6 zestawów i zwraca token JWT na końcu wykonywania zasad.
Krok 5. Aktualizowanie oświadczeń wyjściowych jednostki uzależnionej
ContosoCustomPolicy.XML W pliku znajdź RelyingParty element, a następnie zastąp całą kolekcję oświadczeń wyjściowych następującym kodem:
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surname" />
<OutputClaim ClaimTypeReferenceId="email" />
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
<OutputClaim ClaimTypeReferenceId="identityProvider" />
Dodaliśmy dostawcę tożsamości (identityProvider) jako oświadczenie wyjściowe, więc zostanie on uwzględniony w tokenie JWT zwróconym do aplikacji jednostki uzależnionej.
Krok 6. Przekazywanie zasad
Wykonaj kroki opisane w temacie Przekazywanie pliku zasad niestandardowych, aby przekazać plik zasad. Jeśli przekazujesz plik o tej samej nazwie co plik już w portalu, upewnij się, że wybierzesz pozycję Zastąp zasady niestandardowe, jeśli już istnieje.
Krok 7. Testowanie zasad
Wykonaj kroki opisane w artykule Testowanie zasad niestandardowych, aby przetestować zasady niestandardowe.
Nastąpi przekierowanie do strony logowania na Facebooku. Wprowadź poświadczenia serwisu Facebook, a następnie wybierz pozycję Zaloguj. Nastąpi bezpośrednie przekierowanie do serwisu Facebook, ponieważ ustawiliśmy go w krokach aranżacji, ponieważ nie mamy wielu opcji logowania do wyboru. Zazwyczaj w aplikacji można dodać przycisk, taki jak Zaloguj się za pomocą serwisu Facebook, który po wybraniu powoduje uruchomienie zasad.
Jeśli po raz pierwszy uruchamiasz te zasady (konto społecznościowe jeszcze nie istnieje w usłudze Microsoft Entra Storage), zostanie wyświetlony zrzut ekranu, taki jak pokazany poniżej. Ten ekran nie będzie widoczny w kolejnych wykonaniach zasad, ponieważ konto społecznościowe już istnieje w usłudze Microsoft Entra Storage.
Wprowadź lub zaktualizuj nazwę wyświetlaną, imię i nazwisko, a następnie wybierz przycisk Kontynuuj.
Po zakończeniu wykonywania zasad nastąpi przekierowanie do https://jwt.mselementu i zostanie wyświetlony zdekodowany token JWT. Wygląda podobnie do następującego fragmentu kodu tokenu JWT:
{
"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]
Zwróć uwagę, "idp": "facebook.com"że dostawca tożsamości , został uwzględniony w tokenie JWT.
Połączone logowanie lokalne i społecznościowe
W tym artykule nasze kroki aranżacji podróży użytkownika odwołują się tylko do profilów technicznych, które umożliwiają użytkownikowi logowanie się przy użyciu konta społecznościowego. Możemy zmodyfikować kroki aranżacji, aby umożliwić użytkownikowi logowanie się przy użyciu konta lokalnego lub konta społecznościowego. W tym celu pierwszy krok ClaimsProviderSelections aranżacji zawiera listę opcji logowania dostępnych dla użytkownika.
Aby dodać połączone konto lokalne i społecznościowe, wykonaj następujące czynności:
ContosoCustomPolicy.XMLW pliku znajdźAccountTypeInputCollectorwłasny profil techniczny, a następnie dodajauthenticationSourceoświadczenie w kolekcji oświadczeń wyjściowych przy użyciu następującego kodu:<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localIdpAuthentication" AlwaysUseDefaultValue="true" />UserJourneysW sekcji dodaj nową podróż użytkownika przyLocalAndSocialSignInAndSignUpużyciu następującego kodu:<!--<UserJourneys>--> ... <UserJourney Id="LocalAndSocialSignInAndSignUp"> <OrchestrationSteps> <!--Orchestration steps will be added here--> </OrchestrationSteps> </UserJourney> <!--</UserJourneys>-->W utworzonej
LocalAndSocialSignInAndSignUppodróży użytkownika dodaj kroki orkiestracji przy użyciu następującego kodu:<!--<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>-->W pierwszym kroku określamy opcje, które użytkownik musi wybrać podczas podróży, uwierzytelniania lokalnego lub społecznościowego. W kolejnych krokach użyjemy warunków wstępnych do śledzenia opcji wybranej przez użytkownika lub etapu podróży, w której znajduje się użytkownik. Na przykład używamy
authenticationSourceoświadczenia do rozróżniania lokalnej podróży uwierzytelniania i podróży uwierzytelniania społecznościowego.RelyingPartyW sekcji zmień wartość DefaultUserJourney naReferenceIdLocalAndSocialSignInAndSignUpUżyj procedury w kroku 6 i kroku 7 , aby przekazać i uruchomić zasady. Po uruchomieniu zasad zostanie wyświetlony ekran podobny do poniższego zrzutu ekranu.
Możesz zauważyć, że użytkownik może zarejestrować się lub zalogować przy użyciu konta lokalnego lub konta społecznościowego.
Następne kroki
- Dowiedz się więcej o sposobie definiowania profilu technicznego OAuth2 w zasadach niestandardowych usługi Azure Active Directory B2C.