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.
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've been reviewing some example custom policies that revolve around account linking which I would like to integrate in to my own set of policies. I've found the Azure B2C documentation lacking when it comes to explaining the difference between an 'alternative security' and 'user identities'.
The account linking policies I've been reviewing interact with a user's collection of identities via a handful of claims transformations (e.g. CreateUserIdentity, AddItemToUserIdentityCollection, RemoveItemToUserIdentityCollection and GetIssuersFromUserIdentityCollectionTransformation). The only place these claims transformations appear to be documented is in a random github issue comment posted more than two years ago. All the sample account linking policies also haven't been touched in a couple of years.
On the other hand, the base policy from the default starter packs use documented claims transformations to interact with a user's collection of identities (or at least to add an entry there when a user signs up via social idp). There are claims transformations documented here that match all the user identity ones above (e.g. CreateAlternativeSecurityId, AddItemToAlternativeSecurityIdCollection, RemoveAlternativeSecurityIdByIdentityProvider and GetIdentityProvidersFromAlternativeSecurityIdCollectionTransformation).
The distinction between these two concepts is really not clear to me. Why are there seemingly two ways (along with a parallel set of claims transformations), to interact with identities?
Can account linking can be achieved using the documented alternative security claims transformations? This would go against what appears to be the recommendation to use userIdentities claims transformations with account linking, but using years-old samples employing undocumented features really doesn't fill me with much confidence.
Yes, you can use either.
They are essentially two different naming conventions that refer to the same base structure.
Refer this and this.
ADB2C now allow us to use javascript within built-in policies.
But this is still a preview feature (since several months). Is it safe to use it or not ? We clearly need now to move on the new b2clogin.com domain and we would have taken the opportunity to also implement javascript.
Pubic previews are not suggested for production environment because, the behavior will change during preview and we can't confirm the GA date.
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 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.