I am migrating an existing app using ASP.NET Identity to Azure B2C.
I wanted to migrate the existing user details to Azure AD, when user enter the credential in the Azure b2c login. Is there any way to call custom API on click of the Azure login button? If that is possible, I will call an API which will migrate the data to Azure AD.
I can't do one time migration from existing Identity to Azure B2C as we don't get the password as plain text from the database.
Please advice
This is possible with custom policies.
There is a sample for this particular scenario as well: https://learn.microsoft.com/en-us/azure/active-directory-b2c/user-migration#seamless-migration.
Custom policies do have quite a big learning curve, so this option might require a lot of work from you.
The other option is that you add all users in bulk and require everyone to do a password reset.
This is easier to do for you but will require some work from each user.
Related
We have on-prem sql server database which is connected to a legacy application. The on-prem database contains the username and password for the users. We are in process of migrating the existing solution to Cloud, and using Azure AD B2C for Authentication.
As the existing system is very big, so there is a phased transition we need to do which means keeping the both system running, allowing the users to login to the existing app as well as through Azure AD B2C in the cloud app.
I stumbled across API connectors for Azure AD B2C. I want to know if its possible to implement API connector for Sign In flow, in a way that it does the authentication against the external database store (legacy database) instead of Azure AD B2C.
From whatever I researched on google, it seems that API connector is called after authentication only. Also all the samples were related to Sign up flow. Can someone please guide me for a sample to achieve the login through external database using API connector ?
B2C supports integrating external identity providers. You can find a full list of them here:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-local?pivots=b2c-custom-policy
However, you are seeking to use a custom (generic) identity provider (IDP). This scenario is supported if the custom IDP supports either the OpenID Connector (OIDC) or SAML protocols. Please check that list in the URL above to review these options.
Regarding using the API connector, you can invoke the API connector before the authentication occurs in B2C using a validation technical profile in a custom policy. However, that does not achieve the actual authentication based on OIDC. Instead, it would be considered a validation step.
An overview of when you can use API Connectors is here.
You might be able to achieve a type of workaround using a custom policy to invoke your API connector to authenticate before authenticating in B2C and returning a success flag.
However, I think a better idea is to implement password synchronization. This seems like a perfect fit for you based on what you described. Users would be able to log into both your local system and Azure B2C simultaneously until you decommission your legacy authentication mechanism.
Your main requirement is that you have use a Microsoft Graph API SDK to update the B2C account password via your application backend. The bottom line is that you just need to keep the passwords the same in both systems. This is very easy to achieve with the Graph API, especially if you are developing in C# / .NET.
You also have to figure out how the B2C accounts get provisioned in the first place. This can happen in several different ways depending on your business requirements: Graph API, user sign up flow, import operation, etc.
API connectors only work for sign-up.
There's an example here but you will have to use custom policies.
Lets say I set up and create a new Azure Account and Subscription. Azure automatically creates me an Azure AD called "somedomain.onmicrosoft.com".
Later I deploy REST API and Angular SPA app to Azure. Since I'm using Azure AD for authentication and authorization on both of the applications I register them on my Azure AD, under the domain "somedomain.onmicrosoft.com".
Everything works fine, however after some time I realize that I want to allow access to my services/apps to other organizations. After doing some research I realize that what I want to achieve is multi-tenancy.
In order to register a new tenant I do the following:
Go to Azure portal.
On the left blade menu click on "Create a resource" and search for "Azure Active Directory".
Create a new directory called "tenant-1.onmicrosoft.com".
Next, I update my registered apps (on "somedomain.onmicrosoft.com") according to this documentation - enabling multi tenancy and common endpoint.
After all of this, both users from AD "somedomain.onmicrosoft.com" and "tenant-1.onmicrosoft.com" should be able to authenticate and access my services.
Question
Is this the correct way of achieving and implementing multi tenancy?
You don't need to create a new Azure AD tenant (xyz.onmicrosoft.com). Just register the application in the existing tenant or mark the existing application as multi-tenant. Then, existing other AAD tenants will be able to signup to use your app without doing further registrations. You will need to modify your app code to accept tokens from other tenants, e.g. enter link description here This link points to a regular .NET web app, not SPA. You will need to translate it to your SPA environment.
I'm not sure of your high level use case but one thing to note about the AAD multi-tenant approach. You are assuming that person signing in has an Azure AD tenant, for example through Office365.
If they don't have an Azure AD then they won't be able to sign in.
You 'could' create an AAD for each new tenant and create a user account in there.
They would have the bob#mydomain.onmicrosoft.com address and could add their own domain later.
That way they can then take advantage of all the enterprise features of AzureAD.
It might be a use case, but I think you would need an AAD per tenant and I'm not sure of the limits or if this is best practice.
You can also look at B2C if you want social logins/other OpenIDConnect.
I need to resolve the B2C login in a web application. I'm very new to B2C. The B2C token will contain the user information ? I can set it in the claims all the data that I need?
I must extend it from data from our DB, it is possible, too?
What specific issue are you running into? I can better diagnose your problem if you give me a bit more information.
If you follow the official Microsoft guide for ASP.NET web applications using B2C you can easily achieve B2C login. The guide comes with an accompanying Github sample that you can clone in order to achieve what you are looking for. Here you can also check out the B2C token reference page to see the contents of each type of token in B2C. You can use ID tokens to identify users in your app.
As for your second question, you can migrate data from your local database to Azure AD B2C but just cannot use Azure SQL. See this migration guide to learn how to do this using Azure AD Graph API.
we currently work on site that uses Azure B2C authentication for "normal" public users. The site has an admin backend that need "admin" users login. How do you do that? In azure B2C we can't have groups to identify which is an Admin. Can I use custom attributes like Admin-Boolean and set it to true in the Azure users portal? It is secure enough?
Unfortunately there is no easy solution here IMO.
Yes, you can use custom attributes to solve this problem.
You can set those custom attribute(s) via the Azure AD Graph API.
Then in your app you have to check those custom attribute(s).
The first problem with that solution is there has to be an account created to set those claims on. Depending upon your app this could be an inconvenience or pain point.
You can also set those attribute(s) on sign-up but that requires custom policies which is a whole nother animal IMO
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.