We want to build a .NET and Angular application which our internal users and invited external users can have access. We initially tried to build that by connecting to our internal azure-ad but that would mean that external users are part of our internal azure ad. One approach was to use Azure B2C AD but then not sure of how to get internal users in that AD without duplication. Eventually, we will have roles for users and wanted to check if we can avoid duplication of maintenance in multiple azure AD.
Hopefully, we are not doing something new i.e. creating an application that can be used by internal employees with their office 365 credentials and allowing invited external users to access the same application. Roles govern what part of the functionality is accessible within the application.
What are the possible approaches / recommended approach?
Use AAD B2C and add AAD as an identity provider to B2C, see here.
Let us assume I am an admin who is managing an Azure AD for my organization with about 3k users. All these 3k users have a login in Azure AD, and use a variety of Office365 services like Exchange Online, Microsoft Teams, Word Online etc.
Now, let us say, for some feature in Okta, we choose to federate our Azure AD with Okta, then what happens in the following scenarios :
Say there are as mentioned above the 3k users in Azure AD, only me in Okta, and I federate Azure AD, what happens? Is it like, the moment we federate Azure AD with Okta, everyone in our Azure domain can't login immediately? Or is there any possibility of doing this in a phased manner?
Say after all the 3k users now have an account in Okta as well. Can we maintain continuity? I.E after the users login to Azure AD via Okta, will they still see all their earlier data in Exchange Online, Teams, etc.
I assume there would be a mapping procedure to ensure continuity? How does that work?
There are a couple of things to take care of to ensure there is zero downtime:
AzureAD requires two attributes UPN (User Principal Name) and ObjectGUID to be passed from Okta. If your AzureAD and Okta users are both sourced from on-premise AD you will be fine, else you will need update AzureAD users to match the values with Okta.
Once federated with Okta, legacy authentication is disabled by default. If you need it, please make sure you update client access policies are updated accordingly in Okta
Federation with an AzureAD domain is big-bang but if you have multiple domains, you can federated them in a phases.
More details here: https://www.okta.com/resources/whitepaper/securing-office-365-with-okta/
Thank you
I'm quite new to all things MS/AD and coming from the app developer side of things so please bear with me if i'm not using the right terminology. I can't find confirmation in the online docs for this, so grateful for any ideas or links that could be helpful.
The scenario: my organization is a O365 shop and have a bunch of stuff in Azure. One project is a custom platform with several web apps. Most are accessed by our own folks via SSO, but some of these apps will be accessed by external users from our partners/vendors. A couple of these are MS shops but most are not and we can't require MS accounts.
The twist: we need to delegate user management to our partners/vendors. So as an example, for app3 we will have tons of partner/vendor organizations that need access. We want to give 1 person from that organization the responsibility of inviting their colleagues and removing folks when anyone leaves their organization. In many cases, they won't necessarily have the same email address domains so we can't restrict/group in that manner. In other cases, we need each national office of a global organization to have its own delegated admin to manage staff so there may be separate organizations with users that have the same email address domain.
My questions: Is Azure AD B2C the right approach for this?
Can it support this kind of delegated management (something like https://learn.microsoft.com/en-us/azure/active-directory/active-directory-accessmanagement-self-service-group-management)?
Would we need configure a separate Azure AD B2C directories for each external organization or should these be groups within one Azure AD B2C directory?
At this time there is no out-of-the-box support for user management delegation in Azure AD B2C, whether it's delegatin user management to other B2C admins using local (.onmicrosoft.com) accounts or external users using local (#myemail.com) or social accounts. Azure AD B2C does not support self-service group management capabilities either. You can request either of these in the Azure AD B2C feedback forum.
Is the same instance of these apps going to support people from these multiple organizations?
If the answer is no, meaning that your are going to have one instance of the app for organization A, and another for organization B, you can definitely have multiple Azure AD B2C directories and wire up each application to each directory.
If a single instance of these apps will need to support multiple of these organization, then I can think of two options for you:
Use Azure AD B2C and build all the delegation and user management logic yourself. You can have a custom attributes to assign users their "organization" and another to indicate whether they can manage users or not. You would then need to create a user management UI that queries the Graph for all users that are in the same "organization" and let the user manage those. You would also need to build the invitation feature, first into this UI by creating the user through Azure AD Graph and setting its "organization" claim accordingly, and then by directing users to the Password Reset policy as their "account verification" flow.
Use Azure AD and the B2B collaboration feature (including its ability to delegate invitations). This also opens up the self-service group management capabilities you referenced. If you don't want these users to get access to other things in your organization, you would probably want to create a separate Azure AD tenant for this and also invite people from your on Azure AD via B2B collaboration.
Conceptually, B2C is meant for external users, and Azure AD is meant for internal users, with B2B complementing those internal users with partners that collaborate enough with those internal users to be almost thought of as internal users. That being said, use whichever one best suits your needs. Don't forget to keep in mind that their pricing model is very different.
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.