The Advantages of Multitenancy in Identity as a Service (IDaaS)
If you’ve ever lived in an apartment complex, you’re familiar with multi-tenant housing: a single building containing many residents or families who live in their own separate apartments. And while you’ve probably enjoyed the cost and maintenance benefits of sharing the building with your neighbors, you probably also value the apartment walls that give you privacy and prevent you from hearing their late night parties.
You can think of multi-tenant software as a service (or identity as a service) solutions in much the same way: a single shared resource that contains multiple components, or tenants. In this case, tenants can be applications, environments, organizations or other components, and the shared resource in which they all live is the cloud. Just as with your apartment complex, you can enjoy the benefits of lower costs and easier upkeep with just one cloud resource to manage, but you also get the ability to keep things separate when they need to be.
When it comes to identity and access management, multitenancy can help you structure identities into smaller groups nested within one larger group. Instead of apartments, you have groups of identities, and instead of the apartment complex, you have a container for all your groups of identities.
The Benefits of Multitenancy
Here at Ping, we like to talk about how multitenancy within PingOne for Customers is a big benefit for our users. But why is that the case? What’s so great about multi-tenant solutions? First of all, multitenancy helps keep down the management costs associated with the solution. It allows Ping to be more efficient with the hardware resources we’re using to provide the service, and provide a better product to our customers.
The reason for this is because multiple tenants or environments that share a single resource can make more efficient use of that resource. For example, if your four separate environments each have their own resource, they each may only use a portion of their resource most of the time—say, for argument’s sake, 20%. That leaves a lot unused that you’re still paying for. If instead, we put those four environments on one cloud resource, together they take up 80%, and there’s still room for activity spikes. Now we’re only managing one hardware resource and you benefit from our efficiency. This oversimplifies things, but you get the idea.
Moving to a cloud solution that supports multitenancy also makes it easier to scale as demand requires. If there are separate resources to support each environment, there’ll probably be more management involved and more moving pieces. Management tasks might involve making decisions, configuring an entirely new resource or tearing a part out of a monolithic machine to change the size. With a shared resource, you just need to tack on something, whether that be storage, processors, memory or something else, to make it bigger, or remove a part to decrease the size. You’re virtually taking down and spinning smaller structures up within a larger structure, which is much easier on the overall system and significantly more cost efficient.
Multi-tenant solutions are particularly beneficial to those that need to combine certain benefits of having a shared resource with certain benefits of having separate environments. For example, you may need separate environments to allow you to follow region-specific data protection rules (like GDPR in the EU) in each one and prevent cross-contamination or accidental access.
In another case, you might have a situation in which you need an overview of all environments and centralized control, but still want to keep users partitioned into separate environments. Perhaps you have an admin in charge of the identity service as a whole, and she needs an overall view to help her decide when to provision new environments or adjust policies. Yet you have different engineering teams that should only have access to the environment(s) related to the product they’re working on. Again, multitenancy is the way to go, giving your admin the consolidated view she needs, while keeping environments and their users separated.
Building Multi-tenant Structures
Defining what the tenants should be for your particular case should depend on a logical hierarchy that allows users to easily manage and find things they want. You want to balance the benefits of dividing up elements into logical groups against the confusion of having too many tenants within that shared resource. One resource for one tenant doesn’t help you much, but one-to-too-many makes it hard to find anything among the multitude of tenants. A high-level, logical grouping that keeps the number of tenants reasonable and makes the components within those tenants easy to find is the best way to go.
Another great way to visualize this concept is with an ice cube tray. The shared resource is the tray, and the tenants are the individual ice cubes. You don’t want 24 separate trays to keep track of in your freezer, but one tray with 1,000 ice cubes is probably too much to manage.
With this in mind, let’s think about two examples of how you could divide up your tenants.
Development, Staging and Production Environments
One way to organize tenants is by environment, since each environment serves a particular purpose. Software developers usually use a development environment to develop features, try things out and work on code. The staging environment may be a mirror of the production environment, but it typically serves as a sandbox for testing that’s a little closer to what a live build would look like. The production environment is what’s live and in use by the company’s customers, so any changes need to be made with care. Each of these may have its own user populations, associated devices, user schemas and other details that you want to keep isolated.
Regional Tenants
Another way to organize tenants is by location. You may want to have separate logistics for different regions to support your business needs, like region-specific regulations, but still want to only manage a single resource. For example, different locations could have different data structures that will be easier to manage if kept separate. Again, with virtualized environments, they need not be separated physically on the backend to provide the required level of separation.
Why Aren’t All Cloud Solutions Multi-Tenant?
After hearing about all the benefits of multitenancy, you may be asking, “Why aren’t all software products multi-tenant?” The quick answer is: it’s hard! At a high level, multitenancy tries to accomplish two contradicting goals: keeping your environments together, while still keeping them separate.
If you try to accomplish one of these goals, you will naturally be limited by the other. If you’re storing two sets of sensitive identity data, it’s easy to set up a strong barrier between them and keep them separate in all cases. But it’s much harder to keep them separate while also making sure that it’s easy for a developer to make updates to either of the identity sets from their app’s code.
In the same way, it’s easy to give an admin a full view of everything across all environments if you don’t need to keep data separate. It’s much harder to accomplish this without leaking data across environments or across accounts. One person’s information leaking into another’s account is a much bigger deal than sound leaking from your neighbor’s party into your apartment.
Multitenancy in PingOne for Customers
PingOne for Customers is an identity as a service (IDaaS) solution that was designed with multitenancy in mind. The original hierarchy or container system was built to make sure tenants (called “environments”) are kept separate with hard virtual boundaries between them for the efficiency benefits, but still remain accessible for developers, admins and users through a single organization.
The main way PingOne for Customers keeps environments separate and secure is through our carefully designed use of roles and permissions. Roles can be scoped to a specific environment, which restricts users to only the areas they’ve been explicitly permitted to access. For example, you can grant your QA team members access to multiple applications, but restrict them from production environment applications or configuration options. You can also control what kind of actions each user has permission to perform, which may vary across environments. PingOne for Customers also encrypts data and follows the highest standards of identity security—critical when dealing with users’ sensitive personal information.
Whether you’re isolating different environments, regions, applications or user groups, PingOne for Customers will ensure that those critical barriers remain in place while still allowing you to centrally manage all environments and users from one account for your whole organization.
To try out Ping’s multi-tenant solution for yourself and see how easy managing user identities can be, try PingOne for Customers for free for 30 days.
