Configurar um fluxo de inscrição e credenciais com uma conta de rede social usando a política personalizada do Azure Active Directory B2C
No artigo Configurar um fluxo de inscrição e credenciais usando a política personalizada do Azure Active Directory B2C, configuramos o fluxo de credenciais para uma conta local usando o Azure Active Directory B2C (Azure AD B2C).
Neste artigo, adicionamos um fluxo de credenciais para uma conta externa, como uma conta de rede social, por exemplo, o Facebook. Nesse caso, o Azure AD B2C permite que um usuário entre em seu aplicativo com credenciais de um IdP (provedor de identidade de rede social) externo.
Para contas locais, uma conta de usuário é identificada exclusivamente usando o objectIdatributo de usuário. Para o IdP externo, usamos o atributo de usuário alternativeSecurityId embora ainda exista um objectId.
Pré-requisitos
Se ainda não tiver um, você precisará criar um locatário do Azure AD B2C que esteja vinculado à sua assinatura do Azure.
Registre um aplicativo Web e habilite a concessão implícita de token de ID. Para o URI de redirecionamento, use https://jwt.ms.
Você deve ter o Visual Studio Code (VS Code) instalado em seu computador.
Conclua as etapas em Configurar um fluxo de inscrição e credenciais para uma conta local usando a política personalizada do Azure Active Directory B2C. Este artigo faz parte da série de guias Criar e executar suas próprias políticas personalizadas.
Observação
Este artigo faz parte da série de guias de instruções Criar e executar suas próprias políticas personalizadas no Azure Active Directory B2C. Recomendamos que você comece essa série com o primeiro artigo.
Etapa 1 – Criar aplicativo do Facebook
Use as etapas descritas em Criar um aplicativo do Facebook para obter a ID do Aplicativo e o Segredo do Aplicativo do Facebook. Ignore os pré-requisitos e o restante das etapas descritas no artigo Configurar a inscrição e a entrada com uma conta do Facebook.
Etapa 2 – Criar chave de política do Facebook
Use as etapas descritas em Criar um repositório de chaves do Facebook com uma chave de política em seu locatário do Azure AD B2C. Ignore os pré-requisitos e o restante das etapas descritas no artigo Configurar a inscrição e a entrada com uma conta do Facebook.
Etapa 3 – Configurar as credenciais com o Facebook
Para configurar as credenciais com o Facebook, você precisa executar as seguintes etapas:
- Declarar mais declarações
- Defina mais transformações de declarações para ajudar com manipulações de declarações, como a criação de
AlternativeSecurityId. - Configurar o provedor de declarações do Facebook
- Configure perfis técnicos do Microsoft Entra para ler e gravar a conta de rede social de e para o banco de dados do Microsoft Entra.
- Configure um perfil técnico autodeclarado (para aceitar entradas adicionais do usuário ou atualizar detalhes do usuário) e sua definição de conteúdo.
Etapa 3.1 – Declarar mais declarações
No arquivo ContosoCustomPolicy.XML, localize a seção ClaimsSchema e faça mais declarações usando o seguinte código:
<!--<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>-->
Etapa 3.2 – Definir transformações de declarações
No arquivo ContosoCustomPolicy.XML, localize o elemento ClaimsTransformations e adicione transformações de declarações usando o seguinte código:
<!--<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>-->
Definimos três transformações de declarações que usamos para gerar valores para as declarações alternativeSecurityId e userPrincipalName. Essas ClaimsTransformations são invocadas no perfil técnico do OAuth2 na etapa 3.3.
Etapa 3.3 – Configurar o provedor de declarações do Facebook
Para permitir que os usuários entrem usando uma conta do Facebook, defina a conta como um provedor de declarações com o qual o Azure AD B2C pode se comunicar por meio de um ponto de extremidade. Você pode definir uma conta do Facebook como provedor de declarações.
No arquivo ContosoCustomPolicy.XML, localize o elemento ClaimsProviders e adicione um novo provedor de declarações usando o seguinte código:
<!--<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>-->
Substitua:
facebook-app-idcom o valor deappIDdo Facebook obtido na etapa 1.facebook-policy-keycom o nome da chave de política do Facebook obtida na etapa 2.
Observe as transformações de declarações que definimos na etapa 3.2 na coleção OutputClaimsTransformations.
Etapa 3.4 – Criar perfis do Microsoft Entra
Assim como nas credenciais com uma conta local, você precisa configurar os Perfis Técnicos do Microsoft Entra, que você usa para se conectar ao armazenamento do Microsoft Entra ID, para armazenar ou ler uma conta de rede social do usuário.
No arquivo
ContosoCustomPolicy.XML, localize o perfil técnicoAAD-UserUpdatee adicione um novo perfil técnico usando o seguinte código:<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>Adicionamos um novo Perfil Técnico
AAD-UserWriteUsingAlternativeSecurityIddo Microsoft Entra que grava uma nova conta de rede social no Microsoft Entra ID.Substitua B2C_1A_TokenSigningKeyContainer pela chave de assinatura de token que você criou em Configurar a assinatura.
No arquivo
ContosoCustomPolicy.XML, adicione outro perfil técnico do Microsoft Entra após o Perfil TécnicoAAD-UserWriteUsingAlternativeSecurityIdusando o seguinte código:<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>Adicionamos um novo Perfil Técnico
AAD-UserReadUsingAlternativeSecurityIddo Microsoft Entra que lê uma nova conta de rede social do Microsoft Entra ID. Ele usaalternativeSecurityIdcomo um identificador exclusivo para a conta de rede social.Substitua B2C_1A_TokenSigningKeyContainer pela chave de assinatura de token que você criou em Configurar a assinatura.
Etapa 3.5 – Configurar a definição de conteúdo
Depois que um usuário entrar, você poderá coletar algumas informações deles usando um perfil técnico autodeclarado. Portanto, você precisa configurar a definição de conteúdo para o perfil técnico autodeclarado.
No arquivo ContosoCustomPolicy.XML, localize o elemento ContentDefinitions e adicione uma nova definição de conteúdo na coleção ContentDefinitions usando o seguinte código:
<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>
Usamos essa definição de conteúdo como metadados em um perfil técnico autodeclarado na próxima etapa (etapa 3.6).
Etapa 3.6 – Configurar um perfil técnico autodeclarado
O perfil técnico autodeclarado configurado nesta etapa é usado para coletar mais informações do usuário ou atualizar informações semelhantes obtidas da conta de rede social.
No arquivo ContosoCustomPolicy.XML, localize a seção ClaimsProviders e adicione um novo provedor de declarações usando o seguinte código:
<!--<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>-->
O provedor de declarações que adicionamos contém um perfil técnico autodeclarado, SelfAsserted-Social. O perfil técnico autodeclarado usa o Perfil Técnico AAD-UserWriteUsingAlternativeSecurityId como perfil de validação técnica. Assim, o perfil técnico AAD-UserWriteUsingAlternativeSecurityId é executado quando o usuário seleciona o botão Continuar (consulte a captura de tela na etapa 7).
Além disso, observe que adicionamos a definição de conteúdo, socialAccountsignupContentDefinition, que configuramos na etapa 3.5 na seção de metadados.
Etapa 4 – Atualizar as etapas de orquestração do percurso do usuário
No arquivo ContosoCustomPolicy.XML, localize o percurso do usuário HelloWorldJourney e substitua todas as etapas de orquestração pelas etapas mostradas no seguinte código:
<!--<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>-->
Na orquestração, fizemos referência a perfis técnicos que permitem que um usuário entre usando uma conta de rede social.
Quando a política personalizada é executada:
Etapa de orquestração 1 – Essa etapa inclui um elemento
ClaimsProviderSelections, que lista as opções de credenciais disponíveis que um usuário pode escolher. Nesse caso, temos apenas uma opção,FacebookExchange, portanto, quando a política é executada, os usuários são levados diretamente para Facebook.com na etapa 2, conforme mostrado pelo atributoTargetClaimsExchangeId.Etapa de orquestração 2 – O perfil técnico
Facebook-OAUTHé executado, portanto, o usuário é redirecionado para o Facebook para entrar.Etapa de orquestração 3 – Na etapa 3, o perfil técnico
AAD-UserReadUsingAlternativeSecurityIdé executado para tentar ler a conta de rede social do usuário do armazenamento do Microsoft Entra ID. Se a conta de rede social for encontrada,objectIdserá retornada como uma declaração de saída.Etapa de orquestração 4 – Essa etapa será executada se o usuário ainda não existir (
objectIdnão existir). Ela mostra o formulário que coleta mais informações do usuário ou atualiza informações semelhantes obtidas da conta de rede social.Etapa de orquestração 5 – Essa etapa será executada se o usuário ainda não existir (
objectIdnão existir), portanto, o Perfil TécnicoAAD-UserWriteUsingAlternativeSecurityIdserá executado para gravar a conta de rede social no Microsoft Entra ID.Etapa de orquestração 6 – Por fim, a etapa 6 monta e retorna o token JWT no final da execução da política.
Etapa 5 – Atualizar declarações de saída de terceira parte confiável
No arquivo ContosoCustomPolicy.XML, localize o elemento RelyingParty e substitua toda a coleção de declarações de saída pelo seguinte código:
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surname" />
<OutputClaim ClaimTypeReferenceId="email" />
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
<OutputClaim ClaimTypeReferenceId="identityProvider" />
Adicionamos o provedor de identidade (identityProvider) como uma declaração de saída, portanto, ele será incluído no token JWT retornado ao aplicativo de terceira parte confiável.
Etapa 6 – Carregar política
Siga as instruções em Carregar arquivo de política personalizado para carregar o arquivo de política. Se você estiver carregando um arquivo com o mesmo nome que o que já está no portal, selecione Substituir a política personalizada se ela já existir.
Etapa 7 – Testar a política
Siga as etapas em Testar a política personalizada para testar a política.
Você será redirecionado para uma página de credenciais do Facebook. Insira suas credenciais do Facebook e, em seguida, selecione Fazer Logon. Você será redirecionado diretamente para o Facebook, uma vez que nós definimos isso em nossas etapas de orquestração, uma vez que não temos várias opções de credenciais para escolher. Normalmente, em um aplicativo, você adicionaria um botão como Entrar com o Facebook, que, quando selecionado, executa a política.
Se for a primeira vez que essa política é executada (a conta de rede social ainda não existe no armazenamento do Microsoft Entra), você verá uma captura de tela, como a mostrada abaixo. Você não verá essa tela em execuções de política subsequentes, pois a conta de rede social já existe no armazenamento do Microsoft Entra.
Insira ou atualize o Nome de Exibição, o Nome e o Sobrenome. Em seguida, selecione o botão Continuar.
Depois que a política concluir a execução, você será redirecionado para https://jwt.ms e verá um token JWT decodificado. Ele é semelhante ao seguinte snippet de token 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]
Observe que o provedor de identidade, "idp": "facebook.com", foi incluído no token JWT.
Credenciais local e social combinadas
Neste artigo, nossas etapas de orquestração de percurso do usuário fazem referência apenas a perfis técnicos que permitem que um usuário entre usando uma conta de rede social. Podemos modificar as etapas de orquestração para permitir que um usuário entre usando uma conta local ou uma de rede social. Para fazer isso, o elemento ClaimsProviderSelections da primeira etapa de orquestração lista as opções de credenciais disponíveis para o usuário.
Use as seguintes etapas para adicionar uma conta local e uma de rede social combinadas:
No arquivo
ContosoCustomPolicy.XML, localize o perfil técnicoAccountTypeInputCollectorautodeclarado e adicione a declaraçãoauthenticationSourceem sua coleção de declarações de saída usando o seguinte código:<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localIdpAuthentication" AlwaysUseDefaultValue="true" />Na seção
UserJourneys, adicione um novo percurso do usuário,LocalAndSocialSignInAndSignUpusando o seguinte código:<!--<UserJourneys>--> ... <UserJourney Id="LocalAndSocialSignInAndSignUp"> <OrchestrationSteps> <!--Orchestration steps will be added here--> </OrchestrationSteps> </UserJourney> <!--</UserJourneys>-->No percurso do usuário que você criou,
LocalAndSocialSignInAndSignUp, adicione etapas de orquestração usando o seguinte código:<!--<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>-->Na primeira etapa, especificamos as opções que um usuário precisa escolher durante sua jornada, autenticação local ou social. Nas etapas a seguir, usamos pré-condições para acompanhar a opção escolhida pelo usuário ou o estágio do percurso no qual o usuário se encontra. Por exemplo, usamos a declaração
authenticationSourcepara diferenciar entre um percurso de autenticação local e um percurso de autenticação por redes sociais.Na seção
RelyingParty, altere DefaultUserJourney'sReferenceIdparaLocalAndSocialSignInAndSignUpUse o procedimento na etapa 6 e na etapa 7 para carregar e executar sua política. Depois de executar a política, você verá uma tela semelhante à captura de tela a seguir.
Você pode observar que um usuário pode se inscrever ou entrar usando uma conta local ou uma de rede social.