Skip to content
Platform Strategy

Identity and Access Management Multi-Tenancy

Author(s): Sivakumar Soundarapandian

Last Reviewed: February 2024

Introduction

Multi-tenancy is a crucial architectural concept in platform design, especially in cloud computing and software as a service (SaaS) environments. It refers to the ability of a shared system or service to serve multiple, independent customers or “tenants” while isolating their data, resources and configurations from one another. This is where the pivotal role of Identity and Access Management (IAM) comes into play. IAM stands as the linchpin in orchestrating secure and controlled interactions through authentication, authorization, and user privilege management.

The current state of multi-tenancy within TID poses challenges in managing user access, password policies, and data ownership across various Trimble applications. This paper addresses the existing situation, proposes solutions, and evaluates the pros and cons of different approaches.

Current Situation

TID’s multi-tenancy revolves around individual users. Grouping of authentication subjects such as User and Device with a Tenant entity is primarily managed at the application level. The Tenant plays a crucial role not only in Identity and Access Management but also in terms of data ownership. Presently, these relationships are maintained independently by individual applications. Consequently, despite having a single sign-on through TID, users lack a shared context as they transition from one Trimble application to another, leading to a fragmented and less cohesive user experience. The current situation also leads to challenges in accommodating enterprise-level requirements, including implementing robust password policies and effectively managing user access.

Path Forward

                     +-------------------+     +-------------------+
                     |     Accounts      |     |    Organizations  |
                     +-------------------+     +-------------------+
                       |  |                        |
1. Linked to Accounts  |  |                        |
     +-----------------+  +------------------------+
     |                    |
     v                    |
+-------------+           | 2. Linked to Accounts
|   Identity  |           | 3. May be linked to Organizations
+-------------+           |
                          v
                +-------------------+
                | Password Policy   |
                +-------------------+




        +-------------------+
        |   Identity Server |
        +-------------------+
                    |
                    | 1. Authenticates Identities
                    | 2. Issues JWT tokens
                    |
                    v
            +-------------------+
            |    Application    |
            +-------------------+


                        3. Uses JWT for authentication
                        4. Applies authorization policy based on
                        Account

Identity - An Identity is a User, Device or Application authenticated by Trimble Identity. Every Identity MUST be linked to at least one Account.

Account - An Account represents a billing container of Entitlements. Account also holds the preference for data residency and sovereignty. Accounts hold Identities through “primary” and “guest” relationships.

Organization (aka “Tenants”) - An Organization represents a Customer. An Organization MAY be linked to zero or more Accounts. An Account may be linked to zero or one Organization.

BusinessAccount - A BusinessAccount is any Account linked to one Organization.

IndividualAccount - An IndividualAccount is any Account not linked to an Organization

PasswordPolicies

  • A PasswordPolicy represents a description of allowed password schemes and constraints for authentication for Identity in Trimble Identity.
  • A PasswordPolicy may be linked to one or more Accounts. An Account must have exactly one PasswordPolicy.
  • A PasswordPolicy may be linked to one or more Organizations. An Organization must have exactly one PasswordPolicy.
  • When an Identity has multiple PasswordPolicy through different Accounts, the PasswordPolicy with highest complexity across all the PasswordPolicy will be used.

JWT

  • JWT, or JSON Web Token, is a compact, self-contained mechanism for transmitting authentication and authorization data between the Identity Server and Application.
  • JWT will include an Account claim that passes the Account the authentication subject is linked to.

Here is a high level flow:

  1. The Identity Server authenticates various types of Identities (Users, Devices, Applications). It issues JWT tokens containing a claim of the default Account the subject is linked to.
  2. Applications use these JWT tokens for authentication purposes.
  3. Applications authorize access to the resource based on the authenticated subject and the Account.

Multiple Account handling

  • If the authentication subject is linked to more than Account, it can be handled through an Account selection screen at TID login or by selecting a default Account from the user profile.
  • In case of multiple accounts, the account can be switched through a switch account from User profile.
  • For non-interactive login from Devices/Applications, the default Account will be used. Administrators can change the default Account.

Alignment question: Should users select their account context on every login, or choose a default account through the User Profile?

Account Invitation and Organization Administration

Organizational administration must be seamlessly integrated within the platform, triggering an intuitive workflow streamlining user onboarding and access provisioning. Account experience should include workflows for the process of inviting users or including authentication subjects to be a part of the account and inviting accounts to be a part of an Organization. This ensures a cohesive experience where administrators can efficiently oversee account management tasks while maintaining control over security, data privacy and location preferences.

Conclusion

The solution’s aim is to enhance multi-tenancy within TID, addressing the current challenges and providing a foundation for robust Identity Access Management. Further collaboration and exploration are necessary to elaborate on the workflow and ensure successful implementation.