Open-source multitenant solution 

This part of the book focuses on open-source for multitenant solution providers. Multitenancy goes deep to all levels of the infrastructure: front-end, middle-tier and backend. It might be easier to implement it in open source if we visualize it in two layers – the data plane layer and the application plane. 

The Data plane layer is all about data at rest and transit. Often, this involves partitioning on the data layer with separate partitions, tables, columns, identifiers and labels on the data storage schema and topics such as in Kafka, tags, domains and other data. 

The control plane layer is about context and access over the data and resources and primarily deals with organization, namespace and metadata. It secures and maps the users to the tenants via the Authorization component that can include an external Identity provider or an IAM solution. Many open-source infrastructures provide abilities to delegate IAM access to others. 

An authorization layer alone can convert a single tenant application into a multi-tenant solution where only the accesses are separated over the infrastructure as a whole taken as a resource. This works like an upgrade to the original infrastructure. The right policy model can simplify this transition even better. Policies can include role-based access control with tenant management, relationship based access control over a hierarchy where tenants become root-level relationship or attributes based access control with tenancy as an attribute. While role-based access control is the default policy model sought widely, relationship-based access control can help describe complex relationships between resources in a system. This approach facilitates a “policy-as-a-data” realm as opposed to “policy-as-a-code” realm. The policy is split between declarative rules and logic and can be visualized using a relationship graph and a hierarchical structure for assets such as folders and documents. Hierarchy can help with inheritance.

Attribute based access control emphasizes the use of attributes associated with the subject, the resource or the environment to determine whether access is granted or not. This results in a fine grained authorization model and when these attributes have dynamic values, there is a lot of flexibility achieved. Databases implement row-level security so this has some precedence. Authorization models can also be combined. 

Multi-tenant authorization does not need to be implemented from scratch. Often there is an existing library, product or solution that can be integrated into the Software-as-a-service. If it must be implemented, there are multiple options. Open Policy Agent (OPA) can be leveraged as an authorization microservice. Open Policy Administration Layer (OPAL) enables one to manage the authorization layer at scale, using PubSub topics and json data. Solutions like Permit.IO provide a way to integrate seamlessly for tenants. 

 

 

Convention_vs_Guidance – an example.

A multitenant solution provider for service deployment orchestration has a syntax for describing the stages of buildout. The sample for this looks something like this:

---

name: SERVICE1

service_identifier: abcdefgh-ijkl-mnop-qrst-uvwxyz012345

owner: Service1_Team

buildout_stages:

  newcloud.provisioning:

    - service1_newcloud_rt

  newcloud.prebootstrap:

    - service1_resources

  newcloud.bootstrap:

    - service1_pfdeploy

  newcloud.postbootstrap:

  newcloud.predeploy:

    - service1_newregion_rt

  newcloud.deploy:

    - service1_newregion

  newcloud.postdeploy:

    - service1_telemetry

    - send_service1_newcloud_signal

resources:

  service1_newcloud_rt:

    description:

  service1_pfdeploy:

    description:

  service1_resources:

    description:

  service1_newregion_rt:

    description:

  service1_newregion:

    description:

  service1_telemetry:

     description:

  send_service1_newcloud_signal:

     description:

 

The question is whether the stages can be mandated from the tenants for the deployment of their services, or should this just be a sample?

The answer is not that simple. If it were an enforcement, it might interfere with the organization that the services might want to keep. It is also inefficient if most of the stages are required but cannot be filled. The only drawback is if there is no convention, there is no consistency between service deployment artifacts. The other approach is to publish it as a guidance which is less restrictive and more prescriptive. The drawback for this approach is that all the benefits of publishing go away. The answer lies somewhere in between or dependent on the case.

 This article draws parallels to Microsoft 365 for enterprise tenants which include tenant models, optimal networking, identity, migration and device and app management. 

When we refer to a tenant, we refer to it by the tenant ID, but it is also possible to refer to them by the host names for the tenants in the deployment. A tenant specific sub-domain is set up in this case. The tenant host name, mytenant.myservice.com must be specified as an alternative in the tenant configuration.  The URL can specify the tenant ID and the tenant host name if we specify the host names as alternative IDs for tenants.   

Optimal networking involves optimizing the path between the on-premises users, and the closest location to the Microsoft Global Network, optimizing the access for remote users over VPN, using network insights to design the network perimeter for the office locations, optimizing access to specific assets hosted on SharePoint sites with the office 365 CDN, configure proxy and network edge devices to bypass processing for Microsoft 365 trusted traffic using an allowed list of endpoints.  

Optimal networking is only the first step in tenant management.  Identity Management is the next step.  

Identity infrastructure must be configured correctly, which is vital to managing the Microsoft 365 user access and permissions for an organization.   

There are two types of identity models which are Cloud only model and Hybrid model. User accounts only exist in the Azure AD tenant for the Microsoft 365 tenant in a cloud-only model.  Hybrid accounts have user accounts both in the on-premises Active Directory domain services as well as in the Azure AD tenant.  

The hybrid identity model and directory synchronization are the most common choice for enterprise customers who are adopting Microsoft 365. There are two types of authentications when using the hybrid identity model – the managed authentication and the federated authentication.  

In the managed authentication case, Azure AD handles the authentication process by using a locally stored hashed version of the password or sends the credentials to the on-premises Active Directory Domain Services.  In the federated authentication case, Azure AD redirects the client computer requesting authentication to another identity provider.  

 

Strong sign-in is another requirement for multitenant applications. This is enforced by capabilities such as Windows Hello for Business which replaces passwords with strong two-factor authentication, Azure AD Password protection which detects and blocks known weak passwords and their variants, MFA which requires user sign-ins to be subject to another verification beyond the user account password, identity and device access configurations such as the settings and policies that include conditional access, Intune, and Azure AD identity protection policies which protect against credential compromise. 

Determining which identity model to use and how to enforce strong user and device access is critical to the identity management for tenants. Besides that, only ongoing maintenance might be required for adding or modifying user accounts and groups, and adding or modifying identity and device access configuration to enforce sign-in security requirements. 

Enterprises can manage devices and the apps used on those devices with the help of Microsoft 365 Mobile Device Management and Mobile Application Management. There are two options for device management which include Microsoft Intune, which is a comprehensive device and app management solution for enterprises and Basic mobility and security which is a subset of Intune services. Intune helps with both MDM or MAM. MDM is used when users enroll their device into Intune. After a device is enrolled, it is a managed device and can receive organization’s policies, rules and settings. MAM helps to protect the organizational applications and their data by isolating it from the personal profile for the user on their devices and requiring strong sign-ins. A set of configurations is still required above MDM and MAM to ensure a secure and productive workforce and this includes Azure AD Conditional access policies, Microsoft Intune device compliance and app protection policies, and Azure AD Identity Protection user risk policies and additional policies of cloud applications. As with identity management, device and app management also involves maintenance to manage device enrollment, and revisions to settings and policies for additional applications, devices and security requirements. 

 

The following section continues to describe the tenant management of enterprise tenants with example of Microsoft 365.

Optimal networking involves optimizing the path between the on-premises users, and the closest location to the Microsoft Global Network, optimizing the access for remote users over VPN, using network insights to design the network perimeter for the office locations, optimizing access to specific assets hosted on SharePoint sites with the office 365 CDN, configure proxy and network edge devices to bypass processing for Microsoft 365 trusted traffic using an allowed list of endpoints.

Network design tries to minimize latency by reducing round trip time between clients and network. Some networks such as the Azure Backbone network offer much lower latencies than the public internet. When the Frontdoors are placed on the internet and the tenant is placed in the Microsoft Global Network, the path and the access are optimized. Routing over the network must also be followed up with proper identification of Microsoft 365 network traffic, allowing local egress of that traffic to the internet from each location, bypassing proxies and packet inspection devices for that traffic and avoiding network hairpins.

As with all networks, some maintenance is required for optimal networking on an ongoing basis. These might include updating edge devices and deployed PAC files for changes in endpoints or verifying that the automated process works correctly, managing assets in the CDN and updating the split configuration in the VPN clients for changes in the endpoints.

Optimal networking is only the first step in tenant management.  Identity Management is the next step.

Identity infrastructure must be configured correctly, which is vital to managing the Microsoft 365 user access and permissions for an organization.

There are two types of identity models which are Cloud only model and Hybrid model. User accounts only exist in the Azure AD tenant for the Microsoft 365 tenant in a cloud-only model.  Hybrid accounts have user accounts both in the on-premises Active Directory domain services as well as in the Azure AD tenant.

The hybrid identity model and directory synchronization are the most common choice for enterprise customers who are adopting Microsoft 365. There are two types of authentications when using the hybrid identity model – the managed authentication and the federated authentication.

In the managed authentication case, Azure AD handles the authentication process by using a locally stored hashed version of the password or sends the credentials to the on-premises Active Directory Domain Services.  In the federated authentication case, Azure AD redirects the client computer requesting authentication to another identity provider.

 

A multitenant solution provider facilitates service deployments in a new cloud for tenants. This provider creates tenant certificates and provides templates for services to create their service identities. These service identities include both the managed service identity as well as service accounts. The difference between the two is in the usage where the former is system defined and automatically maintained and the latter is an exclusive credential for the service. Also, Managed Service Identity is specific to Azure Active Directory while a service account can exist in any Active Directory domain, both on-premises and in Azure.

When we refer to a tenant, we refer to it by the tenant ID, but it is also possible to refer to them by the host names for the tenants in the deployment. A tenant specific sub-domain is set up in this case. The tenant host name, mytenant.myservice.com must be specified as an alternative in the tenant configuration.  The URL can specify the tenant ID and the tenant host name if we specify the host names as alternative IDs for tenants.

Migrating certificates is easy but migrating tenant identities is not. Even though the certificates change when they have different subject names that include different domains, it is easy to create those identities in either the source or the destination clouds because they request an external certificate authority to issue it. And once issued for a specific domain, they can be added to the concerned domain wherever it is.

New clouds provide a new challenge in that the migration is not between tenants in the same solution, but the tenant identities are migrated from one cloud instance to another. Therefore, there is a source and destination instance and artifacts for a tenant that existed in one instance must have a corresponding artifact in the destination.

As with any migration, there are four phases:

A.      These include phase 1 – discover and scope, phase 2 – classify and plan, phase 3 – plan migration and testing, and phase 4 – manage and gain insight.

B.      The first phase is the process of creating an inventory of all artifacts in the ecosystem. They fall into three categories those that can be migrated, not migrated, or marked for deprecation.

C.       The second phase involves detailing the artifacts within the categories with criticality, usage, and lifespan.  It prioritizes the artifacts for migration and plans a pilot.

D.      The third phase involves planning migration and testing by communicating changes and migrating artifacts and transitioning tenants.

E.       The fourth phase involves managing and gaining insight by managing end-user and admin experiences and gaining insight into artifacts and their usages.

These four phases transition the artifacts usages from old to new smoothly.

This is a continuation in a series of articles on Multitenant Applications. The previous articles talked about tenant-to-tenant migration and this article talks about tenant management in that context.

One of the first tenant decisions is how many to have. Each tenant is distinct, unique, and separate from all other tenants. A single tenant is one that has a single Azure AD tenant, with a single set of accounts, groups, and policies. Permissions and sharing of resources are facilitated by this central identity provider. Multiple tenants are created when there is administrative isolation, decentralized IT, historical decisions, mergers, acquisitions or divestitures, clear separation of branding for a parent company, pre-production, test or sandbox tenants. Some restrictions apply in providing services to users and intertenant collaboration such as a central location for files, conversations, calendars etc. must be set up for users to collaborate more effectively.

Prior to cross-tenant migration such as for mailboxes, it was required to completely offboard a user mailbox from the current tenant to on-premises and onboard them to a new tenant. Cross-tenant migration allows administrators to move artifacts such as mailboxes with minimal dependencies in their on-premises systems.

A tenant allows a central location and one or more satellite locations to facilitate data residency in specific datacenters while the tenant information is mastered centrally and synchronized into each geo-location. When a new datacenter is added to a tenant in a new geo-location, it’s possible to migrate the organization’s core customer data at rest to the new location. Opening a new datacenter does not impact existing usages of the organization’s data.

The set of products and number of licenses for each requires some planning to ensure that there are enough licenses from the users’ accounts that need advanced features and that there are sufficient licenses but not too many unassigned licenses based on staffing.

A summary of the steps for tenant management includes how many tenants are there or needed, what products or licenses must be purchased for each tenant, whether a tenant needs to be multi-geo  to comply with data requirements, whether inter-tenant collaboration must be setup, whether one-tenant must be migrated to another and whether core data from one datacenter must be moved to a new one.

 Tenant-To-Tenant Migration architecture model (continued):

This is a continuation of the previous article on Migration architecture models. Specifically, it focuses on Microsoft365 migration, tools, and migration of on-premises tenants.

The Tenant-to-Tenant migration architecture model is one of the popular ones among several architectural approaches towards tenant management. A tenant-to-tenant migration can be single-event migration, phased migration, or tenant move or split. These are also referred to as batched migration or cutover migration.

In a single event migration, everything is migrated as a single event. There is a higher risk and a shorter timeline. When there is no strict organization and users wear multiple hats or belong to multiple project teams, it becomes hard to segregate them into migration groups.  A single event can be used to migrate all and eliminate the need for coexistence considerations. The net benefit to the users is that they keep their original email address. The drawback is that automation might rely on APIs and there might be rate limits on their invocations.

Phased migration is the gradual migration of users, services, and data. With separation into multiple migration groups, there is continuity of access for users to their emails and meetings. There is lower risk and a longer timeline. The only drawback is the coexistence limitation.  Users will have an email address in a new domain and a tool might be required to do the migration.  A variety of third-party tools are available from say Consulting Services to migrate Exchange mailboxes, public folders, SharePoint sites, OneDrive folders, Office 365 groups, while users can help themselves with native capabilities from Intune and Windows 10 such as for subscription activation license. Native tools also have their place but they make calculation for Total Cost of Ownership a bit tedious.

Since the migration tasks are complex, there may be many activities occurring simultaneously such as migration of servers and other infrastructures. Coordination to minimize effort and risk and to avoid overlap is essential. Migration might not even be scheduled in certain periods. The overall picture matters more for phased migrations. This warrants the use of an overall plan where individual projects such as Exchange, SharePoint and Teams workload migrations can be managed.

Talking to users is critical towards this purpose. Certain business functions might not even be on the plan until that occurs. Even though these might be limited in number, they matter to the overall migration.

Advanced reporting tools for large and complex projects or periodic migrations can reduce stress because they anticipate common needs and have lower maintenance than custom or ad hoc reporting. Reports also help backwards in the planning process.

As with all projects of this nature, some discretion is required between balancing migration with one or the other factors. Sometimes, a single tool helps better than having teams onboard on multiple native tools.

Migration tools like BitTitan MigrationWiz for migrating Microsoft 365, Exchange and G Suite as well as Fast Cloud File migrations for SharePoint Data are also well-known. Mover.IO is a free migration manager from Microsoft for work or school. These tools work very well for hybrid environment and tenants. When doing the migration directly, it might be better to 1) recreate the teams’ structure by adding users and permissions at the target tenant, 2) migrate content from the associated SharePoint Sites and upload to the target tenant, and 3. Export data from the Exchange mailboxes and import it into the destination. A back-of-the-envelope calculation of the time and cost would be helpful to this case.