Configurar um fluxo de inscrição e entrada com uma conta social usando a política personalizada do Azure Ative Directory B2C
No artigo Configurar um fluxo de inscrição e entrada usando a política personalizada do Azure Ative Directory B2C, configuramos o fluxo de entrada para uma conta local usando o Azure Ative Directory B2C (Azure AD B2C).
Neste artigo, adicionamos um fluxo de entrada para uma conta externa, como uma conta social como o Facebook. Nesse caso, o Azure AD B2C permite que um usuário entre em seu aplicativo com credenciais de um provedor de identidade social (IdP) externo.
Para contas locais, uma conta de usuário é identificada exclusivamente usando o objectIdatributo user. Para IdP externo, usamos alternativeSecurityId o atributo user, embora ainda exista um objectId .
Pré-requisitos
Se você ainda não tiver um, crie um locatário do Azure AD B2C 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 no seu computador.
Conclua as etapas em Configurar um fluxo de inscrição e entrada para a conta local usando a política personalizada do Azure Ative Directory B2C. Este artigo faz parte da série de guias de instruções Criar e executar suas próprias políticas personalizadas.
Nota
Este artigo faz parte da série de guias de instruções Criar e executar suas próprias políticas personalizadas no Azure Ative Directory B2C. Recomendamos que comece esta série desde o primeiro artigo.
Passo 1 - Criar aplicação Facebook
Use as etapas descritas em Criar um aplicativo do Facebook para obter o ID do aplicativo do Facebook e o Segredo do aplicativo. Ignore os pré-requisitos e o resto dos passos no artigo Configurar inscrição e iniciar sessão com uma conta do Facebook.
Etapa 2 - Criar chave de política do Facebook
Use as etapas descritas em Criar o armazenamento de chaves do Facebook uma chave de política em seu locatário do Azure AD B2C. Ignore os pré-requisitos e o resto dos passos no artigo Configurar inscrição e iniciar sessão com uma conta do Facebook.
Passo 3 - Configurar o início de sessão com o Facebook
Para configurar o início de sessão com o Facebook, tem de executar os seguintes passos:
- Declarar mais reclamaçõ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 os perfis técnicos do Microsoft Entra para ler e gravar a conta 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 reclamações
ContosoCustomPolicy.XML No arquivo, localize a ClaimsSchema seção e, em seguida, declare 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, localize o ContosoCustomPolicy.XML ClaimsTransformations elemento 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 e alternativeSecurityId userPrincipalName declarações. Essas ClaimsTransformations são invocadas no perfil técnico 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, você precisa definir 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 um provedor de declarações.
ContosoCustomPolicy.XML No arquivo, localize ClaimsProviders o elemento , 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>-->
Substituir:
facebook-app-idcom o valor do FacebookappIDque obteve no passo 1.facebook-policy-keycom o nome da chave de política do Facebook que obteve no passo 2.
Observe as transformações de declarações que definimos na etapa 3.2 da OutputClaimsTransformations coleção.
Etapa 3.4 - Criar perfis técnicos do Microsoft Entra
Assim como no login com uma conta local, você precisa configurar os Perfis Técnicos do Microsoft Entra, que você usa para se conectar ao armazenamento de ID do Microsoft Entra, para armazenar ou ler uma conta social do usuário.
No arquivo, localize o
ContosoCustomPolicy.XMLAAD-UserUpdateperfil técnico e, em seguida, 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>Adicionámos um novo Perfil
AAD-UserWriteUsingAlternativeSecurityIdTécnico do Microsoft Entra que escreve uma nova conta social no Microsoft Entra ID.Substitua B2C_1A_TokenSigningKeyContainer pela chave de assinatura de token criada em Configurar a assinatura.
ContosoCustomPolicy.XMLNo arquivo, adicione outro perfil técnico do Microsoft Entra após o perfil técnico usando oAAD-UserWriteUsingAlternativeSecurityIdseguinte 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
AAD-UserReadUsingAlternativeSecurityIdTécnico do Microsoft Entra que lê uma nova conta social do Microsoft Entra ID. Ele usaalternativeSecurityIdcomo um identificador exclusivo para a conta social.Substitua B2C_1A_TokenSigningKeyContainer pela chave de assinatura de token criada em Configurar a assinatura.
Etapa 3.5 - Configurar a definição de conteúdo
Depois que um usuário faz login, você pode coletar algumas informações dele usando um perfil técnico autodeclarado. Portanto, você precisa configurar a definição de conteúdo para o perfil técnico autoafirmado.
ContosoCustomPolicy.XML No arquivo, localize o elemento e, em seguida, adicione uma nova definição de conteúdo na ContentDefinitions coleção usando o ContentDefinitions 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 autoafirmado na próxima etapa (etapa 3.6).
Etapa 3.6 - Configurar um perfil técnico autodeclarado
O perfil técnico autodeclarado que você configura nesta etapa é usado para coletar mais informações do usuário ou atualizar informações semelhantes obtidas da conta social.
ContosoCustomPolicy.XML No arquivo, localize a ClaimsProviders seção e, em seguida, 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 sinistros que adicionamos contém um perfil técnico autodeclarado, SelfAsserted-Social. O perfil técnico autoafirmado usa o AAD-UserWriteUsingAlternativeSecurityId Perfil Técnico como um perfil técnico de validação. Assim, o Perfil Técnico é executado quando o usuário seleciona o AAD-UserWriteUsingAlternativeSecurityId botão Continuar (veja a captura de tela na etapa 7).
Além disso, observe que adicionamos a definição de conteúdo, , socialAccountsignupContentDefinitionque configuramos na etapa 3.5 na seção de metadados.
Etapa 4 - Atualizar as etapas de orquestração da jornada do usuário
No arquivo, localize a jornada do usuário e substitua todas as etapas de orquestração pelas etapas mostradas no código a ContosoCustomPolicy.XML HelloWorldJourney seguir:
<!--<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, usamos fazer referência a perfis técnicos que permitem que um usuário faça login usando uma conta social.
Quando a política personalizada é executada:
Etapa de orquestração 1 - Esta etapa inclui um elemento que lista as opções de entrada disponíveis que um
ClaimsProviderSelectionsusuário pode escolher. Nesse caso, temos apenas uma opção, portanto, quando a política é executada, os usuários são levados diretamente para Facebook.com na etapa 2,FacebookExchangeconforme mostrado peloTargetClaimsExchangeIdatributo.Orquestração Passo 2 - O
Facebook-OAUTHperfil técnico é executado, de modo que o usuário é redirecionado para o Facebook para entrar.Orquestração Etapa 3 - Na etapa 3 , o
AAD-UserReadUsingAlternativeSecurityIdperfil técnico é executado para tentar ler a conta social do usuário do armazenamento de ID do Microsoft Entra. Se a conta social for encontrada,objectIdserá retornada como uma declaração de saída.Etapa de orquestração 4 - Esta etapa é executada se o usuário ainda não existir (
objectIdnão existe). Ele mostra o formulário que coleta mais informações do usuário ou atualiza informações semelhantes obtidas da conta social.Etapa de orquestração 5 - Esta etapa é executada se o usuário ainda não existir (
objectIdnão existe), então oAAD-UserWriteUsingAlternativeSecurityIdPerfil Técnico é executado para gravar a conta social no Microsoft Entra ID.Etapa de orquestração 6 - Finalmente, 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 da terceira parte confiável
No arquivo, localize o ContosoCustomPolicy.XML RelyingParty elemento e, em seguida, 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.
Passo 6 - Política de carregamento
Siga as etapas em Carregar arquivo de política personalizado para carregar seu arquivo de política. Se estiver a carregar um ficheiro com o mesmo nome que o que já se encontra no portal, certifique-se de que seleciona Substituir a política personalizada, caso já exista.
Etapa 7 - Política de teste
Siga as etapas em Testar a política personalizada para testar sua política personalizada.
Você será redirecionado para uma página de login do Facebook. Introduza as suas credenciais do Facebook e, em seguida, selecione Iniciar sessão. Você é redirecionado diretamente para o Facebook à medida que o definimos em nossas etapas de orquestração, já que não temos várias opções de login para escolher. Normalmente, em um aplicativo, você adiciona um botão como Entrar com o Facebook, que, quando selecionado, executa a política.
Se for a primeira vez que esta política é executada (a conta 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 social já existe no armazenamento do Microsoft Entra.
Introduza ou atualize o Nome a Apresentar, o Nome Próprio e o Apelido e, em seguida, selecione o botão Continuar.
Depois que a política terminar a execução, você será redirecionado para https://jwt.mso , e verá um token JWT decodificado. Ele é semelhante ao seguinte trecho 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.
Um login local e social combinado
Neste artigo, nossas etapas de orquestração da jornada do usuário fazem referência apenas a perfis técnicos que permitem que um usuário faça login usando uma conta social. Podemos modificar as etapas de orquestração para permitir que um usuário faça login usando uma conta local ou uma conta social. Para fazer isso, o elemento da primeira etapa de ClaimsProviderSelections orquestração lista as opções de entrada disponíveis para o usuário.
Use as seguintes etapas para adicionar uma conta local e social combinada:
ContosoCustomPolicy.XMLNo arquivo, localize o perfil técnico autodeclarado e, em seguida, adicioneauthenticationSourcedeclaração em sua coleção de declarações de saída usando oAccountTypeInputCollectorseguinte código:<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localIdpAuthentication" AlwaysUseDefaultValue="true" />UserJourneysNa seção , adicione uma nova jornada do usuário,LocalAndSocialSignInAndSignUpusando o seguinte código:<!--<UserJourneys>--> ... <UserJourney Id="LocalAndSocialSignInAndSignUp"> <OrchestrationSteps> <!--Orchestration steps will be added here--> </OrchestrationSteps> </UserJourney> <!--</UserJourneys>-->Na jornada do usuário que você criou,
LocalAndSocialSignInAndSignUpadicione 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 em sua jornada, autenticação local ou social. Nas etapas a seguir, usamos pré-condições para rastrear a opção que o usuário escolheu ou o estágio da jornada em que o usuário está. Por exemplo, usamos a
authenticationSourcedeclaração para diferenciar entre uma jornada de autenticação local e uma jornada de autenticação social.RelyingPartyNa seção , 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 conta social.
Próximos passos
- Saiba mais sobre como Definir um perfil técnico OAuth2 em uma política personalizada do Azure Ative Directory B2C.