Objectives
This post considers scenarios where an application needs to be accessed by users from many sources of authentication. (Office 365, owned and operated by Microsoft but whose use is managed separately by many independent organizations is an example of such a resource). It proposes a framework for determining an optimal solution for the application using Azure AD.
The optimal identity infrastructure architecture to minimizes security risks, maximizes utility of authentication while minimizing its cost. In particular, providing single sign-on reduces the risk of user compromising their credentials (because they have to remember several). Also, having the credential managed outside of the application removes from it the cost of its management (storage, associated call center services, etc.).
However, providing SSO to users from many identity directories involves solving at least two technical problems. These are described in more detail below as Issues. The Discovery section describes a taxonomy that seems useful in understanding authentication requirements. These requirements are then used to identify distinct identity directory architectures addressing the cost/benefit objectives described above.
Issues
Providing access to a single application by users authenticated by several directories requires solutions to at least the following two technical issues.
1. Home Realm Discovery – there needs to be a way to determine which of the possibly many identity providers a user needs to be routed to in order to authenticate. Assuming the user’s initial, anonymous access arrives at the application, it or some service it uses needs to decide to which authentication server the user should be sent to. The user could be presented with a list of available choices (usually not a good idea) or be asked for some additional information (email address and thus their domain or some pre-defined value in the url) to direct the application to the appropriate authentication server.
2. Federation setup - establishing trust between the application and potentially many authentication servers. This process usually requires some manual configuration on both FP and IdP servers (configuring application ids, their urls, exchanging secrets) and may require periodic maintenance. Disparities between how different servers implement authentication protocols make this process non-trivial and somewhat error-prone. This process also requires cooperation from the administrators of the end user’s IdP and, dependending on how the application uses resources managed by that IdP may require privileged consent to the IdP itself (e.g. to read additional data).
Discovery
The optimal recommended solution choice is based on answers to questions, listed here with their main options:
1. Authentication - how are users authenticated?
a. Users lifecycle is managed by a corporate directory, i.e. their presence in the directory and attributes held about them is managed by some authority who owns the directory
i. Using Azure AD
ii. Using some other corporate IdP supporting a modern protocol (e.g. OpenID Connect, SAML2)
b. Users life-cycle is self-managed, i.e. they determine to join or leave in an identity provider and manage their own attribute, usually as social identity (Facebook, Gmail, MSA).
c. Users do not have either
2. Authorization - how is permission and level of access determined?
a. Collaborative use – the owner of the application uses a directory to determine who can access the application and with what privileges. Usually, the applications primary users are employees of one company but some access needs to be provided to selected users from other companies (partners).
b. Partitioned use – owner of the application controls its configuration and deployment but individual directories subscribe to its use and their owners control access to the application. (multi-tenant applications).)..
c. Self-asserted – individuals register to use the application or leave its use of their own volition, provide some of their attributes and may decide for themselves when to depart from the use of the application
Scenarios and solutions
The matrix below proposes identity infrastructure architectures for each combination of answers to the questions above:
| Authentication → Authorization ↓ |
Azure AD | Other modern | Social provider | None |
|---|---|---|---|---|
| Collaborative | 1 - AAD B2B | 4 - AAD B2B | 7 - AAD with social accts | 10 - AAD with MSA or Gmail |
| Partitioned | 2 - AAD Multi-tenant | 5 - App & tool (b2C, ADFS) based federation | 8 - B2C with custom multi-tenancy | 11 - B2C with custom multi-tenancy & local accounts |
| Self-asserted | 3 - AAD Multi-tenant | 6 - B2C using IEF to federate | 9 - B2C with social accounts | 12 - B2C with local accounts |
These scenarios, solutions and their main features are described in more detail below:
| Ref | Scenario | Solution | Pros | Cons |
|---|---|---|---|---|
| 1 | Users are in AAD directories and need to collaborate on a resource/application owned by one of these directories | Use AAD B2B features to allow federated access of users from one Azure AD tenant to resources managed in another. | Out-of-the-box support for HRD and federation setup. Easy to operate and manage. | |
| 2 | Users are in AAD directories, each of which controls its users access to a 3rd party application. | Use AAD multi-tenant application support. | Out-of-the-box support for HRD, consent and federation. | Application needs to be coded and configured to take advantage of these features (minor effort) |
| 3 | Users are in AAD directories and decide for themselves to use a 3rd party application. Application itself controls authorization based on minimal set of attributes provided by the users. | As above. The scenario is intended for any user with an AAD account to sign up for use of a 3rd party application | As above | Application may not require any user attributes beyond those volunteered by the individual users, e.g. it may not require. |
| 4 | Users are in a non-AAD directory supporting a modern protocol and need access to a resource whose access is managed by our AAD directory. | Use AAD B2B features for non-AAD users. Creates an un-managed AAD tenant for users with corporate email addresses. | Built-in HRD. Supports validation of users membership of an external, partner directory. Users need to authenticate using a one time code sent to their corporate email address. | No federation to user’s IdP, thus limited SSO for users: corporate authentication is not re-used. |
| 5 | Users are in a non-AAD directory supporting a modern protocol. Owners of each directory control access of their users to a 3rd party application. | Use B2C or ADFS farm to federate customer IdPs. | Application is not burdened with managing federations with multiple providers. All setup, consent, etc. done through the federation server | Manual federation setup & custom HRD code. B2C IEF may not scale to more than a handful IdPs. ADFS requires IaaS and does not support OIDC IdPs. |
| 6 | Users are in a non-AAD directory supporting a modern protocol. Application itself controls authorization based on minimal set of attributes provided by the users. | Use AAD B2C federating multiple providers. | Application is not burdened with managing federations with multiple providers. All setup, consent, etc. done through the federation server | Manual federation setup & custom HRD code. B2C IEF may not scale to more than a handful IdPs. Requires custom HRD and (except for OIDC IdPs) non-trivial federation setup. The latter is still in Public Preview. |
| 7 | Users have social accounts. Their access to the application is controlled by the owner of an AAD. | Use AAD B2B features for social accounts. | Seamless HRD and federation for MSA/Google ID users. | Users with other social accounts are required to setup an MSA account with the other social account’s email address. Collaboration on 3rd party software (e.g. SPO) is restricted. |
| 8 | Users have social accounts. From the applications point of view the users belong to distinct groups (tenants), each of which needs to control access to the application for its members. E.g. application for small businesses, whose employees use social identities. Each individual business controls its use of the software. | Custom application extensions using B2C (see example in references below). The extension manages data about user groupings and access privilege. | Built-in federation and HRD. Capable of supporting groups with few users, common in this space, where users often work in multiple small companies (e.g. vet clinic) but use same social identity for all of them. | Requires custom code and data storage to link users to application tenants. |
| 9 | Users have social accounts and register to use an application. | Core B2C scenario using social providers. | Simple federation setup for many social providers, ability to add MFA and custom attributes. Built-in HRD. | |
| 10 | Users do not have any identity accounts. Owner of an application controls their access to it through the directory. | AAD B2B using MSA/Google ID accounts. | Built-in federation and HRD, supports MFA. | Users of social accounts other than MSA or Google ID need to create an MSA account. |
| 11 | Users do not have any identity accounts. Application is used in a multi-tenant way (see 8 above). | Same as 8 but using local accounts. | As above. | Users need to register and manage their own credentials. |
| 12 | Users do not have any identity accounts but need to access an application requiring authentication. | Same as above (11) but no need for custom code to manage multi-tenancy. | As above. | As above. |
Multi-modal support
Few real-life situations fall neatly into one of the above categories. An application may need to support one of the above scenarios. This may require application level customization and extension to work. For example, https://b2cmultitenant.azurewebsites.net is an application using scenario 8 above (B2C multi-tenant). However, the same app accessed as https://b2cmultitenant.azurewebsites.net/aad supports scenario 2 (AAD Multi-tenant) as well. Application code detects the presence or absence of the url segment and redirects the user accordingly.
Sharepoint Online is an example of another application which is typically used in the multi-tenant scenario – published by Microsoft but access managed by individual subscribing organizations – is also often used in a collaborative scenario: an organization using SPO invites external users to access it in their subscription.
References
- AAD support for multi-tenant apps
- AAD and B2B features and this.
- AAD B2C
- Using B2C for multi-tenant support.
- Using Google ID in B2B. and this.