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
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!
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.
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.
I find the authorization flow confusing for calls to Azure's management APIs, i.e. not Azure API management which is the API gateway SaaS, and I'm hoping for some clarification.
From documentation at https://msdn.microsoft.com/en-us/library/azure/dn629581.aspx:
Although Azure originally allowed access only by Microsoft account users, it now allows access by users from both systems. This was done by having all the Azure properties trust Azure AD for authentication, having Azure AD authenticate organizational users, and by creating a federation relationship where Azure AD trusts the Microsoft account consumer identity system to authenticate consumer users. As a result, Azure AD is able to authenticate “guest” Microsoft accounts as well as “native” Azure AD accounts.
and http://blogs.technet.com/b/ad/archive/2014/08/15/prepping-for-new-management-features.aspx:
Your Microsoft Azure subscriptions uses Azure Active Directory to sign users in to the management portal and to secure access to the Azure management API.
The documentation leads me to believe the Azure AD tenant associated with a subscription acts as a STS with management API being the RP, or authorization server and resource server respectively using OAuth terminology. The tenant can also choose to trust third-party STSes, e.g. another tenant or Microsoft Account services, and thus allow for users from external identity providers access to the management API.
The blog post also writes:
Azure will soon require administrators to be registered in Azure Active Directory to be able to sign in to the Azure portal or use the Azure management API.
Disassociating an admin's account with the subscription's Azure AD tenant, irrespective if it is a "native" account to a tenant or a federated account, should in my mind revoke their access to the management APIs.
I tried validating the assumption using one my subscriptions and couldn't quite make sense of the result. Let's say the subscription has three admins:
Service admin SA using a federated Microsoft Account
A co-admin CA-AAD using an account "native" to the tenant trusted by the subscription
A co-admin CA-MSA again using a federated Microsoft Account
With all three accounts registered with the tenant, any of them can manage resources belonging to the subscription as well as use an web application that in turn access the Insights API through user impersonation.
Removing CA-AAD from the tenant disallowed the account from managing resources and accessing the Insights API once the cookie/access token had expired. This is the expected behavior, except the now non-exitant account still remains listed as a co-admin for the subscription.
However, removing CA-MSA from the tenant did not prevent the account from managing resources or accessing the API. This behavior even persisted between sessions and the account remained listed as a co-admin and not quite the expected outcome.
And now onto the questions:
Why is CA-MSA allowed continued access to management APIs despite it not registered with the tenant?
What is the authorization flow for accessing the management APIs?
How are accounts mapped to those listed as co-admins for a subscription?
Azure subscription refers only two directories for authorizing the users for accessing the management API.
the Azure AD to which the subscription is associated to.
Microsoft AD(MSA).
When a user with Microsoft Account is added as a subscription co-admin, user is indirectly registered in the Azure AD to which the current subscription is associated to. If the user is deleted from Azure AD, it still has the subscription access. It is because the user is still present in Microsoft Account AD.