If I attempt to both separate email verification and user registration (as per this sample) and use custom email verification (as per this one) in the same policy, I get a non-descript "The page cannot be displayed because an internal server error has occurred" 500 error after successful email validation but before the 2nd self-assertion screen is displayed. App Insights logging states that the policy transitioned to a Microsoft.Cpim.Common.PolicyException state, possibly after an IsSelfAssertedEmpty predicate returned true. But nothing in the logging suggests what's empty and as best I can tell nothing is. Any ideas either how to fix this issue or how to diagnose the cause?
Microsoft's sample for splitting email verification and sign-up includes a 'PartnerClaimType="Verified.Email"' attribute on the email output claim on the verification technical profile. Somehow, the out of the box email verification control provides this partner claim, whereas the custom control defined in their custom email example does not. I can't say I understand how this works since display controls can't have output claims, but removing the partner claim reference solves the 500 error.
Related
I want to get the user emails used for Azure organization on callback action of SSO web login flow.
Could you please advise which property and which API permission should I request for it? I tried upn, preferred_username, and email properties, but as I understand they can differ from the actual email.
Tried multitenant and single-tenant approaches.
Keep in mind that the user logs in with their UPN, which is typically (but isn't necessarily) the same as their email address.
The email claim should contain the user's email address if the directory is looked after by admins. That's the one you're after.
More information on the default claim set can be found here.
More information on how the UPN might be populated, including the approach of using an Alternate ID can be found here.
I'm using the built-in azure b2c sign up user flow in my application. The signup form doesn't give the proper validation messages. It always gives one generic message and it's always located at the top. Is there any way to customize this message and put it below the input field, that failed the validation?
The following image shows one scenario where the password is week. but still, the error message has no indication about the password.
Please take a look at this: https://learn.microsoft.com/en-us/azure/active-directory-b2c/localization#predicate using predicates to define the error message displayed to a user.
I am pre-creating federated users using the Graph API. Although I am using a SignUpSignIn custom policy, I want to be able to prevent a SignUp and show an error when a federated user is not already in the B2C directory. I have tried just removing the orchestration step that does SelfAsserted-Social but that didn't yield intended results.
Any help will be appreciated.
I was able to resolve this doing the following
Create a claim type to hold the message to the user
Create a claims transformation of type CreateStringClaim that populates the above claim type
Created a self-asserted technical profile that
a. hides the continue and cancel buttons
b. has an InputClaimsTransformation referencing 2. above.
c. has an Input claim of the claim type in 1. above
d. has an output claim of the claim type in 1. above
Remove/comment out the orchestration step that shows the self-asserted page for auth with social Idp
In the orchestration step that writes the federated account to AAD, I replace the referenced TP (AAD-UserWriteUsingAlternativeSecurityId) with the one in 3.
Later I will be using a ContentDefinition element to have the page that displays the error message contain a link that sends the user back to the beginning signin user journey.
I'm experiencing the same problem you had here, but unfortunately I'm not yet able to get what you did in those 5 steps.
I know 2 years have passed, but if still have access to the files which you used to do this that would be great!
When signing up a new user, the password field is setup to require a complex password. While entering the information a warning pops up if the field does not match the security pattern. If the user ignores that and tries to create the account, the warning about the password disappears and the heading says "One or More Fields are filled out incorrectly. Please check your entries and try again".
Problem is we are getting support calls from new users that can't create accounts because the warning about which specific field causing the error is hidden. They are left to guess which field is filled out incorrectly. Why does the B2C signup flow hide the fact that the passwords are not strong enough after they continue?
Thanks,
J
Yeah, I'm running into this as well. It's not a very good error message for a password not meeting the complexity requirements.
However, it is possible to modify the error message via the "Language Customization" feature.
It's a part of the user flow "Languages" tab.
The docs for language customization are here:
https://learn.microsoft.com/en-gb/azure/active-directory-b2c/language-customization?pivots=b2c-user-flow
The feature is also available for custom policies.
I need some help with this sample:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-rest-api-step-custom
I need to do the same but with signin policy, i need to validate the email with sql database and change a status column in database, and/or block access if the email is doesn't exist.
do you have some example for that?
Thanks
P.D: Excuse my english
The example you are pointing to is more useful for just retrieving additional claims for a user but not for validating the input. Since you are validating the email address, this example is more relevant:
Walkthrough: Integrate REST API claims exchanges in your Azure AD B2C user journey as validation on user input
This is what I would suggest:
Host your database behind a Rest API so it can be called to validate the email address
Create a technical profile using Web.TPEngine.Providers.RestfulProvider that calls into your Rest API (see the example I linked above)
Add a ValidationTechnicalProfile to the SelfAssertedAttributeProvider technical profile that collects the email so it will validate it and show an error if validation fails
By adding validation such as this, the user will be blocked with an error message and will have the opportunity to fix the input (e.g. typos) and try again. You can also get additional claims about that email address from the Rest API by adding them in the OutputClaims of both the technical profiles.
You will need to determine whether this is the right place to change the flag in the DB or if that ought to be a separate operation. The reason is that if the user goes to the next step in the user journey and then abandons it and comes back later, what would their experience be.
If you want it as a separate step later in the user journey, then you would create it using the example you provided (i.e. as a separate step after all the required steps have executed in the user journey).
The steps will be very similar except you will need to modify a different UserJourney and RelyingParty.
Update <UserJourney Id="SignUpOrSignIn"> as described in step 4.
Update SignUpOrSignin.xml as described in step 5.