I want Azure for my application's identity management. Also I require a customer to sign up and become the owner account of my application. And he should send invitations to others. Example consider a university principal sending invitations to his instructors. An instructor sending invitations to his students. This should look like an inverted tree structure. Also my application should have many owner accounts. For example, multiple university principals should have an account in my application. How can I implement this using Azure? Should I use Azure AD B2C or Azure AD B2B?
I need azure only for authentication.
Difference to see to choose between the services is which user (random cunsumer or user from same organization) .
You can make use Azure AD B2B which is a feature of AzureAD service if the Application is for organisations and their corporate users.
Azure AD B2C target is to build a directory for consumer applications where users can register themselves with e-mail ID or social providers like Google, FB, MSA, known as Federation Gateway. Azure AD B2C is not targeted at organisation users but consumers.
Both are azure ad identity management services .It depend on who your users are from same organization or random customers that registers themselves.
In both services,user can send invitation to other user through portal or bulk of users using csv template from portal or powershell.
First the user need to sign in as global administrator to assign roles to users and groups.
The user can be given owner role to the app.
You can make more than one member as owner to an application
References:
azure-ad-vs-azure-ad-b2c-vs-azure-ad-b2b -SO reference
add-users
https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/groups-assign-member-owner
I want to create a multi-tenant application where users will log in using Azure AD B2C. I will grant access to certain tenants that are our customers using policies. Only business customers from select tenants will have access.
I have a customer that requires granular control over which of their users can access my application. From what I've understood, my application will be registered as a service principal in their tenant as soon as a user consents to the applications requested permissions.
That as all well, but the service principal is only a kind of account, with access to certain resources in their tenant that was granted when the application was accepted. When the application has been registered in their AD, anyone from that organization can sign in. When someone signs in, that automatically creates a Consumer account in Azure AD B2C in our tenant.
The consumer user can sign in to applications secured by Azure AD B2C, but cannot access Azure resources such as the Azure portal. The consumer user can use a local account or federated accounts, such as Facebook or Twitter. A consumer account is created by using a sign-up or sign-in user flow, using the Microsoft Graph API, or by using the Azure portal.
Now, I have a customer that also wants to control that only certain accounts within their AD can login. So basically, a user identity should not be able to access a service principal?
Is this a use case that is supported, and if so, how do I handle it and what terminology am I looking for? I don't want my organization to handle any of this if possible. I just want to give all users in a tenant access, and then it is up to the customer to grant/revoke access to individual users.
If I understand correctly, As you have created a multi-tenant application it will be registered in your tenant as a Service Principal and for the customers tenant it will be in Enterprise Application . So , if they want to give access to few users or a particular group then they can assign user/group to that particular Enterprise application.
Example:
Service Principal Created on my tenant :
It gets registered as a Enterprise application in other tenant So in there we can select Assign Users and Groups to give access to this Application from their tenant or they can set conditional access policy as well for specified set of conditions.
Reference:
Restrict Azure AD app to a set of users - Microsoft identity platform | Microsoft Docs
I have a requirement where we want the users to use their social accounts to login into our application (i.e. get an ID Token) through Azure B2C. I configured the Identity Provider and create a user flow for Sign in only. We don't want Users to Sign Up because that through Invitation only. When I use the "Invite User" to the live.com account and the user accepts the invitation and tries to login into the application, I get the below error.
AADB2C99002 User does not exist. Please sign up before you can sign in.
But the user is existing as a Guest User.
When I allow Sign up and the user actually does the Sign-up and then login in, it works.
Questions:
Why isn't the Guest User allowed to access the application? What needs to be done for the same to work?
If it's not possible, I don't want the user to be a "member" to avoid maintaining their credentials. I want the users to use their social accounts only.
As I don't have the requirement of self sign-up and the only invitation-based, how do I achieve my requirement?
Thanks,
Neel
Please see the Overview of user accounts in Azure Active Directory B2C.
Guest account - A guest account can only be a Microsoft account or an Azure Active Directory user that can be used to access applications
or manage tenants.
Consumer account - A consumer account is used by a user of the applications you've registered with Azure AD B2C. Consumer accounts
can be created by:
The user going through a sign-up user flow in an Azure AD B2C application
Using Microsoft Graph API
Using the Azure portal
Guest account is specifically distinguished from Consumer account. So Guest user can't sign into B2C application directly.
Your three questions are actually the same question: How to log in a social account without managing its credentials?
Please refer to Add an identity provider to your Azure Active Directory B2C tenant.
In order to let live.com account sign in, you need to Set up sign-in with a Microsoft account using Azure Active Directory B2C. Choose the policy type (User flow or Custom policy) you want to find the corresponding steps.
If you need your customers from other social idps such as Facebook, Google and so on, you can find the corresponding article on the left.
We are designing an application which will be used by client's employee, some of their vendors and consumers as well. All of these three types of user will have the different set of rights.
We were analyzing the Azure AD and found that Azure B2B can be used for employees and vendors whereas B2C can be used for consumers. So, we need both of them. Can we setup our application in such a way that if can authenticate from B2B and B2C both? Or any other suggestion to implement this.
Thanks In Advance
You can totally setup an app to authenticate with multiple directories.
Setup one Azure AD that will be used by employees, where partners can be added through B2B. Then also setup a B2C directory for the customers.
On your app side you need to display a choice for the user: if they want to sign in as an employee/partner or as a customer. Then you redirect to the correct sign-in page.
You'll need to define the app twice, once in both directories.
The actual implementation will vary based on your tech stack, but in ASP.NET Core you would need to setup multiple Open ID Connect middleware. And none of them can use AutomaticChallenge, as you do need to know where to redirect the user, you can't really choose for them.
Update to B2C allows you to do it all from there now
Azure AD B2C now allows custom policies (preview feature). This means you can use any OpenId Connect provider for sign-in, including Azure AD of course.
This new feature allows you to:
Create a B2C tenant with custom policy for employee/partner login through Azure AD
Send all users to authenticate with your B2C tenant
Users can choose if they want to sign in with social accounts or if they are an employee or partner
If they choose to sign in as employee or partner, they would be redirected to your Azure AD
In the end your app gets a token from B2C telling where the user signed in, so you can then do authorizations based on that info
We have three differnt websites and we want to use Azure AD for the purpose of single sign on. My question is how do I add users to Azure AD (via API) who could have differnt emails such as foo#gmail.com, bar#yahoo.com, baz#outlook.com, etc
When I try to add users with these emails to Azure via API, I get the error:
Property userPrincipalName is invalid.
If however I add users with azure tenant name (like reinhold#mytenant.onmicrosoft.com), they are added fine.
I searched in forums and google but to no avail.
So is there any way to add users having gmail/yahoo/outlook/other email addresses to Azure AD using API ?
Thanks
Short answer: you can't. Azure AD will support only users whose domain name is your own onmicrosoft.com domain, or that have an email address for a custom domain for which you have the rights to represent. If you expect people to signup with #yahoo or #gmail, etc addresses, Azure AD is not the directory you are looking for.
AAD supports consumer owned accounts through guest flows with MSA. So, your users can create an MSA for their #yahoo or #gmail account (the #outlook account is already an MSA). Then, you can invite the user to be a guest in your tenant using the Azure portal (just as you would invite an AAD user from another tenant to be a guest). See: https://azure.microsoft.com/en-us/documentation/articles/active-directory-create-users/.
There are two options here:
B2B Azure AD Tenant - where You add those users as guests. Your guests can be External AAD accounts, MSA Accounts, and you can setup federation for Google easily, and others. You can also enable "passcode" authentication to allow any email to be used without signup. They are emailed a one-time passcode that works for 30 days.
B2C Azure AD Tenant - This is where you are creating an authentication for a public site and want folks to use any email. It is presetup with lots of federation for you to configure.
From https://learn.microsoft.com/en-us/azure/active-directory/external-identities/compare-with-b2c as of 2021/04/20
What are External Identities in Azure Active Directory?
With External Identities in Azure AD, you can allow people outside your organization to access your apps and resources, while letting them sign in using whatever identity they prefer. Your partners, distributors, suppliers, vendors, and other guest users can "bring their own identities." Whether they have a corporate or government-issued digital identity, or an unmanaged social identity like Google or Facebook, they can use their own credentials to sign in. The external user’s identity provider manages their identity, and you manage access to your apps with Azure AD to keep your resources protected.
External Identities scenarios
Azure AD External Identities focuses less on a user's relationship to your organization and more on how the user wants to sign in to your apps and resources. Within this framework, Azure AD supports a variety of scenarios from business-to-business (B2B) collaboration to access management for consumer/customer- or citizen-facing applications (business-to-customer, or B2C).
Share your apps and resources with external users (B2B collaboration). Invite external users into your own tenant as "guest" users that you can assign permissions to (for authorization) while letting them use their existing credentials (for authentication). Users sign in to the shared resources using a simple invitation and redemption process with their work, school, or other email account. You can also use Azure AD entitlement management to configure policies that manage access for external users. And now with the availability of self-service sign-up user flows, you can allow external users to sign up for applications themselves. The experience can be customized to allow sign-up with a work, school, or social identity (like Google or Facebook). You can also collect information about the user during the sign-up process. For more information, see the Azure AD B2B documentation.
Build user journeys with a white-label identity management solution for consumer- and customer-facing apps (Azure AD B2C). If you're a business or developer creating customer-facing apps, you can scale to millions of consumers, customers, or citizens by using Azure AD B2C. Developers can use Azure AD as the full-featured Customer Identity and Access Management (CIAM) system for their applications. Customers can sign in with an identity they already have established (like Facebook or Gmail). With Azure AD B2C, you can completely customize and control how customers sign up, sign in, and manage their profiles when using your applications. For more information, see the Azure AD B2C documentation.
Compare External Identities solutions
The following table gives a detailed comparison of the scenarios you can enable with Azure AD External Identities.
External user collaboration (B2B)
Access to consumer/customer-facing apps (B2C)
Primary scenario
Collaboration using Microsoft applications (Microsoft 365, Teams, etc.) or your own applications (SaaS apps, custom-developed apps, etc.).
Identity and access management for modern SaaS or custom-developed applications (not first-party Microsoft apps).
Intended for
Collaborating with business partners from external organizations like suppliers, partners, vendors. Users appear as guest users in your directory. These users may or may not have managed IT.
Customers of your product. These users are managed in a separate Azure AD directory.
Identity providers supported
External users can collaborate using work accounts, school accounts, any email address, SAML and WS-Fed based identity providers, Gmail, and Facebook.
Consumer users with local application accounts (any email address or user name), various supported social identities, and users with corporate and government-issued identities via direct federation.
External user management
External users are managed in the same directory as employees, but are typically annotated as guest users. Guest users can be managed the same way as employees, added to the same groups, and so on.
External users are managed in the Azure AD B2C directory. They're managed separately from the organization's employee and partner directory (if any).
Single sign-on (SSO)
SSO to all Azure AD-connected apps is supported. For example, you can provide access to Microsoft 365 or on-premises apps, and to other SaaS apps such as Salesforce or Workday.
SSO to customer owned apps within the Azure AD B2C tenants is supported. SSO to Microsoft 365 or to other Microsoft SaaS apps isn't supported.
Security policy and compliance
Managed by the host/inviting organization (for example, with Conditional Access policies).
Managed by the organization via Conditional Access and Identity Protection.
Branding
Host/inviting organization's brand is used.
Fully customizable branding per application or organization.
Billing model
External Identities pricing based on monthly active users (MAU). (See also: B2B setup details)
External Identities pricing based on monthly active users (MAU). (See also: B2C setup details)
More information
Blog post, Documentation
Product page, Documentation
Secure and manage customers and partners beyond your organizational boundaries with Azure AD External Identities.
About multitenant applications
If you're providing an app as a service and you don't want to manage your customers' user accounts, a multitenant app is likely the right choice for you. When you develop applications intended for other Azure AD tenants, you can target users from a single organization (single tenant), or users from any organization that already has an Azure AD tenant (multitenant applications). App registrations in Azure AD are single tenant by default, but you can make your registration multitenant. This multitenant application is registered once by yourself in your own Azure AD. But then any Azure AD user from any organization can use the application without additional work on your part. For more information, see Manage identity in multitenant applications, How-to Guide.