In Azure B2C, I have a sign in user flow to sign in the user. Since they still don't have a password reset on first sign in, I used the following method.
The user has a custom attribute called 'IsUserNew'. This is used to
check whether the user is new or not.
If the user is new, I wanna
redirect the user to the B2C, with a password reset user flow.
The problem is, after sign in, the user is not redirecting to B2C. Is it because the user as already signed in with a user flow?
I believe you are using Custom Policy and your extension attribute is defined as boolean and value is true on registration, if this is the case you can do following:
OrchestrationStep for Authentication.
OrchestrationStep for Read User Details, in the technical profile add "extension_IsUserNew" so that this attribute can be read from User.
Add below in the next OrchestrationStep. This will check the attribute and call the Password Technical Profile.
<OrchestrationStep Order="3" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="false">
<Value>extension_IsUserNew</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
<Precondition Type="ClaimEquals" ExecuteActionsIf="false">
<Value>extension_IsUserNew</Value>
<Value>True</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="NewCredentials" TechnicalProfileReferenceId="LocalAccountWritePasswordUsingObjectId" />
</ClaimsExchanges>
</OrchestrationStep>
Add Step to modify the "extension_IsUserNew" value or delete the attribute so that Password Reset will not ask in the next login.
In 1 Policy only you can handle the Password Reset in 1st login, no need to create separate policies.
Related
The Microsoft documentation on subjourneys state the following: A sub journey is called only from a user journey, it shouldn't call another sub journey. (https://learn.microsoft.com/en-us/azure/active-directory-b2c/subjourneys#user-journey-branching)
From a development point of view it would be good to split reusable steps into subjouneys and call as required which is exactly how MS structure their policies, this is an extract of base-v1
<SubJourney Id="TotpFactor-Verify" Type="Call">
<OrchestrationSteps>
<OrchestrationStep Order="1" Type="InvokeSubJourney">
<JourneyList>
<Candidate SubJourneyReferenceId="SetTotpInitialValue" />
</JourneyList>
</OrchestrationStep>
<OrchestrationStep Order="2" Type="ClaimsExchange">
The base-v1 entire setup is small reusable subjourneys that are referenced from others.
Do we know if this statement in the documentation is out of date or it's not support for customer custom policies?
We are using Azure AD B2C login in our web application. We want to be able to set MFA for a B2C user based on a setting in the application. From the documentation, I can see that custom policies are able to be applied. But can the custom policy hook in to the application to read a setting (eg whether MFA should be applied in this case)?
Another approach we are considering is to set MFA programmatically for the user, based on the application setting. I have read that MFA can be set on a per user basis, through the Azure Portal. Is there a way to do this programmatically? I have looked at the Graph API but have not seen anything obvious.
I have tried setting the MFA setting for a user via the Azure portal, but this is not working for me yet. Despite setting the user's MFA to Enforced, the user can still sign in without being challenged. I also find the portal confusing, and for many users there is no clear way of identifying them (the portal only shows display name as Unknown and email address as an internal identity rather than an external identity).
I have seen these following posts Can I apply MFA to each user in Azure ADB2C and Azure AD B2C MFA on a function which do provide some useful information, but I am still unclear on this.
Is this possible, and which approach (custom policy hooking in to the application to read setting, or setting the MFA for the specific user from the application) would be better?
The way I normally do this is by having an extension attribute in B2C that determines whether the user has MFA or not.
Using the starter pack MFA sample e.g.:
<OrchestrationStep Order="7" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="false">
<Value>extension_MFA</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>isActiveMFASession</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="PhoneFactor-Verify" TechnicalProfileReferenceId="PhoneFactor-InputOrVerify"/>
</ClaimsExchanges>
</OrchestrationStep>
You would need to add the extension attribute as an output claim in a "AAD-UserRead" step.
We're implementing the embedded password reset, as is the new recommended practice. Once we click the Forgot your password? link the reset sub-journey is invoked as expected.
The reset sub-journy always skips the local account discovery step, where the user verifies their email to access their account information, and jumps directly to the screen to enter a new password - the new password entry then fails, because there is no account to write the new password into.
Our reset password journey is as follows:
<SubJourney Id="PasswordReset" Type="Call">
<OrchestrationSteps>
<OrchestrationStep Order="1" Type="ClaimsExchange">
<!-- This orchestration step never occurs. The user is never prompted for their email address. -->
<ClaimsExchanges>
<ClaimsExchange Id="PasswordResetUsingEmailAddressExchange" TechnicalProfileReferenceId="LocalAccountDiscoveryUsingEmailAddress" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="2" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="NewCredentials" nicalProfileReferenceId="LocalAccountWritePasswordUsingObjectId" />
</ClaimsExchanges>
</OrchestrationStep>
</OrchestrationSteps>
</SubJourney>
Our code, so far, is lifted directly from the tutorials and sample code. How can we fix this issue, and has anyone else encountered the same problem?
Your question has been solved, post it as the answer to the end of the thread:
This is a bug in the B2C system - the initial combined sign in and
sign up step seems to set the email claim, even if the user hits the
"forgot your password" link. The
LocalAccountDiscoveryUsingEmailAddress profile attempts to use the
(blank) claim without prompting the user to enter an address, jumping
to the password write step but not picking up an account to write the
password to. We worked around this by creating a new resetEmail claim
used only by the account discovery and password write profiles.
I need some advice on Customizing Azure B2c (Apple Identity Provider)
Is there a way to disable the sign up of a SignUpAndSignIn policy for an specific IDP? In that case apple?
I checked that post Azure B2C disable Sign up of a SignUpAndSignIn policy but is regarding to local signup, not for a social provider
You can do it only in custom policies. They are divided into steps (OrchestrationStep) which can be run under specified conditions (Precondition). One of those conditions can be identity provider selected. In your case it would be configuring the step which writes new external IdP user to directory to be skipped when particular provider is detected.
Something similar to this:
<OrchestrationStep Order="7" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimEquals" ExecuteActionsIf="true">
<Value>identityProvider</Value>
<Value>https://appleid.apple.com</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
</ClaimsExchanges>
However, this is just stopping the signup from happening. Some error handling, UX etc would have to be added as well.
Thank you very much for your time.
I'm receiving the following window, we don't want to see the following prompt
enter image description here
We want to use our Apple ID and jump to the app (see image bellow)
enter image description here
Azure B2C stores information about every claims principal logged in.
We do not need this information.
Users should be just passed through B2C from IdPs to service provider.
How to disable storing users information in B2C?
Here is the solution I found.
The base policy in SignIn userjourney
<UserJourney Id="SignIn">
contains an orchestration step that calls a technical profile AAD-UserWriteUsingAlternativeSecurityId
<OrchestrationStep Order="4" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>objectId</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="AAD-UserWriteUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
</ClaimsExchanges>
</OrchestrationStep>
This step creates user registrations in Azure B2C.
If this user journey is overloaded in an extension policy and this step skipped there then users will not be created.
Another step that checks users registration with id AAD-UserReadUsingAlternativeSecurityId-NoError
TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError"
can also be skipped.
The authentication process with an external identity providers goes on flawlessly without these steps.
Azure AD B2C does not store anything if you are using an external identity provider. But if you are using Azure AD B2C's idedntity provider, It will store the claims within it.
Hope the information helps.