Azure Active Directory multi-tenant authentication hosted on Microsoft Azure Cloud Infrastructure, has the potential to centralize identity management and improve usability within Azure applications across an organization.
It facilitates tenant credentials used in one Azure AD application to enable access to any other Azure application, once a user provides their consent for the process.
The single-sign-on (SSO) experience, powered by Azure AD’s automated SaaS app access management and provisioning capabilities, enables it to be used by both employees and partners.
The image below depicts the process of multi-tenant authentication outlined in this blog.
The need for multi-tenant authentication
Application accessibility can be a complex and difficult process to manage. Multi-tenant authentication helps simplify the whole process by enabling a user to easily authenticate to a database by using a valid user ID despite any tenancy. This solution offers a quicker and feasible use of the Azure Active Directory available under Microsoft Azure Cloud Services because the data is now more easily accessible across various tenants.
Benefits of multi-tenant authentication
- Easy upgrades. Instead of requiring a vendor to update every instance of its software across a large number of servers, multi-tenant authentication enables it to update a single central application or codebase and have the changes instantly available to all users. As a result, the process for setting up a new cloud and application on behalf of a new customer is much easier.
- Easy customizations. With multi-tenancy-based applications, developers can create an additional layer to allow for customizations while still maintaining the underlying codebase that remains constant for all users.
- Ongoing cost savings. Multi-tenancy is a cost-effective approach. It speeds upgrades by eliminating the need to create multiple active directories for every application since a single active directory with multi-tenant authentication can be used instead of separate authentications for every login.
Creating multi-tenant authentication
The implementation of multi-tenant authentication does require some development.
Developers or admins need to register the app using the Azure portal in the Active Directory section of the App Registration Tab. They also need to add permissions using the Required Permissions section in the Azure AD of the requested app.
When the Azure AD app is created it will, by default, add the permission for the app as shown in the below-mentioned snippet.
As the Azure AD app is used for authentication through the user, the permission to the application only requires user consent without any admin requirement. The below-mentioned screenshot depicts this.
Differences between user and admin controls / consent
Both the user and admin consent experience for Multi-Tenant authentication is affected by the permissions requested by the application. Azure AD supports two kinds of permissions, app-only and delegated:
- A delegated permission grants an application the ability to act as a signed-in user for a subset of the things the user can do. For example, you can grant an application the delegated permission to read the signed in user’s calendar.
- An app-only permission is granted directly to the identity of the application. For example, the application can be granted the app-only permission to read the list of users in a tenant, regardless of who is signed into the application.
Some delegated permissions (read-only) require a tenant user’s consent. If your application requests delegated permissions (read-only) and a user tries to sign into the application, it asks the user to consent with a yes or no option. Once the user has given consent to the application and tries to access the resource from the Azure Active Directory (which requires read-only permission for which the user has already consented to the application), the application will not prompt for consenting.
Certain delegated permissions and app-only permissions always require a tenant administrator’s consent. If your application requests an app-only permission and a user tries to sign into the application, then an error message will be displayed saying the user isn’t able to consent.
If the application uses permissions that require admin consent, then there is a requirement for an option such as a button or link where the admin can initiate the action. The request your application sends for this action is a usual OAuth2/OpenID Connect authorization request, but that also includes the â€˜prompt=admin_consent’ query string parameter. Once the admin has consented and the service principal is created in the customer’s tenant, subsequent sign-in requests do not need the â€˜prompt=admin_consent’ parameter.
To implement Azure AD authentication using native apps, the apps need to be registered as Native (Application Development type) in the Azure AD app registration. All apps registered as Native app in Azure AD function as multi-tenant, so there is no need to make changes to multi-tenant features (such as web app/API). If it’s required to enable multi-tenant in your Azure AD then â€˜common‘ is used as the tenant ID or your application tenant ID can be used.
What claims are required or provided?
When authentication is desired through Azure AD, the following claims are required to validate the user’s authenticity:
- Access token: An access token ensures the user is authenticated through the Azure AD. Whenever a user wants to access the resources from the Azure AD, they need to send this token for authorization of the request.
- User info: A user info claim provides complete details about the user, like their name and User ID, etc.
- Expires on: This validates the time limit of the claims, mainly in cases when it is used with the access token provided by Azure AD.
Claims can be edited through the available options in the manifest of the app. For the application shown in the below snippet, the â€˜GroupMembershipClaims’ is set as â€œAllâ€. The claims can be modified in the manifest section as per your use.
Multi-tenant authentication without adding guest users
After implementing multi-tenant authentication with Azure AD, it is typically not verified whether the application is adding guest users to the application tenant. When an application is first created, it adds many read/write permissions to the app whenever a user/admin consent pops up and the user gets added as a guest user to the AD. This increases the users’ list. As users are already present in another Azure AD, adding them as guest users from another tenant AD is redundant. This case can be rectified by setting the required permission as ‘Sign in and read user profile’.
Azure active directory multi-tenant authentication is useful for enabling a single sign-on feature for your application which allows for better authentication and viability to the entire work function. If you are looking for development assistance for Azure AD or your Azure applications, contact us today.