When validating user passwords to make sure they are complex enough when creating an account through an Azure B2C custom policy, is it preferable to use Regexes, or Predicates?
The default custom policy we've downloaded from Microsoft uses Regexes, which does the job. But would it be better to change the policy file to use Predicates instead?
It's recommended to use the Predicates. The Predicates has better user experience and much more flexible to configure. Yep, the starter pack still use the Regex, but we advice customers to use the Predicates. See the Configure password complexity using custom policies in Azure Active Directory B2C doc for more info.
Azure AD B2C by default uses Strong passwords. You can configure the password complexity rules like min,max length, character set/class for bult in user flow.
Using the Custom policies we will have lot more freedom to configure the password complexity with Regular expression(regex) or by Predicate validation.
Regular expression and Predicate can be used restrict or set rules on the user input. There are some issue by using regex where you can over come with Predicate like the error message that we display for user input validation is scoped for the entire regex.
But by using Predicate validation you can define a collection of rules and can specify the error message that apply to different rule/rule groups which will help in communicating where users data entry is failing.
We recommend Predicates over Regex, but its upto you on choosing based on the password complexity you are building.
Related
We have implemented adb2c custom polices for providing options to user to select preferred method for MFA i.e either by Phone/SMS or Email.
Is there a way to find the analytics that how much time users are using either of the method.
Need this to identify if we really need to provide two options going forward or can remove one of them.
Appreciate any help on this.
You can add extra data to App Insights based on MFA selection.
You can then query the data and analyse the results.
I have a task to create a notification system where I can configure which email goes when based on conditions.
Since I would like it to be multi-tenant and customizable I thought that the conditions could be stored/configured in the same manner as Azure Policy json.
For my system I need:
conditions
parameter replacing
In "then" statement I would point to the notification id.
Is there any out-of-the-box library that I could use for evaluation of this kind of jsons?
Or my only option is to look at the source code of AZ Policy and create such a thing myself.
Thanks,
Rafal
To the best of my knowledge, this would not be possible with policy since policy does not support notification systems.
I need users to enter a date when signing-up or editing their profile in Azure AD B2C. Is there any way to do this without using Custom Policies?
I see two options:
Use a string extension attribute with a text input. But you cannot do client-side validation...
Use 3x string extension attributes (day, month, year) with 3x single-select drop-down inputs. I think this is the way I will need to do it.
Is there a simpler way? Am I missing something?
Why not use Custom Policies? This is the only functionality I am missing using the built-in policies, so it seems like overkill to introduce the additional complexity of getting everything working with Custom Policies, just to get a valid date. Plus Custom Policies are in preview at the time of asking, so are subject to change etc.
Many thanks!
I opened a question on the MSDN forums to see if I could get an answer there.
To sum it up, you need to use Custom Policies.
My concern regarding using features in Public Preview was addressed like so:
We recommend built-in policies for most scenario's. However, for specific requirement (scenario) built-in policies may not fetch you the actual results. In that situation, you have to use custom policies. Yes, you're right, Microsoft does not recommend using preview features in production environment. It is good to be cautious and follow the recommendations.
I have custom policies for sign up, sign in and reset password. All with custom ui.
I want to have different CSS styles and show different elements for different webs that use the sign up policy. Should I create different sign up policies with different custom UIs to accomplish this?
Also, I want to change the position of the UI fragments embedded by Azure B2C. Is css the only way to change this?
If you are using base b2c policies, then the only way is to create multiple sign-up/in policies. But please keep in mind that there's a limit to number of policies you can have in your b2c tenant (currently 100 policies). So if you want to do that also for reset password or any other user journey you will hit that really fast.
So... looking at the tags I can see Identity Experiance Framework, in that case you can use sample provided by MS - active-directory-b2c-ui-customization-custom-dynamic and change your UI based on the additional query parameter that is being sent to policy.
As for moving embedded elements inside your <div id="api"></div> CSS is the standard way. But you can look at the b2clogin.com program that is currently in public preview but it is not recommended to be used for any production use.
I'm working on applying a custom company security policy in my company's application.
I use the AdalJs library and I see that even if I apply the my Azure policy to the AD application, because of the silent renewing tokens, I'm not able to comply with the policy requirements.
Is there a parameter to set in AdalJs library to disable the Renewing Tokens?
If not, I'll be forced to modify the library, but it is not what I'd like to do.
Thank u in advance.
OaicStef
No, there is no such parameter we can disable token renewing. If you have a common scenario require this feature, I suggest that you submit the feedback from here.
And if it is not a common scenario, you may need to modify the source code. For example, you can modify the acquireToken function to remove the relative code about _renewToken and modify it based on your special requirement.