We are looking into Azure AD B2C as a general identity management solution for our SaaS services.
One scenario we need to support is around distribution of pre-paid (stored value) payment cards, sold in stores or offered by other 3rd parties to customers. The customer gets the card with a PIN or one time registration code, and with that they can sign up to the cardholder portal, a web application / native app that allows them to view card history, balances and so on.
The sign up process needs to eventually identify the card as a custom claim, but also needs to validate the supplied code right there and then. The user needs to be able to go to the cardholder portal, click 'sign up' and be presented with input fields for the basic info plus the PIN/ reg code. On submit, the PIN/reg code needs to be validated.
Can Azure AD B2C support this type of scenario? Can the UI be completely custom? Are there any pricing implications to this? Also....is there anyway of having the native version of the app have a completely native version of the UI?
I believe you can configure this type of validation for new users signing up using Azure AD B2C Custom Policies. Custom policies allow you to define your own policy rather than using the built-in set. Specifically for your case, you'll be able to validate user data given at sign up with your own API.
Fair warning, custom policies can be complex to configure properly.
Related
I am building a Blazor Server web app that will have locked features only accessible via paid subscription (payment handled with stripe).
I am using Azure AD B2C for user management/authentication.
I also have an Android and iOS app built with Xamarin, from which users will be able to subscribe to the service (payment handled with Android/iOS built-in payment service), and therefore have full access to the web app.
What is the right approach to save the fact that a user has completed payment, and retrieve that data on future sign up ?
I read about custom attributes in Azure AD B2C, so maybe I should build the system on top of Azure AD B2C, but I am not sure it is the appropriate approach for this use case.
Thanks in advance
Yes, you could use a custom policy and custom attributes if you have a simple system where you just want to store a value and deny access during login if the value is not set.
For anything more complicated, rather store all the details in a DB and access it via a REST API.
Update
You can access the attribute direct from custom policies. You just read and write it like any other attribute.
If you want to use the Graph API, be aware the name is different.
After investigating what Azure AD B2C can do, I'm not sure if it can do everything we need it to do through custom policies / we would have to make some compromises. I was thinking of still using it purely for authentication actions against our users: sign in or sign up - local & social media accounts, reset password etc.
However, we also want to collect more details about the user that they either provide at sign up or at a later date, and I'm finding the ability to edit profiles quite lacking.
Therefore I was thinking instead to create a bespoke dot net core or framework application which will act as a 'preference centre' that the user goes through. We will have much greater customisation o this, as we will not be limited to what Microsoft allow through custom policies. The user would either be passed through this application after signing in and before reaching one of our applications, or they can get to it from a link on our applications. All the data that is stored for the user will still be held in the Users section in our Azure AD B2C. Then the application will use the Graph API to query and update the data for the user.
Is this a sensible approach? Or can you recommend something else?
We have a simple scenario but technologies(or implementation) have made things bit complex -
We have Sitecore as CMS for client's main web site and for business functionality we have Dynamics 365 Portal and we are using Azure AD B2C as identity provider for both.
We have heavily customised B2C custom policy to cater specific requirements.
We are using same custom policy in Sitecore and in Dynamics 365 Portals so sign in individually and works perfect without any issues.
With regards to SSO, we have kept the configuration as OOTB as you can find it here.
Only 1 or 2 user journeys are absolutely perfect as good as seamless journeys. In specific journeys we need user to be logged in both ends to make it work (we can force user to go to sign in page, but it is not required on all the pages).
In order to understand how real and proper SSO should work in Azure AD B2C, I have no idea or experience to relate this process to. so I am looking for guidance and help here.
I found very good information in this about how B2C works in terms of signin and providing tokens process but it bit old question and things have changed a lot since then specifically UI and some of the operations.
Use the following docs when configuring sessions management for a custom policy. Session Behavior section is where you define which SSO behavior. Specifically:
<SingleSignOn Scope="Application" />
If you want your users to get SSO between all applications, then define this value as "Tenant". There are several useful scenarios in creating separation between sessions - such as a company that has multiple brands that do not want to conflict each other. Or a separation of experiences.
Follow the exact format and location to be placed in your policy or you will not get the desired result.
Another concept that is important is the understanding the session provider:
SSO session management has two parts. The first deals with the user's interactions directly with Azure AD B2C and the other deals with the user's interactions with external parties such as Facebook. Azure AD B2C does not override or bypass SSO sessions that might be held by external parties. Rather the route through Azure AD B2C to get to the external party is “remembered”, avoiding the need to reprompt the user to select their social or enterprise identity provider. The ultimate SSO decision remains with the external party.
Session providers are used to define maintain what goes into generating the session when your policy is being executed (inside the Identity Experience Framework). If marked incorrectly, this could lead to undesirable results such as wrong claims being sent, additional MFA prompts, parts of your policy not being maintained when ran or just general errors.
This is for those who are interested in how we achieved this -
Sitecore also does offer OOTB Azure AD B2C configuration however the supplier of Sitecore delivery side decided not to use OOTB configuration approach and hence it caused lot of issues. From what I have read about Sitecore configuration for Azure AD B2C it does work smoothly with B2C with careful configuration.
Work Around: We had to rely on external triggers(e.g. cookie) which will indicate and trigger that a user has signed on either sides and accordingly the sign in process on both side kicks off.
I want to integrate Multi Factor Authentication (MFA) through Azure Active Directory (AD), I checked its documentation and some code samples, then I knew that Azure AD B2C have some of features which suits my requirement,
NOTE - I only need MFA feature from Azure AD B2C,
I tried this sample code provided in official docs, https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-tutorials-spa
But I have some of queries:
1) Is there any service in Azure B2C, which can directly provide MFA facility to integrate, without need to register users in Azure AD?
2) In Azure B2C, can I control user flow with information of my website? So that email and phone number will be of my website during user flow. (I am asking about this because according to my plan I am going to integrate it after login process in my website)
3) There are 3 types of account in Azure B2C, (Work account, Guest user, Consumer user), Which user type is most suitable? (I only need MFA for the user, and will require to manage users via Graph or any official API)
4) From where can I decide, which type of user will be registered? because the code which I have tried, doesn't mention about user type, (Actually I want to know that is there any param or option in user-flow, which can decide type of user, which will be registered through this flow)
Any help or suggestions will helpful for me,
Thanks in advance,
1. Is there any service in Azure B2C, which can directly provide MFA
facility to integrate, without need to register users in Azure AD?
Yes you can restrict new user to sign and sign up using MFA. For that need to enable MFA. Its global MFA for all.
See the screen shot below.
Note: You can also implement MFA for each individual user.
See the screen shot below for Individual MFA
Once you implement MFA you would be prompted to verify your phone
number like below
Note:
For Testing MFA Userflow need native application on application
drop down
See the screen shot below
2. In Azure B2C, can I control user flow with information of my
website? So that email and phone number will be of my website during
user flow. (I am asking about this because according to my plan I am
going to integrate it after login process in my website)
Yes you can customize your user flow. You can add new user flow according to yours.
To do that, Choose All services in the top-left corner of the Azure portal, and then search for and select Azure AD B2C
Then In the left menu, select User flows, and then select New user flow
See the screen shot below:
3. There are 3 types of account in Azure B2C, (Work account, Guest user, Consumer user), Which user type is most suitable? (I only need MFA for the user, and will require to manage users via Graph or any official API)
In short Work account has the more privileged in B2C tenant as the official document says. As consumer account cannot access some resource on portal. For accessing Microsoft Graph API Guest user has some restriction even on azure portal.
Note: As per your requirement I would suggest you to go with Work account which has some benefits while you would access Microsoft API
Though the account type mostly depend on your business needs but Work Account more useful comparing all aspect.
Let's say, If you want to add some user those who already registered some other organization but you need to add them in your particular application privilege. So need to add user as Guest privilege.
4. From where can I decide, which type of user will be registered?
Tough the question is bit confusing as I said earlier it would depend on your business needs. Work account usually best for tenant user. So when you feel within on your tenant if new user need to add so go with Work account. Once you specify your need it would definitely easier for you which kind of user you need to add. There is no such reference which can explain well upto to now.
Note: You could try adding all the user type to check how the user account behave using portal and accessing resources.
This is basically a follow up to my prev question - https://stackoverflow.com/a/44738654/2896495. I've implemented an Azure B2C sign up and auth in my web app (.NET Core 2.0) and now I want to add a custom sign up logic with Graph API (as described here - https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet).
But I'm confused about app registrations. For B2C auth I created an app in the Portal under Azure AD B2C -> Applications. Now, in order to use custom sign up logic I need another app registration under Portal -> App Registrations -> New Application Registration (where I can grant necessary permissions to Azure AD, like Read and Write directory data).
So, if I need auth AND custom sigh up, how should I set up my app? What's the right way of doing this?
For simplicity's sake, as well as a healthy separation of concerns, I would indeed make a separate app for the custom sign-up. It doesn't have to be a full-fledged app, a microservice that does the sign-ups for the main B2C app would be fine.
If you want to use the custom attribute to implement the custom sign up process, you need to register two apps as the document you mentioned in the post. One app is for integrating with Azure AD B2C for login, and the other is using the Azure AD Graph to query the custom attribute.
After that, you can using the Azure AD Graph REST to query the relative info and handle your own business logic in the web app. And to query the extension info, we just need to query the user info like below:
If you are just trying to have your own look and feel, as opposed to the default templates with your logos and other branding, then look into providing a template for UI customizations:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-ui-customization
Also, see this other answer to a similar question:
Azure AD B2C UI Customization
If you are trying for a whole different workflow, the you will want to create a custom policy.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-overview-custom
Or if that does not work, then I guess you could just use the GraphApi, but that is the most laborious of options and completely destroys the entire purpose of using B2C in the first place. I do not recommend this approach.
Update:
I would not do everything you want to do in a custom policy. Separating the signup into it's own application/service would be a great approach (as #camsoper suggested), but only use the policies for the bare amount needed to create the initial account or authenticate an approved user. I've never used a policy to change the "accountActive" attribute, but I would be inclined to use the GraphApi to modify the user profile after the account is created by using the "NewAccount" attribute to key off. There is a "Block sign in" setting on a users profile in the azure portal which can be used to restrict access (and the signup application could set the default after the account is created), but I'm not sure if that corresponds to the "accountActive" attribute or not (yet).
Most of the administration you've described can be done in the azure portal, such as changing the "Block sign in" setting on a users profile can be used to restrict access (and the signup application could set the default after the account is created). If there is some capability that the portal does not offer, I would put that into a separate application. Avoid duplicating functionality in your customized admin app, and instead just redirect the admin to the users profile in "portal.azure.com".
https://portal.azure.com/#blade/Microsoft_AAD_IAM/UserDetailsMenuBlade/Profile/userId/{objectId}
Note: there may be some issues with that URL template if the admin has access to more than one Directory for her account. It will try to pull up the directory that her account was created on by default.