Azure b2c record custom policy started time and end time-CodePudding

My requirement is to know how much time it took for signin journey as per Microsoft documentation I implemented the application insights integration. but the sign-in and sin-in completions is recorded as separate records in application insights. I want to add policy started time and policy ended time in one record.
Trusted framework extension:
      <DisplayName>Application Insights</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="AppInsights-Common">
          <DisplayName>Application Insights</DisplayName>
          <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.Insights.AzureApplicationInsightsProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
          <Metadata>
            <!-- The ApplicationInsights instrumentation key, which you use for logging the events -->
            <Item Key="InstrumentationKey">XXXXXXXXXXX</Item>
            <Item Key="DeveloperMode">true</Item>
            <Item Key="DisableTelemetry ">false</Item>
          </Metadata>
          <InputClaims>
            <!-- Properties of an event are added through the syntax {property:NAME}, where NAME is the property being added to the event. DefaultValue can be either a static value or a value that's resolved by one of the supported DefaultClaimResolvers. -->
            <InputClaim ClaimTypeReferenceId="EventTimestamp" PartnerClaimType="{property:EventTimestamp}" DefaultValue ="{Context:DateTimeInUtc}" />
            <InputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="{property:TenantId}" DefaultValue="{Policy:TrustFrameworkTenantId}" />
            <InputClaim ClaimTypeReferenceId="PolicyId" PartnerClaimType="{property:Policy}" DefaultValue="{Policy:PolicyId}" />
            <InputClaim ClaimTypeReferenceId="CorrelationId" PartnerClaimType="{property:CorrelationId}" DefaultValue="{Context:CorrelationId}" />
            <InputClaim ClaimTypeReferenceId="Culture" PartnerClaimType="{property:Culture}" DefaultValue="{Culture:RFC5646}" />
          </InputClaims>
          
        </TechnicalProfile>

        <TechnicalProfile Id="AppInsights-SignInRequest">
          <InputClaims>
            <!-- An input claim with a PartnerClaimType="eventName" is required. This is used by the AzureApplicationInsightsProvider to create an event with the specified value. -->
            <InputClaim ClaimTypeReferenceId="EventType" PartnerClaimType="eventName" DefaultValue="SignInRequest" />
          </InputClaims>
          <IncludeTechnicalProfile ReferenceId="AppInsights-Common" />
        </TechnicalProfile>

        <TechnicalProfile Id="AppInsights-UserSignUp">
          <InputClaims>
            <InputClaim ClaimTypeReferenceId="EventType" PartnerClaimType="eventName" DefaultValue="UserSignUp" />
          </InputClaims>
          <IncludeTechnicalProfile ReferenceId="AppInsights-Common" />
        </TechnicalProfile>

        <TechnicalProfile Id="AppInsights-SignInComplete">
          <InputClaims>
            <InputClaim ClaimTypeReferenceId="EventType" PartnerClaimType="eventName" DefaultValue="SignInComplete" />
            <InputClaim ClaimTypeReferenceId="federatedUser" PartnerClaimType="{property:FederatedUser}" DefaultValue="false" />
            <InputClaim ClaimTypeReferenceId="parsedDomain" PartnerClaimType="{property:FederationPartner}" DefaultValue="Not Applicable" />
            <InputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="{property:IDP}" DefaultValue="Local" />
          </InputClaims>
          <IncludeTechnicalProfile ReferenceId="AppInsights-Common" />
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider> ```


**SIGNIN policy:**

    ```<UserJourneys>
        <UserJourney Id="SignUpOrSignInMFAOption">
          <OrchestrationSteps>
            <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
              <ClaimsProviderSelections>
                <!-- <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange"/> -->
                <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
              </ClaimsProviderSelections>
              <ClaimsExchanges>
                <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
              </ClaimsExchanges>
            </OrchestrationStep>
            <!-- Track that we have received a sign in request -->
            <OrchestrationStep Order="2" Type="ClaimsExchange">
              <ClaimsExchanges>
                <ClaimsExchange Id="TrackSignInRequest" TechnicalProfileReferenceId="AppInsights-SignInRequest" />
              </ClaimsExchanges>
            </OrchestrationStep>
            <!-- Check if the user has selected to sign in using one of the social providers -->
            <OrchestrationStep Order="3" 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="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
              </ClaimsExchanges>
            </OrchestrationStep>
            <!-- For social IDP authentication, attempt to find the user account in the directory. -->
            <!-- <OrchestrationStep Order="3" Type="ClaimsExchange">
              <Preconditions>
                <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                  <Value>authenticationSource</Value>
                  <Value>localAccountAuthentication</Value>
                  <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
              </Preconditions>
              <ClaimsExchanges>
                <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError"/>
              </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). 
              This can only happen when authentication happened using a social IDP. If local account was created or authentication done
              using ESTS in step 2, then an user account must exist in the directory by this time. -->
            <!-- <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> -->
            <!-- This step reads any user attributes that we may not have received when authenticating using ESTS so they can be sent 
              in the token. -->
            <OrchestrationStep Order="4" Type="ClaimsExchange">
              <Preconditions>
                <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                  <Value>authenticationSource</Value>
                  <Value>socialIdpAuthentication</Value>
                  <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
              </Preconditions>
              <ClaimsExchanges>
                <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
              </ClaimsExchanges>
            </OrchestrationStep>
            <!-- The previous step (SelfAsserted-Social) could have been skipped if there were no attributes to collect 
                 from the user. So, in that case, create the user in the directory if one does not already exist 
                 (verified using objectId which would be set from the last step if account was created in the directory. -->
            <!-- <OrchestrationStep Order="4" 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> -->
            <!--Sample: If uses is enrolled for MFA, ask the user to select the preferred method-->
            <OrchestrationStep Order="5" Type="ClaimsExchange">
              <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                  <Value>extension_mfaByPhoneOrEmail</Value>
                  <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
              </Preconditions>
              <ClaimsExchanges>
                <ClaimsExchange Id="SelfAsserted-Select-MFA-Method" TechnicalProfileReferenceId="SelfAsserted-Select-MFA-Method" />
              </ClaimsExchanges>
            </OrchestrationStep>
            <!-- Phone verification: If MFA is not required, the next three steps (#5-#7) should be removed.
                 This step checks whether there's a phone number on record,  for the user. If found, then the user is challenged to verify it. -->
            <OrchestrationStep Order="6" Type="ClaimsExchange">
              <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                  <Value>isActiveMFASession</Value>
                  <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
                <!--Sample: If the preferred MFA method is not 'phone' skip this orchestration step-->
                <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
                  <Value>extension_mfaByPhoneOrEmail</Value>
                  <Value>phone</Value>
                  <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
              </Preconditions>
              <ClaimsExchanges>
                <ClaimsExchange Id="PhoneFactor-Verify" TechnicalProfileReferenceId="PhoneFactor-InputOrVerify" />
              </ClaimsExchanges>
            </OrchestrationStep>
            <!-- Save MFA phone number: The precondition verifies whether the user provided a new number in the 
                 previous step. If so, then the phone number is stored in the directory for future authentication 
                 requests. -->
            <OrchestrationStep Order="7" Type="ClaimsExchange">
              <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
                  <Value>newPhoneNumberEntered</Value>
                  <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
              </Preconditions>
              <ClaimsExchanges>
                <ClaimsExchange Id="AADUserWriteWithObjectId" TechnicalProfileReferenceId="AAD-UserWritePhoneNumberUsingObjectId" />
              </ClaimsExchanges>
            </OrchestrationStep>
            <!--Sample: MFA with email-->
            <OrchestrationStep Order="8" Type="ClaimsExchange">
              <Preconditions>
                <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
                  <Value>extension_mfaByPhoneOrEmail</Value>
                  <Value>email</Value>
                  <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
              </Preconditions>
              <ClaimsExchanges>
                <ClaimsExchange Id="Email-Verify" TechnicalProfileReferenceId="EmailVerifyOnSignIn" />
              </ClaimsExchanges>
            </OrchestrationStep>
            <OrchestrationStep Order="9" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
            <!-- Track that we have successfully sent a token -->
            <OrchestrationStep Order="10" Type="ClaimsExchange">
              <ClaimsExchanges>
                <ClaimsExchange Id="TrackSignInComplete" TechnicalProfileReferenceId="AppInsights-SignInComplete" />
              </ClaimsExchanges>
            </OrchestrationStep>
          </OrchestrationSteps>
          <ClientDefinition ReferenceId="DefaultWeb" />
        </UserJourney>
      </UserJourneys> ```

How can I combine the signnin request time and signin complete time in one log from b2c custom application.


[enter image description here][1]


  [1]: https://i.stack.imgur.com/kRqUG.png
CodePudding user response：
You cannot, it will be two seperate events. You can correlate the events using the correlationId. Use Azure monitor and log analytics to manipulate the data.