This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses the identity and group management considerations for multitenant solutions.

A multitenant application does not control how many tenants or the direct ownership of a resource to its tenant. The customer has the complete say in this. They may want to reassign a resource to another tenant. For example, if they decide to join a machine to a different tenant, they need to disconnect from the first tenant and then register again with the new tenant.  The single sign-on (SSO) option for password hash synchronization and pass-through authentication can be used with only one Azure AD tenant.

When resource and users proliferate, groups come in handy to organize them and manage actions against many users. The Azure AD can use groups to assign access to a SaaS application that’s integrated with AD. A security group can be used to secure access to a resource. Members can be added or removed from the security group without changing the security model of the resource access control. This capability can be added to hundreds of resources across the application.

The role assignment for a group can be done directly with the Azure AD admin center and this can be added from the application gallery. Users and groups can be selected and then users can be added to a role. The users or groups can be assigned to the multitenant application or a resource within the application. Both app and resource access can be managed this way.

Azure AD gives access to the organization’s resources by providing access rights to a single user or an entire Azure AD group. Nested groups and users can inherit permissions which saves the effort of adding permissions one by one. There are four ways of assigning access rights and permissions. Rights can be directly accessed assigned to the user. They can be assigned to a group instead. There can be assignment based on rules where the rule defines how users are assigned to resources. Access can be granted from an external source such as an on-premise directory or the multitenant application.

 A resource owner creates a group and assigns the group to the resource. The group owner assigns users to the group who become members of the group and gain access to the resource. The group owner can let the users find their groups to join, instead of assigning them. The owner can also setup the group to automatically accept all users that join to or require approval. When a user requests to join a group, the request is forwarded to a group owner. If it is required, the owner can approve the request and the user can be notified but if there are multiple owners and one of them disapproves, the user is notified but isn’t added to the group. Automatic approval eliminates the onus on the group owner.sw

Azure resources are deployed and managed through a hierarchy. Most resources are deployed into resource groups which are contained in subscriptions. This hierarchy pertains to a tenant. When we deploy the resources, we have the option to isolate them at different levels. Different models can be used in different components of the same solution.  Groups can be used to secure the appropriate level.

Reference: Multitenancy: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=fBoKcN