Open RaphaelSilv opened 2 years ago
You can’t show a self asserted screen without at least one user input that is required to complete.
The sample is quite old. I would now design this using a claim transform technical profile to check if the account is disabled, then use the Oauth2 error technical profile to return an error to the app.
Thanks for the reply, Jas!
The sample is quite old. I would now design this using a claim transform technical profile to check if the account is disabled
Would you reuse a technical profile, let's say the "SelfAsserted-Social-v2" from (auto-account-link), or create a new one only for that purpose? Like "AAD-AssertAccountEnabled" .
Oauth2 error technical profile to return an error to the app.
How is that possible? Do you have any code snippets on this?
You can send the user to an orchestrations step which references this technical profile: https://learn.microsoft.com/en-us/azure/active-directory-b2c/oauth2-error-technical-profile
Hi! I am implementing an adaptation from the sample (A B2C IEF Custom Policy which allows disabling accounts that are from External IDPs) on top of auto-account-link and have a few doubts.
The first one is why the output claim "dummy" is necessary. Why would I need a self-asserted interaction from the user as at this point I already know his account is not enabled? I'd rather expect the assertion from the claims transformation right away. Does that make any sense?
I tried to directly replace the calling of "AAD-DisabledUserPage" with "AAD-AssertAccountEnabled" but got an error.
AADB2C: An exception has occurred. Correlation ID: 60ca1bf1-d42f-4e60-ad8c-ca2b6df0bd01 Timestamp: 2022-10-11 13:40:14Z
Don't know the root cause tho. By inspecting the logs I found the following:
Really appreciate your input. Cheers!