SignUpOrSignIn Intermittent Exception

[sudolibre]

This issue is not reproducible on demand. Intermittently you will see errors logged stating "A claim could not be found for lookup claim with id "alternativeSecurityId" defined in technical profile with id "AAD-UserReadUsingAlternativeSecurityId-NoError""

It looks to me there is an unhandled case in the SignUpOrSignIn user journey. The journey assumes that if the authenticationSource is not localAccountAuthentication then the alternativeSecurityId claim will exist. This seems not to be true in practice. Step 2 in the user journey acknowledges that an objectId could already exist and if it does then it skips that step. That step is where the alternativeSecurityId gets created so if it is skipped and authenticationSource is social then you can get the error reported above. Looking further into the logs there is a field called objectIdFromSession which is set to true. So it seems that when the objectId is populated from a session it does not create a alternativeSecurityId from that session, it skips the step 2 that creates alternativeSecurityId, and because authenticationSource is set to social it goes into step 3 and we get the above error.

        <!-- 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="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>

[tripflex]

I can confirm that i'm having this issue as well

[max-nicholson]

Also having this issue.

Although we're using a custom 3rd party IDP instead of Facebook, our custom policy was built from this sample/snippet.

[ablanken-equinox]

I deleted my previous comment. We were seeing the same behaviour during SSO sign-ins but it was due to a custom technical profile referencing the SM-AAD claims provider incorrectly during sign-ins using social IDPs. We resolved the problem by adding a condition to skip execution of this TP when social sign-in/sign-up was used.