Application access management is an issue related to almost every system. By taking care of proper authentication, not only do we limit the possibility of obtaining or modifying sensitive data, but we also gain more flexibility in terms of the User Experience, by defining the roles or properties associated with a given user.
Building a credential management system from scratch is a very difficult task and requires a great deal of security knowledge. Fortunately, there are ready-to-use solutions available on the market, such as Azure Active Directory (AAD).
GO TO:
- 1. What is the Azure Active Directory service?
- 2. What is a multi-tenant application?
- 3. Get started with the Azure AD service
- 4. Registering a multi-tenant application
- 5. Logging into the application as an external user
- 6. Multi-tenant application calling internal APIs
- 7. Identity management – restricting access to applications
- 8. Azure AD service from Microsoft – summary
What is the Azure Active Directory service?
Azure Active Directory (AAD) is a cloud-based service from Microsoft that allows us to manage access and identities. Using this solution, we can also register our applications and define access policies – in terms of both users and other applications. A registered solution in a given tenant can be accessed by all objects (users, applications) that share it. AAD also allows us to “share” applications with other tenants, so we don’t have to worry about managing external users of our app. A solution configured this way is known as a multi-tenant application.
What is a multi-tenant application?
A multi-tenant application allows you to support multiple tenants through a single instance. In case of this solution, it is important that the client does not have access to other tenants’ data. This is most often solved through business logic or separating databases so that each client has their own.
A multi-tenant application registered in Azure Active Directory allows you to shift responsibility for user management and determining the level of access to the solution onto the shoulders of the administrator of a given tenant. This reduces the costs associated with maintaining users on the service provider’s side.
Please note, however, that the issue of access to individual application components is further addressed by developers by defining appropriate policies in the code.
Get started with the Azure AD service
Are you keen to use Azure AD? Microsoft provides administrators with the know-how materials necessary to manage services in the Azure Portal. The documentation also includes answers to FAQs. All information is available on the Microsoft Azure Active Directory page, where you can learn all about identity and access management in the cloud. If you’re not yet using Microsoft Azure services, it’s a good place to start.
Registering a multi-tenant application
When registering a new application, we are obliged to choose which type of account we want to support. By choosing the option highlighted below, we grant access to other tenants. If we are in doubt about which option to choose, there is a link below the section with a description of the particular options.
By registering an application object, we create a business application, or more precisely a service unit (Service Principal). User accesses to the application are plugged in to this service unit. Exactly the same mechanism is used for external clients.
Logging into the application as an external user
The first time we try to log in to an application, we are asked to grant permission for the application. Depending on the tenant’s settings, we will be able to grant it ourselves or it will require administrator approval.
It is worth mentioning that the administrator grants permission for all users, so only the first login to the application by any user will trigger a request for permission. With self-consent, it will be triggered individually for each user on the first login attempt.
Here’s where some of you may have concerns: by allowing access to a user’s data, are we assigning it to the provider with whom the application is registered? Rest assured, this is not quite the case. As in the case of the primary tenant, a service unit is created as a business application. Depending on the accesses set against it, our solution obtains information about the user who is currently logged in.
When DevOps or an engineer registers an application and wants to have Microsoft logins, the target application with the target accesses used for logging in will be created automatically during registration. There is no need for users to give consent for the application in this tenant.
Expert knowledge Serverless workflow orchestration – Azure Durable FunctionDiscover Azure Durable Function and its potential in serverless programming. Find out what ADF is and what benefits it brings in app development.Read the article! |
Multi-tenant application calling internal APIs
Especially with microservices, it often turns out that our application communicates with another through its API. When this happens in a service-to-service model, all we need to do is guarantee access in the provider’s tenant. The situation gets more complicated when we want the application to communicate via API on behalf of a logged-in user.
For a multi-tenant solution, we need to guarantee that the API has a representative at the tenant in the form of a service entity, which forces the public availability of the API template. This is all due to the access verification mechanism within the tenant, i.e. the user’s tenant.
Therefore, it is necessary to think carefully about the model of communication between applications.
It is important to define the web application as being authorized in the registered object of the API application – this will enable the client to allow access to the API, and thus the service entity will be registered in its tenant.
Identity management – restricting access to applications
As I have already mentioned, when a business application appears for a given tenant, every user has access to it. However, we can restrict this. If we want only specific users or a group of users to have access, we need to set our service unit to require assignment.
Then, for a user or group to have access, the application must appear in the user’s or group’s assignments.
Another way to modify access to an application is by granting conditional access, which allows you to enforce certain behaviors or block access depending on the scenarios you set. However, this option is only available in the premium tiers of service. For information on pricing plans and the available services, visit the Microsoft Azure website.
Read also: Cloud-native applications: what do you need to know?
Azure AD service from Microsoft – summary
A multi-tenant application reduces costs by sharing a single instance across multiple customers. Using Azure Active Directory to register such a solution further reduces the cost of maintaining users, as we are using those belonging to the tenant, so to speak. It is up to the tenant’s administrator who he wants to grant access to, and to what extent.
Unfortunately, we are then limited to Microsoft customers only, which may make us less competitive. If we would like to have a solution available to customers regardless of the credential provider they use, an interesting option is Azure Active Directory B2C with Single Sign-On.
Azure Active Directory streamlines access and identity management, significantly enhancing security and operational efficiency. Understanding and controlling costs is a crucial aspect of managing Azure services. For in-depth insights on optimizing cloud costs in Azure, read our guide on Azure Cost Management 101. This resource will equip you with strategies to manage your Azure investments more effectively.
GO TO:
- 1. What is the Azure Active Directory service?
- 2. What is a multi-tenant application?
- 3. Get started with the Azure AD service
- 4. Registering a multi-tenant application
- 5. Logging into the application as an external user
- 6. Multi-tenant application calling internal APIs
- 7. Identity management - restricting access to applications
- 8. Azure AD service from Microsoft – summary