Is there any way to restrict the user login from two different devices?
Unfortunately, Azure AD B2C cannot do this.
I understand why do you need this. But I think it should be configured in your Application ,not Azure AD B2C. For example, you can let your Application get the users' deviceIDs and restrict them can login from one device.
Actually, Azure AD B2C can do cloud identity management, so it cannot collect more information from users. For the security and private policy, Azure AD B2C may not have very powerful features.
Hope this helps!
Related
I have an requirement to implement both Azure B2C and B2B in a single application where B2C is used to login/signup, after user's login/signup the B2B is used to get Microsoft Intune Access??? is that possible to implement this flow?? any help will be appreciated.
Yes you can add multiple providers to most applications, for example if you use API's and azure functions or webapps etc, this can done either with EasyAuth or in your own code.
In simple terms you end up adding AAD as one provider and B2C as a second provider, meaning that your application will trust tokens from both services and then you go from there.
I have an ASP.Net core web application and integrated authentication using the Azure AD B2C Tenant/Application. I'm able to authenticate and get the user claims in my web application.
But what I additionally want is to allow only certain customer users access the web application. I want to do this at the B2C Tenant itself. Right now any B2C customer user can sign in. Any help, ideas, insight will be appreciated.
You may know there is an Manage user assignment for an app feature in Azure Active Directory. But it's not available in Azure B2C.
Currently the recommended way to control the access in Azure B2C is defining custom attributes and check the claims in token.
If the expected claim is included, you allow the user to continue.
The documentation for Azure Active Directory B2C states ADConnect can’t be used to migrate users. I believe this is referring to the native store.
“No, Azure AD Connect is not designed to work with Azure AD B2C.”
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-faqs
But can I use ADConnect if I configure Azure Active Directory as an Identity Provider?
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-setup-oidc-azure-active-directory
If you setup sync to an Azure AD from on-prem AD with AAD Connect,
and then connect that AAD as an identity provider to B2C,
it will work.
Note you should use another Azure AD tenant for this, OT the one underneath the B2C tenant.
It also works quite nicely at least based on my short testing that if you have a single IdP in the sign-in policy, the B2C pages don't even show up.
Of course the first time, users will have to "sign up" to the B2C tenant with their AAD account.
Technically the sentence is correct that you can't migrate users to B2C with AAD Connect, but there is this roundabout way of doing it.
Technically the users are not migrated to B2C, but we migrate them to a place where they can be utilized from by B2C.
Why does B2C "live" in its own Azure directory?
This seems to be the odd duck, no? Are there other Azure services this way? All of my other Azure resources live in the "default" directory.
It might help in understanding this by understanding the purpose of B2C. The idea here is to support a consumer facing application. For example, you might be building a consumer facing application and people all over the world might access it. You might want to outsource the security piece of that application to Azure AD.
Instead of integrating the application with your corporate Azure AD tenant, you can create a different AD directory, a B2C directory, that simply stores consumer identities. In this case, the B2C AD is completely separate from your corporate / main AD.
We all know that for one AAD tenant, it represents an organization. We can use AAD to manage users and resources for an organization. But for AAD B2C, it is just a service for authentication/authorization to all customers which relys application. It can integrate Soical accounts. AAD B2C cannot define those users belong to one organization.
However,AAD B2C still needs AAD to do authentication/authorization and manager users. In B2C, users are Local accounts or social accounts. In AAD, users are cloud accounts or on-premise synced accounts.
For example. If we use normal tenant also as a B2C tenant, the AAD authentication/authorization endpoint will be same. With this situation, we cannot distinguish the kind of users.It will result bad logic in product.
For distinguishing this two AAD, the B2C tenant must be separated.
Here is the clarify in official documentation:
Azure AD and Azure AD B2C are separate product offerings and cannot
coexist in the same tenant. An Azure AD tenant represents an
organization. An Azure AD B2C tenant represents a collection of
identities to be used with relying party applications. With custom
policies (in public preview), Azure AD B2C can federate to Azure AD
allowing authentication of employees in an organization.
Hope this helps!
I have what seems on the face of it a simple requirement when using Azure AD B2C. I have two applications (App A and App B) registered in Azure AD B2C. I want to restrict access so that User 1 can access both App A and App B, but User 2 should only be able to access App A.
I can register appRoleAssignments and assign them to a user via the Azure AD Graph API with a zero id as per this question When a user logs in, I can then query these and restrict access myself, but it feels like I'm reinventing the wheel and this should be provided by B2C.
Is this something Azure AD B2C is able to provide out of the box?
Azure AD B2C does not currently have first class support for application assignments.
As you've indicated, you'll need to implement this yourself.
You can request this feature in the Azure AD B2C Feedback Forum
I think the way you are doing it is the correct way, eventually Azure B2C will support role and group claims and this extra step wont be needed.