ROPC with User Migration API issue

[kcrosby]

Related to #14; hoping @JasSuri can help out here...

Are there policy samples available for the ROPC flow with user migration included?

I'm working on one, but when I start my steps with the directory read for the migration status I get a "Method or operation not implemented" exception through App Insights before the first step even executes. When I change the order and do OAUTH first, my lookup succeeds as the second step, but obviously that doesn't work for actually migrating the user.

Here is the exception I get when leading with the directory read:

{ "Kind": "FatalException", "Content": { "Time": "3:18 PM", "Exception": { "Kind": "Handled", "HResult": "80004001", "Message": "The method or operation is not implemented.", "Data": {} } } }

[kcrosby]

Additional info...

Here is the Orchestration Step:

<OrchestrationStep Order="1" Type="ClaimsExchange"> <ClaimsExchanges> <ClaimsExchange Id="GetMigrationStatusFromB2C" TechnicalProfileReferenceId="GetMigrationStatus-ROPC" /> </ClaimsExchanges> </OrchestrationStep>

And here is the Technical Profile:

<TechnicalProfile Id="GetMigrationStatus-ROPC"> <Metadata> <Item Key="Operation">Read</Item> <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item> <Item Key="UserMessageIfClaimsPrincipalDoesNotExist">An account could not be found for the provided user ID.</Item> <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item> </Metadata> <IncludeInSso>false</IncludeInSso> <InputClaims> <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="signInNames.userName" Required="true" DefaultValue="{OIDC:Username}" AlwaysUseDefaultValue="true"/> </InputClaims> <OutputClaims> <OutputClaim ClaimTypeReferenceId="objectId" /> <OutputClaim ClaimTypeReferenceId="extension_userMigrated" DefaultValue="false" /> <OutputClaim ClaimTypeReferenceId="extension_aquaGUID" /> <OutputClaim ClaimTypeReferenceId="userMigrated" DefaultValue="true" AlwaysUseDefaultValue="true"/> </OutputClaims> <IncludeTechnicalProfile ReferenceId="AAD-Common" /> </TechnicalProfile>

[kcrosby]

As an additional update, I've tried making the first step a non-Azure AD lookup. I've tried one with Protocol="None" that just sets a claim value, and I get an error:

An attempt was made to resolve a protocol handler for unsupported protocol "None" in technical profile with id "GenerateUserMigratedClaim" in policy with id "B2C_1A_SignIn_ROPC" for tenant with id "mytenant.onmicrosoft.com"."

[kcrosby]

This has to be a bug with the ROPC flow, but there does appear to be a workaround. Make sure the first orchestration step contains the technical profile for ROPC OAUTH2, then add a pre-condition to ensure the step is always skipped. I checked for an objectId which would never exist when starting the flow. Here is my first step:

<OrchestrationStep Order="1" Type="ClaimsExchange"> <Preconditions> <Precondition Type="ClaimsExist" ExecuteActionsIf="false"> <Value>objectId</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> </Preconditions> <ClaimsExchanges> <ClaimsExchange Id="ResourceOwnerFlow1" TechnicalProfileReferenceId="ROPC-OAUTH2" /> </ClaimsExchanges> </OrchestrationStep>

Then after that, you can add your other migration steps as documented in #14 as necessary. Hope it helps!

[JasSuri]

Thats odd. We will review. This was a limitation that step 1 had to be the ROPC step. But we did make a change to allow REST API call prior to it. I am not sure if AAD Protocol for R/W was an option to have prior to the ROPC step, something we need to confirm.

[kcrosby]

Actually, my solution of putting the OAUTH step as #1 and then skipping it with a Pre-Condition doesn't appear to work either. It does the OAUTH in step 1 regardless of the pre-condition. Mine was only succeeding because I accidentally had the password the same in both B2C and the legacy platform.

[kcrosby]

I created a dummy API and called that with Step 1, then moved into my other steps. This appears to be working now. So it does appear you can lead with a REST API call, but in my case I need to query B2C first, then call the real migration REST API.

[JasSuri]

Yes makes sense to me as per my flow chart, its preferable to read the directory first assuming a pre-migration flags the migrated users in the directory using an extension attribute. For now, the only way forward would be to have the REST API read the directory using Graph API, or have it read a Azure Table which indicates whether the user needs to be migrated. This is less efficient as you have to call the API on every user auth, regardless of their current state :(

[dave22000]

@JasSuri @kcrosby I am following the same flow of using a useless REST API call (Azure Function that just returns 200) first before the actual flow - but not having to do that would be much better. Has anything changed here since February as far as reading the directory as the first step?