Percorsi secondari

I percorsi secondari possono essere usati per organizzare e semplificare il flusso di passaggi di orchestrazione all'interno di un percorso utente. I percorsi utente specificano percorsi espliciti attraverso cui un criterio consente a un'applicazione relying party di ottenere le attestazioni desiderate per un utente. L'utente segue questi percorsi per recuperare le attestazioni che devono essere presentate alla relying party. In altre parole, i percorsi utente definiscono la logica di business di ciò a cui accede un utente finale mentre il framework dell'esperienza di gestione delle identità di Azure AD B2C elabora la richiesta. Un percorso utente è costituito da una sequenza di orchestrazione da seguire per garantire l'esito positivo di una transazione. L'elemento ClaimsExchange di un passaggio di orchestrazione è associato a un singolo profilo tecnico eseguito.

Un percorso secondario è un raggruppamento di passaggi di orchestrazione che possono essere richiamati in qualsiasi punto all'interno di un percorso utente. È possibile usare i percorsi secondari per creare sequenze di passaggi riutilizzabili o implementare il ramo per rappresentare meglio la logica di business.

Ramo del percorso utente

I percorsi secondari si comportano come i percorsi utente, come entrambi sono rappresentati come una sequenza di orchestrazione che deve essere seguita per una transazione riuscita. I percorsi utente possono essere richiamati autonomamente e richiedono un passaggio SendClaims da eseguire. I percorsi secondari sono componenti dei percorsi utente e non possono essere richiamati in modo indipendente e vengono sempre chiamati da un percorso utente.

Il componente chiave del ramo consiste nel consentire un'elaborazione migliore della logica di business in un percorso utente. I passaggi di orchestrazione comuni vengono raggruppati in singoli pezzi da richiamare separatamente. Un percorso secondario può semplificare un percorso in cui più passaggi di orchestrazione sono associati insieme (con le stesse precondizioni). Un percorso secondario viene chiamato solo da un percorso utente, non deve chiamare un altro percorso secondario.

Esistono due tipi di percorsi secondari:

• Chiamata : restituisce il controllo al chiamante. Il percorso secondario viene eseguito e quindi viene restituito il controllo al passaggio di orchestrazione attualmente in esecuzione all'interno del percorso utente.
• Trasferimento : trasferisce il controllo al sotto viaggio (ramo irreversibile). Il percorso secondario deve avere un passaggio SendClaims per restituire nuovamente le attestazioni all'applicazione relying party.

Scenari di esempio

Chiamare il percorso secondario

Un percorso secondario di chiamata è utile negli scenari seguenti:

• Age Gating: per il controllo dell'età, sono presenti molti componenti condivisi tra i percorsi utente. Il ramo consente di compilare gli elementi comuni in componenti condivisibili.
• Consenso parentale: branching consente la praticità nella progettazione del consenso genitoriale consentendoci di accedere alle attestazioni dal percorso utente eseguito dal minore, oltre a poter ramo in un percorso utente di consenso genitori dopo aver trovato il consenso dell'utente richiede il consenso.
• Iscriversi all'accesso: prendere in considerazione uno scenario in cui un utente esiste già nella directory, ma potrebbe aver dimenticato di aver creato un account. Potrebbe essere consigliabile in tal caso che invece di indicare all'utente che le credenziali immesse esistono già e forzare l'utente a riavviare il percorso in cui il criterio è in grado di eseguire un passaggio da un flusso di iscrizione a un flusso di accesso per tale utente.

Trasferimento secondario

Un percorso secondario Di trasferimento è utile negli scenari seguenti:

• Visualizzazione di una pagina di blocco.
• Test A/B instradando la richiesta a un percorso secondario per eseguire e rilasciare un token.

Aggiunta di un elemento SubJourneys

Di seguito è riportato un SubJourney esempio di elemento di tipo Call, che restituisce il controllo indietro al percorso utente.

<SubJourneys>
  <SubJourney Id="ConditionalAccess_Evaluation" Type="Call">
    <OrchestrationSteps>
      <OrchestrationStep Order="1" Type="ClaimsExchange">
       <ClaimsExchanges>
        <ClaimsExchange Id="ConditionalAccessEvaluation" TechnicalProfileReferenceId="ConditionalAccessEvaluation" />
       </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="2" Type="ClaimsExchange">
        <Preconditions>
          <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
            <Value>conditionalAccessClaimCollection</Value>
            <Action>SkipThisOrchestrationStep</Action>
          </Precondition>
        </Preconditions>
        <ClaimsExchanges>
          <ClaimsExchange Id="GenerateCAClaimFlags" TechnicalProfileReferenceId="GenerateCAClaimFlags" />
        </ClaimsExchanges>
      </OrchestrationStep>
    </OrchestrationSteps>
  </SubJourney>
</SubJourneys>

Di seguito è riportato un SubJourney esempio di elemento di tipo Transfer, che restituisce un token di nuovo all'applicazione relying party.

<SubJourneys>
  <SubJourney Id="B" Type="Transfer">
    <OrchestrationSteps>
      ...
      <OrchestrationStep Order="5" Type="SendClaims">
    </OrchestrationSteps>
  </SubJourney>
</SubJourneys>

Richiamare un passaggio del percorso secondario

Viene usato un nuovo passaggio di orchestrazione di tipo InvokeSubJourney per eseguire un percorso secondario. Di seguito è riportato un esempio che mostra tutti gli elementi di esecuzione di questo passaggio di orchestrazione.

<OrchestrationStep Order="5" Type="InvokeSubJourney">
  <JourneyList>
    <Candidate SubJourneyReferenceId="ConditionalAccess_Evaluation" />
  </JourneyList>
</OrchestrationStep>

Componenti

Per definire i percorsi secondari supportati dai criteri, aggiungere un elemento SubJourneys sotto l'elemento di primo livello del file di criteri.

L'elemento SubJourneys contiene l'elemento seguente:

Elemento	Occorrenze	Descrizione
SubJourney	1:n	Percorso secondario che definisce tutti i costrutti necessari per un flusso utente completo.

L'elemento SubJourneys contiene gli attributi seguenti:

Attributo	Obbligatoria	Descrizione
ID	Sì	Identificatore del percorso secondario che può essere usato dal percorso utente per fare riferimento al percorso secondario nel criterio. L'elemento SubJourneyReferenceId dell'elemento Candidate punta a questo attributo.
Tipo	Sì	Valori possibili: Callo Transfer. Per altre informazioni, vedere Branching del percorso utente

L'elemento SubJourney contiene l'elemento seguente:

Elemento	Occorrenze	Descrizione
OrchestrationSteps	1:n	Sequenza di orchestrazione da seguire per garantire l'esito positivo di una transazione. Ogni percorso utente è costituito da un elenco ordinato di passaggi di orchestrazione eseguiti in sequenza. Se un passaggio non riesce, la transazione ha esito negativo.

OrchestrationSteps

Per l'elenco completo degli elementi del passaggio di orchestrazione, vedere UserJourneys.

Passaggi successivi

Informazioni su UserJourneys