Is there something you cannot do with Azure Ad in which case you would use Azure Ad B2C?
One of the best use case of using Azure AD B2C is it allow users to sign in to your application with credentials from external social or enterprise identity providers (IdP). Azure AD B2C supports external identity providers like Facebook, Microsoft account, Google, Twitter, and any identity provider that supports OAuth 1.0, OAuth 2.0, OpenID Connect, and SAML protocols.
With external identity provider federation, you can offer your consumers the ability to sign in with their existing social or enterprise accounts, without having to create a new account just for your application.
Please refer these documents for more information.
Regarding technical comparisons between Azure ad b2b and azure ad b2c please refer Document
It’s very dependent on your user base. If you are serving an enterprise audience you would not use B2C but many public facing apps do not need you to login with your organisational email. Is there a use case that you have in mind, might be a good discussion if you do?
Azure AD now allows social logins via external identities.
Azure AD is typically for corporate customers that are mainly domain-joined e.g. email is joe#company.co.nz.
Azure AD B2C is for a non-corporate customer - not domain-joined e.g. email is joe#some-smtp.co.nz.
B2C also caters for people that don't have an email address e.g. via phone with an OTP.
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.
We're considering to use Azure AD B2B OR B2C for SSO service. We will not be using Azure B2B built-in SSO login page OR B2C custom-policies based login page. We've our own custom login JSP page that we plan to use MSAL Graph APIs for calling Azure AD authentication services.
Questions:
Is this MSAL APIs applicable to B2C only, or can we use this with B2B tenant application as well? All the documents and guidance that I can take as an example uses B2C tenant app only.
If I am using MSAL OAuth 2.0 authentication services for my custom login page, I assume we don't need to rely on SAML SSO configuration. Or would it be possible to use mix of these services (i.e. SAML for basic login authentication, MSAL OAuth2.0 calls for self service account registration)?
I appreciate if anyone can shed some light on this.
Thanks.
B2B and B2C serve two different purposes. B2B is meant for you to use to invite external federated users to your directory using their own credentials whereby you can assign them access directly to your resources. On the other hand, B2C is a separate directory where you allow users to register, optionally using their own credentials from federated providers as well. If your aim is to SSO to a local AzureAD protected resource, then clearly you're going to have to tell that resource to use the B2C directory as an IdP as well. Hence, B2B is much simpler for SSO, but a big differentiator is scale. If you plan to invite a massive number of users, then this it is not a good idea to user B2B.
MSAL uses standard protocols such as OAuth 2.0 and OIDC to authenticate directly to any supported IdP, including Azure AD or Azure AD B2C. Being a guest user or not has no bearing on that process. It is also important to mention that B2C does require either a User Flow or a Custom Policy to function.
So to answer your questions to the best of my ability:
1- MSAL libraries work similarly for both Azure AD and Azure AD B2C. There may be some configuration differences in case of B2C to supply additional information regarding the policy name, etc. But they work all the same.
2- MSAL itself does not support SAML authentication. For that you'll need a library which can perform SAML authentication. While Azure AD supports SAML natively, Azure AD B2C requires you to setup a custom policy to configure SAML authentication.
My Azure web application will have both internal and external users. The requirements regarding authentication are:
Internal users authenticate with their domain accounts (with SSO)
External users authenticate through Azure AD B2C (we need to create accounts for them)
How can I set up such scenario?
Regards
George
If your internal users are using Azure AD - simple - you add your corporate AAD as Identity provider to your B2C.
There are various ways to do this. So start here.
If your internal users do not have Microsoft 365 (Azure AD), and you only have on-premises AD DS infrastructure - ... move to Cloud, things will be so much easier. If not, you need at least ADFS, then you can hook up ADFS as Identity Provider in your B2C.
There is no way to make Windows Integrated Authentication and Claims Based authentication at the same time for the app.
AD FS is configured with custom policies as a claims provider on Azure AD B2C using WS-Federation and SAML. The relying party on Azure AD B2C is using OpenID Connect.
Is it possible to do front-channel single logout initiated through OpenID Connect?
OpenID Connect Front-Channel Logout 1.0 - draft 02: http://openid.net/specs/openid-connect-frontchannel-1_0-ID1.html
Single logout is initiated from the relying party using OpenID Connect and continued through Azure AD B2C using WS-Federation and reaching the AD FS. Thereby terminating the session in both the relying party, Azure AD B2C and AD FS.
If so, how is that configured in Azure AD B2C with custom policies?
Azure AD B2C does not support signing you out from the external identity provider, be it Facebook, Google or a custom OIDC/SAML/WS-Fed identity provider. It only signs you out from Azure AD B2C.
That practice is highly discouraged as it's quite invasive on the end user and risks discouraging the user from doing SSO, rather opting for local accounts.
For example, if the user signed in using Facebook and then signs out of your application, they'll probably be very annoyed by the fact that they've also been signed out of Facebook and after enough times of this happening, might give up on SSO using Facebook and just create a local account that doesn't messes up their experiences elsewhere. A similar case could be made for business customers that, by signing out of your app, also get signed out of all of their other business apps.
All that said, you can still request support for this via the Azure AD B2C feedback forum.
My organization has our own custom software solution hosted as a Web App in Azure. We are utilizing Azure AD for our authentication security. Some of our customers may have their own Office365 AD tenants, and so we take advantage of the B2B capabilities to invite these users to our apps and have some visibility of their accounts in our AD tenant (as external users).
We have one customer who would like for us to integrate with their Shibboleth service. We would like to support using their Shibboleth service as the identity provider for their users, and allow their MFA settings to be honored. We don't want to force them to create new identities in AD. What would be needed on our side to support this sort of trusted federation with Shibboleth? Ideally we'd like to be able to see their identities surfaced as external users in our AD tenant so that we're using a single security model for our app.
Azure AD's only equivalent for "trust" or "federation" with others is, as you've been doing, via B2B. Currently there is no B2B-like equivalent that supports direct federation to non-Azure AD IdPs.
However it is possible to set up Azure AD so that it leverages a third party IdP as its primary auth mechanism.
You should be able combine these two approaches to achieve what you want.
Have your customer sign-up for Azure AD
Have your customer configure Shibboleth as per the steps in this article: https://msdn.microsoft.com/en-us/library/azure/jj205456.aspx
Add your customer's users to your Azure AD via B2B as you've been doing for everyone else.