Nested access rights check for multi-tenant organizations

Abstract

Techniques are provided for managing access to content, including: receiving a first signal requesting an indication of whether a user has access rights to access a resource associated with a first tenant accessing a management service, or to perform an operation using the resource through a data processing system; determining that a first user account associated with the user does not have an access right to access the resource; performing a nested access permission check to determine whether the user is associated with a second user account having access permission to access the resource; and granting access to the resource via the communication network in response to the nested access rights check determining that the user is associated with the second user account and the second user account is associated with access rights to access the resource.

Description

[0001] This application is a divisional application of the Chinese patent application with application date of October 19, 2020, application number 202080075875.1, and invention name “Nested access permission check for multi-tenant organizations”. Background Art

[0002] Managing access to software and other resources in large organizations is a complex process. Users can join and leave organizations, requiring the purchase of additional licenses or reassignment of licenses when users leave an organization. Some organizations may be divided into multiple sub-entities for which software licenses are purchased. When users from one sub-entity of an organization need to share licensed resources with users from another sub-entity of the organization, licensing constraints and other access permissions may prevent users from being able to collaborate across organizational boundaries. There are many important areas for new and approved mechanisms for handling resource access permissions in multi-tenant organizations. Summary of the invention

[0003] An example computing device according to a first aspect of the present invention includes a processor and a computer-readable medium. The computer-readable medium stores executable instructions for causing the processor to perform operations, the operations including: receiving a first signal via a communication network, the first signal requesting an indication of whether a user has access rights to access a resource associated with a first tenant of an access management service or to use the resource to perform operations through a data processing system; in response to receiving the first signal, accessing first user account data of a user stored in a memory and associated with the first tenant of the access management service, wherein the first user account data includes a linked account identifier attribute, the linked account identifier attribute including a first identifier associated with a second tenant of the access management service and a second identifier associated with second user account data of the second tenant; determining the first user account data does not include an access permission attribute that allows access to the resource; in response to determining that the first user account data does not have access permission to access the resource, performing a nested access permission check by: accessing a linked account identifier attribute of the first user account data to determine whether the user is associated with second user account data of the second tenant; when it is determined that the user is associated with the second user account data, accessing the second user account data in the second tenant of the access management service; and determining that the second user account data includes an access permission attribute that indicates that the user is allowed to access the resource; and in response to the nested access permission check determining that the user is allowed to access the resource, granting access to the resource via the communication network.

[0004] According to a second aspect of the present invention, an example method performed by a data processing system for managing access to resources managed by an access management service includes: receiving a first signal via a communication network, the first signal requesting an indication of whether a user has access rights to access resources associated with a first tenant of the access management service or to perform operations using the resource through the data processing system; in response to receiving the first signal, accessing first user account data of a user stored in a memory and associated with the first tenant of the access management service, wherein the first user account data includes a linked account identifier attribute, the linked account identifier attribute including a first identifier associated with a second tenant of the access management service and a second identifier associated with second user account data of the second tenant; and determining Determining that the first user account data does not include an access permission attribute that allows access to the resource; in response to determining that the first user account data does not have access permission to access the resource, performing a nested access permission check by: accessing a linked account identifier attribute of the first user account data to determine whether the user is associated with second user account data of the second tenant; when it is determined that the user is associated with the second user account data, accessing second user account data in the second tenant of the access management service; and determining that the second user account data includes an access permission attribute that indicates that the user is allowed to access the resource; and in response to the nested access permission check determining that the user is allowed to access the resource, granting access to the resource via the communication network.

[0005] An example memory device according to a third aspect of the present invention stores instructions that, when executed on a processor of a computing device, cause the computing device to manage access to resources managed by an access management service by: receiving a first signal via a communication network, the first signal requesting an indication of whether a user has access rights to access resources associated with a first tenant of the access management service or to perform operations using the resources through a data processing system; in response to receiving the first signal, accessing first user account data of a user stored in a memory and associated with the first tenant of the access management service, wherein the first user account data includes a linked account identifier attribute, the linked account identifier attribute including a first identifier associated with a second tenant of the access management service and second user account data associated with the second tenant associated with the resource; determining that the first user account data does not include an access permission attribute that allows access to the resource; in response to determining that the first user account data does not have access permission to access the resource, performing a nested access permission check by: accessing a linked account identifier attribute of the first user account data to determine whether the user is associated with the second user account data of the second tenant; upon determining that the user is associated with the second user account data, accessing the second user account data in the second tenant of the access management service; and determining that the second user account data includes an access permission attribute that indicates that the user is allowed to access the resource; and in response to the nested access permission check determining that the user is allowed to access the resource, granting access to the resource via the communication network.

[0006] This summary is provided to introduce some concepts in a simplified form, which are further described in the detailed description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The accompanying drawings depict one or more embodiments according to the present teachings only as examples and not by way of limitation. In the drawings, the same reference numerals refer to the same or similar elements. In addition, it should be understood that the accompanying drawings are not necessarily drawn to scale.

[0008] Figure 1 An example operating environment is presented in which techniques for performing nested license checks may be implemented;

[0009] Figure 2 is a diagram illustrating an example of assigning software licenses to users of a multi-tenant organization.

[0010] Figure 3is a diagram illustrating an example of a user attempting to access content across tenants within an organization;

[0011] Figure 4 is a diagram illustrating another example of a user attempting to access content across tenants within an organization;

[0012] Figure 5 is a diagram illustrating another example of a user attempting to access content across tenants within an organization;

[0013] Figure 6 is a diagram illustrating an example of a user attempting to access content across tenants and across organizations;

[0014] Figure 7 is a block diagram of an example implementation of an access management service;

[0015] Figure 8 is an example procedure for performing nested access rights checks;

[0016] Fig. 9 is a block diagram illustrating an example software architecture, portions of which may be used in conjunction with the various hardware architectures described herein, which may implement any of the features described herein;

[0017] Fig.10 is a block diagram illustrating components of an example machine configured to read instructions from a machine-readable medium and perform any of the features described herein; and

[0018] Fig.11 is a block diagram illustrating an example of user account data. DETAILED DESCRIPTION

[0019] In the following detailed description, numerous specific details are set forth by way of example in order to provide a thorough understanding of the relevant teachings. However, it should be apparent that the present teachings can be practiced without these details. In other cases, well-known methods, processes, components and / or circuits have been described at a relatively high level (without details) to avoid unnecessarily obscuring aspects of the present teachings.

[0020] Provided are techniques for managing access to resources in a multi-tenant environment managed by an access management service. The access management service provides an organization (e.g., a company, university, government agency, or other entity) with a means for managing user access to resources associated with the access management service. These resources may include resources within the organization, such as internal applications developed for use within the organization, intranet sites, and / or other resources that users within the organization can access. Resources managed by the access management service may include external resources, such as cloud-based software applications and other external resources that users of the organization may be allowed to access. The access management service may be divided into logical "tenants" of the access management service, each with its own set of user accounts, resources, licenses, and policies associated with it. Each tenant is managed by the access management service as a separate entity, and ideally, each organization will be associated with a single tenant in the organization, where all users associated with the organization will be included in the single tenant. This single-tenant approach for each organization will make collaboration between users of the organization much simpler, because all resources of the organization will be organized into a single tenant on the access management service. However, in reality many organizations have multiple departments or other sub-entities, and each department or other sub-entity may have its own tenant in the access management service for a variety of reasons discussed in the following examples. This can make it difficult for users whose user accounts reside in different tenants to collaborate with each other, because access to software and other resources is typically limited to users who have user accounts within the tenant.

[0021] One approach to addressing these issues is to establish multiple accounts for users in multiple tenants associated with an organization to allow users to access resources residing in different tenants associated with the organization. A user may have a primary user account in the tenant to which the user is primarily affiliated. For example, a user's primary user account may be established in a tenant associated with a department of an organization for which the user is an employee. A user may also have one or more "shadow" accounts established in other tenants of the organization. Shadow accounts allow users to authenticate through other tenants and access resources therein. However, this approach presents significant technical issues for organization administrators, who must manage multiple accounts for users. Large organizations may contain thousands of users and different resources in each tenant. Thousands of shadow accounts may be required to represent users in other tenants associated with the same organization to allow users to access resources belonging to those other tenants.

[0022] The authentication and overhead associated with maintaining a large number of shadow accounts are just technical issues that arise in multi-tenant organizations. Other important technical issues are management of software licenses and other such access rights that allow users to access resources (e.g., software applications) associated with a specific tenant. In traditional multi-tenant configurations of access management services, software licenses and / or other such access rights to access resources are usually limited to a single tenant. Therefore, a user may need multiple copies of the same software license or other access rights to be assigned to each shadow account across multiple tenants so that the user can use the resource across multiple tenants. This presents a significant technical problem for administrators of such multi-tenant organizations because of the significant overhead of managing multiple licenses and / or access rights for users across each tenant. In addition, the cost of obtaining multiple licenses for the same user may be quite high, and administrators may need to try to obtain discounts or free licenses or other access rights from software providers to avoid having to pay for multiple licenses or other access rights for the same resource for each user. The technology disclosed herein provides a technical solution to these and other technical problems faced by administrators in multi-tenant organizations by providing a nested license check that can access user accounts linked or mapped together across tenants. The nested access rights check can check each user account in multiple tenants within the same organization to determine whether the user has a valid license to access a resource or other access rights associated with at least one of the user's user accounts. If a valid license or other access rights to access the requested resource is found to be associated with at least one of the user accounts of the user within multiple tenants of the organization, the user will be granted access to the requested resource. This approach provides a technical solution that can significantly reduce or eliminate the need to maintain multiple copies of software licenses and / or other access rights for the same user in an organization. The technical solution can greatly simplify the maintenance of user accounts and reduce operating costs by eliminating unnecessary duplicate copies of software licenses required in traditional access management services.

[0023] Figure 1 An example operating environment 100 is presented in which techniques for performing nested access permission checks can be performed. The operating environment includes an access management service 135, a first cloud-based software as a service (SaaS) provider 130a, a second SaaS provider 130b, a first organization 105, and a second organization 115.

[0024] The access management service 135 is a cloud-based access management service that can provide a means for managing the access of the organization's users to various resources, including internal and external resources. External resources may include SaaS applications that are not provided by the organization. Internal resources may include applications on the organization's network and intranet and cloud-based applications developed by the organization. In some embodiments, the access management service 135 can be implemented by Microsoft Azure Active Directory (AzureAD), and in other embodiments, other access management services can be used to implement the access management service 135.

[0025] The access management service 135 may also provide identity management services for verifying the identity of a user. For example, the first SaaS provider 130a and / or the second SaaS provider 130b may outsource authentication to the access management service 135. The SaaS providers 130a and 130b may register with the access management service 135, and the access management service 135 may be configured to register each application provided by the SaaS providers 130a and 130b in a "directory" maintained by the access management service 135 for each "tenant" of the access management service 135. The directory may include information identifying users, user groups, and applications associated with tenants. A tenant may be an organization or a sub-entity of an organization, as will be further discussed in the following examples. The access management service 135 may be configured to support various authentication protocols, such as, but not limited to, OAuth 2.0, OpenID Connect, WS-Federation, and SAML 2.0. The specific flow of requests and responses passed between the access management service 135 will depend on the authentication protocol selected when registering the application with the access management service 135.

[0026] The access management service 135 may also be configured to allow an administrator to define a set of access permissions associated with each user account of the tenant. The access permissions may be used by the access management service 135 to determine whether a particular user is allowed to access resources managed by the access management service 135. The resources managed by the access management service 135 may include licensed software, and the access permissions may include a software license that allows a user to access a software application associated with a particular license. Software licenses may be assigned to specific user accounts and / or may be assigned to user groups ("group licenses") that may access the software associated with the license using licenses from a pool of licenses assigned to the group.

[0027] The first and second SaaS providers 130a and 130b provide cloud-based software services, where the software is delivered online rather than installed on individual computers. The first and second SaaS providers 130a and 130b can provide various applications and services online. Access to the software provided by the first and second SaaS providers can be a subscription-based service, where a user purchases a license to use one or more software products provided by each SaaS provider. The first and second SaaS providers 130a and 130b can be configured to perform license management using an access management service 135, where the first and second SaaS providers 130a and 130b rely on the access management service 135 to verify whether the user has a valid license to access the software provided by the first and second SaaS providers 130a and 130b. The first and second SaaS providers 130a and 130b can provide various types of software, such as document editors, spreadsheet editors, photo editors, and / or other software products that can be used as cloud-based software. Examples of such applications and services may include, but are not limited to, Microsoft Office 365 and Microsoft Azure.

[0028] The access management service 135, the first and second SaaS providers 130a and 130b, the first organization 105 and the second organization 115 may communicate over a network. The network may include one or more public and / or private networks and may include at least a portion of the Internet.

[0029] Figure 1 Two example organizations are included to illustrate the concepts of managing access permissions in a multi-tenant environment disclosed herein. The specific structure and organization of these example multi-tenant organizations are by no means limiting.

[0030] The access management service 135 may be configured to support one or more logical domains referred to as "tenants". Each tenant may be associated with one or more user accounts, and a user may have accounts in more than one tenant. Each user may be associated with access permissions that define which resources the user may access within and outside the tenant. As discussed in the following examples, the access permissions associated with a user account may include one or more software licenses that allow the user associated with the user account to access specific software applications.

[0031] In multi-departmental organizations (e.g. Figure 1The first organization 105 and the second organization 115 shown may establish each department as a separate tenant on the access management service 135. Organizations with more than one tenant on the access management service 135 may result from mergers and acquisitions. An organization that was already a tenant of the access management service 135 acquires another organization that was also already a tenant of the access management service 135, resulting in the organization having multiple tenants in the access management service 135. A multi-tenant configuration within an organization may also be the result of different business units of an organization each migrating to a cloud-based software solution separately rather than migrating the entire organization. Each business unit then becomes a separate tenant on the access management service 135. As will be discussed in the following examples, this multi-tenant configuration with an organization may make collaboration of tenants across the multi-tenant organization cumbersome.

[0032] In this example, the first organization 105 is a company, also referred to herein as "Company A". The first organization 105 includes a first department with a first tenant 110a having an access management service 135 and a second department with a second tenant 110b. The first tenant 110a includes a first user account 111 of user A, a second user account 112 of user B, and a guest account 113. The first user account 111 and the second user account 112 are member accounts that have the ability to create content in the tenant and invite other users to collaborate on the content. The guest account 113 has more limited access to the tenant's resources and may not be allowed to create new content and may not be allowed to invite other users to collaborate on the content.

[0033] The first user account 111 (user A) and the second user account 112 (user B) can each be assigned one or more access rights. The access rights can be used by the access management service 135 to determine whether user A and user B are allowed to access resources managed by the access management service 135. The access rights can be related to external and / or internal resources. External resources can include resources provided from outside the organization, such as SaaS applications provided by the first and second SaaS providers 130a and 130b. Internal resources can include resources provided from within the organization, such as applications provided on the organization's internal network or intranet and cloud-based applications developed by the organization.

[0034] Access rights may include a software license that allows a user to access a software application. Figure 1In the example shown, the access rights associated with the user may include licenses for other software applications of the first SaaS provider 130a, the second SaaS provider 130b, and / or other software providers. The second tenant 110b of the first organization 105 includes a first user account 114 of user C, a second user account of user D, and a guest account 116. The first user account 114 (user C) and the second user account (user D) may both be assigned one or more access rights. These access rights may include software licenses, such as licenses for applications provided by the first SaaS provider 130a, the second SaaS provider 130b, and / or software providers. The guest account 113 may be associated with a pool of software licenses that may be assigned to guest users of the first tenant 110a of the first organization 105, and the guest account 116 may be associated with a pool of software licenses that may be assigned to guest users of the second tenant 110b of the first organization 105.

[0035] The second organization 115 is a company referred to as "Company B" in this example. The second organization 115 includes a first department having a first tenant 120a and a second department having a second tenant 120b on the access management service 135. The first tenant 120a includes a first user account 121 of user E, a second user account 122 of user F, and a guest account 123. The second tenant 120b includes a first user account 124 of user G, a second user account 125 of user H, and a guest account 126. The user accounts 121, 122, 124, and 125 are member accounts. Each of the user accounts and the guest account can be associated with one or more access rights, which can include one or more software licenses.

[0036] The example organizations 105 and 115 shown in this example each have two departments. However, other organizations may have more than two departments, and users from a first department may wish to collaborate with users from more than one other department. These examples and subsequent examples are by no means limiting and are intended to illustrate examples of how nested access rights checks may be implemented by the access management service 135.

[0037] Figure 2 An example of access rights that have been assigned to users of a multi-tenant organization is shown. Figure 2 Shown from Figure 1 FIG. 105 shows a diagram of a first organization 105 in which access rights have been assigned to each user account. In this example, a user account may be assigned access rights that allow a user associated with the user account to access one or more of software products A, B, C, and D. The access rights may include software licenses for software products A, B, C, and D (if licenses are required for these software products). Figure 2In the example shown, user account 111 of user A has been assigned access rights 201 to product A and access rights 202 to product B. User account 112 of user B has been assigned access rights 203 to product A and access rights 204 to product B. User account 114 of user C has been assigned access rights 211 to product A and access rights 212 to product C. User account 114 of user D has been assigned access rights 213 to product A and access rights 214 to product D. The following examples will illustrate some of the challenges that may arise when a user associated with one tenant attempts to collaborate with a user associated with a different tenant and / or a user attempts to access resources associated with a different tenant or perform operations through a data processing system using resources or applications associated with a different tenant.

[0038] Figure 3 An example is shown in which user C from a second tenant 110b of an organization 105 invites user A from a first tenant 110a of the organization to collaborate on a project. However, user A and user C are in different departments, each of which is associated with their own respective tenant of the access management service 135. This can present challenges from an authentication perspective and a licensing perspective. If the user has a user account and can authenticate with the access management service, the user can only gain access to content associated with the tenant of the access management service 135.

[0039] To allow a user to access content in another tenant of the organization (which is not the user's home tenant), an administrator can provision a user account in another tenant. Figure 3 In the example shown, a duplicate user account 301 (also referred to as a "shadow account") may be created for user A in the second tenant 110b. The duplicate user account 301 allows user A to be authenticated and access content in the second tenant 110b. The duplicate user account 301 may be mapped or linked to user account 111 of user A in the first tenant 110a. The access management service may be configured to allow user A to be authenticated based on user profile information associated with user account 111 when user A attempts to access content in a tenant associated with the organization's second tenant 110b. This solution overcomes the access challenges of having users in an organization distributed across multiple tenants, but may present other significant difficulties for administrators with respect to resource permissions.

[0040] Fig.11An example of user account data representing a user account 111 and a shadow account 301 of user A is shown. User account data and other resources associated with a tenant may be stored by the access management service 135 in different directory structures that are isolated from each other so that resources maintained in one tenant cannot be directly accessed in another tenant. The user account data may include an object identifier, which is a unique identifier used by the access management service 135 to reference the user account data associated with an account. The user account data may also include a tenant identifier, which is a unique identifier used by the access management service 135 to identify the tenant associated with the user account data. The user account data may include additional information, such as a user name that the user may use for authentication purposes and that may be used by other users to identify a particular user. A username is a human-readable identifier that may be used to refer to a user within an application and / or service managed by the access management service 135. In some embodiments, a username may be an email address or other alias for a user. The user account data may also include the name of the user. The user account data may also include one or more roles associated with the user, such as, but not limited to, member, administrator, or guest, and each role may have one or more associated access rights. The user account data may also include authentication credentials that may be used to authenticate the user for access to the tenant and resources managed by the tenant. The authentication credentials may include a username and password, biometric information, and / or other authentication credentials that may be used to identify the user to the access management service 135. The shadow account 301 may not be associated with authentication credentials, and the access management service 135 may be configured to access the user account data identified in the linked account identifier attribute to determine which authentication credentials should be used to authenticate the user when the user accesses the shadow account 301.

[0041] User account data may include an alternate security identifier (“AltSecID”) attribute (also referred to herein as a “linked account identifier”) that may be set by access management service 135 when a shadow account is created that links the shadow account user account data to user account data in another tenant managed by access management service 135. Fig.11 An example of how a link 302 between a shadow account 301 and a user account 111 may be implemented is shown. The linked account identifier includes two pieces of information: an identifier of the tenant in which the linked user account data is located, and an identifier of the user account data within the tenant. Fig.11In the example shown, the linked account identifier of shadow account 301 includes: an identifier of first tenant 110a, which is "128765554"; and an identifier of user account data associated with user account 111 in first tenant 110a, which is "190112124575933". Access management service 135 can use this information to look up user account data associated with shadow account 301 in tenant 110a.

[0042] When creating a shadow account in a first tenant for a user who has a user account in a second tenant, the access management service 135 can set the AltSecID attribute of the shadow account to include the tenant identifier of the second tenant and the unique user identifier assigned to the user account data of the user in the second tenant. When performing a nested license check on the shadow account, the access management service 135 can identify that the shadow account is a shadow account in response to the AltSecID attribute being set. The access management service 135 can use the tenant identifier and the unique identifier assigned to the user account to access the user account data in the second tenant's principal. Once the user account data is already in the second tenant, the access management service 135 can determine whether the user account data is associated with any access rights attributes, which can include permission information for resources that the user is allowed to access. The access management service 135 can optionally determine whether the first and second tenants are part of the same organization. The access management service 135 can determine whether the first tenant and the second tenant are part of the same organization based on tenant attribute information stored in the corresponding directory of each tenant.

[0043] In some implementations, the creation of a user's shadow account can be automated by the access management service 135 for cross-tenant access within the same organization. Figure 3 In the example shown, user C may send an invitation to user A via email or via other means that provides user A with a link to access resources in the second tenant 110b. In some embodiments, in response to the access management service 135 determining that the invited user does not have a user account in the second tenant 110b to which user C belongs, user C may be presented with the option of creating a user account for user A (or any other user invited to collaborate with user C) in the second tenant 110b. User C may specify an email address, alias, or other identifier for user A, and the access management service 135 may use the email address, alias, or other identifier to look up user A in a directory of tenants associated with the second tenant 110b. In response to determining that user A does not have a user account in the second tenant 110b of the organization 105, the access management service 135 may search for user A in the access management service 135's directory of tenants associated with the same organization (e.g., Figure 3If a matching user account is found in another tenant associated with the same organization, the access management service 135 can be configured to grant the user account to the tenant where the shared resource is located (e.g., Figure 3 110b) in the example shown in . A shadow account can be linked to a primary user account in a tenant in which the user for whom the new account has been provisioned is located. Thus, the access management service 135 can automatically generate a shadow account 301 in response to user A being invited to collaborate using resources in a tenant associated with the second tenant 110b or in response to user A accepting an invitation to access a resource. The access management service 135 creates the shadow account 301 and configures the shadow account 301 to reference the primary user account 111 of user A via a link 302.

[0044] exist Figure 2 and Figure 3 In the example shown, a user may have access to one or more software products A, B, C, and D. These software products may be software applications external to the tenant, such as cloud-based applications provided by SaaS providers 130a and 130b, or may be internal applications residing within a specific tenant. The software may require the purchase of a license to access the software. In a single-tenant organization, this is not a problem. However, in a multi-tenant organization, a user may have a primary user account in the home tenant and one or more shadow accounts in other tenants associated with other departments or sub-entities of the organization. This may cause significant problems for administrators who must manage access rights for users across multiple tenants in a large organization.

[0045] In particular, software licenses can be problematic because a user may need to access resources or perform operations through a data processing system using resources that require a software license to access the software across multiple tenants. Software licenses are typically assigned to a user account in one tenant and cannot be used to access the software in another tenant, even if both tenants are part of the same organization. To overcome this problem, an administrator must obtain additional licenses to be associated with a user account of a user in each tenant to which the user needs to access a specific licensed software application. The administrator can purchase these licenses at a high cost and / or can negotiate with the software provider to obtain free or discounted software licenses to assign to the user account of a user who needs to access the software across multiple tenants of an organization. The nested access permission checking technology disclosed herein can be used to avoid the need to obtain and maintain multiple software licenses for a single user across multiple tenants of an organization.

[0046] In a conventional implementation of the access management service 135, the access management service may be configured to provide an access rights verification application programming interface (API) that provides an interface for the application to determine whether a user is allowed to access a particular application. The application may submit a request to the access management service 135 via the API, the request including information identifying the application and the user requesting access to the application. The information identifying the application may include a unique identifier for the application, and may also include an identifier of a tenant associated with the application. The user information may include a user name, a user identifier, an authorization credential, and / or other information related to the user. The access management service 135 may be configured to find a user account associated with the request in the tenant and determine whether the user account is associated with a software license or other access rights indicating that the user is allowed to access the software. If the user account in the tenant does not have a valid software license or other access rights indicating that the user can access the software, the user will be denied access to the software. However, a user may have multiple user accounts across multiple tenants, and one of those user accounts may have a valid license or other access rights indicating that the user is allowed to access the software. However, because traditional access rights checks only check access rights associated with user accounts in a specific tenant, the user will still be denied access to the software application.

[0047] Figure 3 An example of this concept is shown. User A has a primary user account 111 in a first tenant 110a of an organization 105 and a shadow account 301 in a second tenant 110b of the organization 105. Shadow account 301 may be linked or otherwise mapped back to primary user account 111. User account 111 is associated with access rights 201 and 201 that allow the user to access software applications A and B in first tenant 110a, respectively. Shadow account 301 is not associated with any access rights to access resources in second tenant 110b. Therefore, if user A attempts to access software applications A or B using shadow account 301 in second tenant 110b, access will be denied because shadow account 301 is not associated with any access rights to any of these software applications. In a traditional access management system without nested access rights checks, an administrator would need to assign the required access rights and / or software licenses to shadow account 301 in order for user A to access software applications A or B using shadow account 301.

[0048] In an organization with potentially thousands of users, an administrator may have to provision user accounts with appropriate access rights and / or software licenses for these thousands of users across multiple tenants. While the authentication issue can be easily overcome by creating shadow accounts for users to allow them to gain access to content residing in other tenants of the organization, the licensing issue remains problematic. A license is required to access software provided by a cloud-based software provider (e.g., SaaS providers 130a and 130b). Typically, software provided by such cloud-based providers implements license checks as part of their authorization logic.

[0049] The technology disclosed herein provides a nested access permission check that overcomes the problems associated with traditional access permission checks in multi-tenant organizations. The nested access permission check can be configured to determine whether a user account of a user who has requested access to a resource is associated with a valid license or other access permission for the resource. If the user account is associated with a valid license or other access permission for the resource, the access management service 135 can grant access to the requested resource. Granting access to the resource can include sending an indication to the requested resource that the user should be allowed to access the resource. The indication can include an access token or other indication that the user is allowed to access the requested resource.

[0050] However, if the user account is not associated with a valid license or other access rights, the access management service 135 may determine whether at least one other user account associated with the user is associated with a valid license or other access rights for the requested resource. If another user account associated with the user is found to be associated with another tenant of the same organization and has a valid license and / or other access rights to the resource, the access management service 135 may grant access to the resource even though the user account requesting access to the resource is not associated with a valid license and / or other access rights to access the resource. The access management service 135 may be configured to recursively check whether a user account and / or any user accounts associated with the user account have a valid license and / or access rights for a particular resource.

[0051] Return to reference Figure 3To illustrate these concepts, user A's shadow account 301 is linked or mapped to user A's user account 111. If user A attempts to access software applications A or B from shadow account 301, the access management service 135 can first determine that shadow account 301 does not have a valid license and / or access permissions for either of these software applications. However, a nested access permission check can determine that shadow account 301 is directly or indirectly mapped or linked to another user account that has a valid license or access permissions for the resource. The nested access permission check can recursively check the linked accounts until a valid license or other access permissions are found on one of the linked accounts or there are no more linked accounts to check. Once a valid license or access permission is found, the process can stop and the access management service 135 can grant access to the requested resource. Figure 3 In the example shown, shadow account 301 is linked to primary user account 111. Primary user account 111 may in turn be linked to one or more other user accounts (not shown), which may also be linked to other user accounts associated with the user.

[0052] Figure 8 8 is an example process 800 for performing a nested access permission check to determine whether a user has a valid license and / or other access permissions to access a resource or to perform an operation using a resource by a data processing system. Process 800 may be performed by access management service 135 and / or may be performed by an application configured to determine whether a user is allowed to access the application.

[0053] The nested access rights check may include determining that the linked user account is associated with the same organization. The nested access rights check may also include determining that the second user account is associated with a tenant belonging to the same organization as the first user account. As discussed in the previous example, a user may have accounts associated with multiple tenants within an organization. Instead of assigning a software license and / or other access rights to access a resource to each of these user accounts, an administrator of the organization may only assign a license and / or other access rights associated with a resource to only one of the linked accounts. In some embodiments, an administrator may assign a license and / or other access rights to a primary account associated with a user. In other embodiments, an administrator may assign a license and / or access rights to a shadow account of a user that is mapped or linked to a primary user account. This approach can significantly reduce the number of software licenses that a multi-tenant organization may need, which can significantly reduce the overhead required to assign software licenses to users because only one user account needs to be updated, and significantly reduce costs because only one copy of the license needs to be purchased for users with multiple user accounts within an organization.

[0054] Process 800 may include operation 810, in which a signal is received via a communication network requesting an indication of whether a user has access rights to access a resource associated with a first tenant of an access management service 135 or to perform an operation using the resource through a data processing system. The requested resource may be a cloud-based application accessible to a user of a tenant of the access management service 135. The application may send a signal to the access management service 135 in response to an attempt by the user to access the cloud-based application. As discussed in the previous example, the application may communicate with the access management service 135 via an access rights verification API, which may send a signal to the access management service 135 requesting an indication of whether a user who has attempted to access the application has a valid license to use the application. The application may be associated with a first tenant of the access management service 135, and the user requesting access to the application will need a license and / or other access rights to access the requested application. The access management service 135 may maintain user accounts of users associated with particular tenants and which access rights are associated with each user account.

[0055] Process 800 may include operation 820, wherein in response to receiving the first signal, first user account data of a user stored in a memory and associated with a first tenant of an access management service is accessed. The first user account data includes a linked account identifier attribute that includes a first identifier associated with a second tenant of the access management service and a second identifier associated with second user account data of the second tenant. The access management service 135 may access the user account data referenced in the request received from the application to determine whether a license for the application is associated with the user account. Referring back to Figure 3 and Fig.11 , if user A attempts to access software application A from shadow user account 301, access management service 135 will determine that user A does not have the license and / or access permissions associated with shadow account 301. In contrast, if user A attempts to access software application A from primary user account 111, access management service 135 may determine that user account 111 is associated with valid access permissions 201 for software application A.

[0056] Process 800 may include operation 830, wherein determining that a first user account associated with a user does not have access rights to access a resource by determining that first user account data stored in a memory of the access management service and associated with a first tenant of the access management service does not include an access rights attribute that allows access to the resource. In response to determining that the user is associated with a valid license and / or access rights for the requested resource, process 800 may continue to stage 850.

[0057] Process 800 may include operation 840, wherein in response to determining that a first user account associated with the user does not have access rights to access the response, performing a nested access rights check. Performing the nested access rights check may include operation 840a, wherein a linked account identifier attribute of the first user account data is accessed to determine whether the user is associated with second user account data of a second tenant. Process 800 may also include: operation 840b, wherein upon determining that the user is associated with the second user account data, the second user account data is accessed in a second tenant of an access management service; and operation 840c, wherein it is determined that the second user account data includes an access rights attribute indicating permission for the user to access a resource. Return to reference Fig.11 , the shadow account 301 of user A in the second tenant 110b includes a linked account identifier that references the primary user account 111 of user A in the first tenant 110a. The linked account identifier in this example includes two pieces of information that can be used to identify the linked user account. The first part of the linked account identifier includes an identifier of the tenant in which the linked user account is located, and the second part of the linked account identifier includes an identifier of the user account data in that tenant. Fig.11 In the example shown, the linked account identifier of shadow account 301 includes an identifier of first tenant 110a, which in this example is "128765554". The second part of the linked account identifier of shadow account 301 includes an identifier of user account data associated with user account 111 in first tenant 110a, which in this example is "190112124575933". Access management service 135 can use the linked account identifier to access user account data associated with user account 111, and can access access permission attributes associated with the user account data to determine whether the user account is associated with any access permissions. Fig.11 In the example shown, the primary user account 111 of user A is associated with access rights A 201 and access rights B 202. In this example, user A has attempted to access software application A from shadow account 301. The nested access rights check performed by the access management service 135 has determined that user A has a license to access software application A on the primary user account 111, so the access management service 135 will grant user A's shadow account 301 rights to software application A in the organization's tenant 110b.

[0058] Process 800 may include operation 850, wherein, in response to the nested access rights check determining that the user is associated with a second user account and the second user account is associated with access rights to access the resource, granting access to the resource via the communication network. Access management service 135 may signal to the application that the user has a valid license or other access permission associated with the second user account. Figure 3 In the example shown, a shadow account 301 associated with user A is mapped to a user account 111 associated with a first tenant 110a via a link 302. The first user account 111 is associated with access rights 201 for software application A, which may include a software license and / or other access rights to access software application A. The access management service 135 may send a signal to the application indicating that the user should be granted access to the application via the license management API. If the user does not have a valid license for the application that the user is attempting to access, a signal may be sent to the application that the user should not be granted access to the application. An application that receives such a signal may present a message to the user indicating that the user does not have a valid license for the application that the user is attempting to access.

[0059] Figure 4 and Figure 5 An additional example of nested access permission checks performed for cross-tenant requests is shown. Figure 4 In the example shown, user B invites user D to collaborate on a project that requires user D to have access to software product C. User D is provided with a shadow account 401 in the first tenant 110a of the organization 105. Shadow account 401 includes a link 402 to the primary user account of user D in the second tenant 110b. Shadow account 401 is not associated with any access rights to any internal or external resources associated with the first tenant 110a. Figure 4 In the example shown, the nested access permission check will deny user D access to software application C. Neither user D's shadow account 401 nor the primary user account has a license or other access permission to software application C. Figure 5 , user D's user account includes access rights 501 to software application C. In this example, the nested access rights check will grant user D access to software application C via shadow account 401 because user D's primary user account includes a software license and / or other access rights to software application C.

[0060] Figure 6 An example of applying nested access permission checks to a cross-tenant request is shown, where the two tenants are parts of different organizations. Figure 6The example shown in shows that the access rights associated with users in the second organization 115 include access rights. User account 121 of user E is associated with access rights 601 to access application A and access rights 602 to access application B. User account 122 of user F is associated with access rights 603 to access application A and access rights 604 to access application D. User account 124 of user G is associated with access rights 611 to access application A and access rights 612 to access application B. User account 125 associated with user H is associated with access rights 613 associated with access rights 613 to access application A, and is associated with access rights 614 to access application D.

[0061] In this example, user D of the first organization 105 invites user E from the second organization 115 to collaborate on a project using software application A. User D and E are associated with different organizations. Even if a shadow account is created for user E in the second tenant 110b of organization 105, the nested access permission check will not grant user E access to software application A in the second tenant 110b. User E has access permission 601 to access application A in user account 121, but because the access permission is associated with a different organization than the one that user E has attempted to access application A, user E will not be allowed to access application A using the shadow account in the tenant associated with the second tenant 110b.

[0062] Figure 7 is a block diagram of an example implementation of an access management service that may be used to implement the access management service 135. The access management service may include a user authentication unit 705, a user account management unit 710, an access rights verification unit 715, an access rights management unit 720, and a tenant management unit 725. The functionality of the access management service 135 may be implemented by processor-executable instructions stored in a memory of a computing device. The functionality of the access management service 135 may be implemented as a cloud-based service that may be accessed through a network connection over the Internet or via one or more public and / or private networks.

[0063] The tenant management unit 725 can be configured to provide a user interface that enables an administrator of an organization to establish and / or manage tenants in the access management service 135. As discussed in the previous example, a tenant can represent an entire organization. A tenant can be associated with a sub-entity of an organization, such as a department of a company, and an organization can have more than one tenant, each tenant representing a sub-entity of the organization.

[0064] The user authentication unit 705 can be configured to authenticate the user to the tenant of the access management service 135 using various authentication techniques, including a password, a personal identification number (PIN), one or more biometric parameters (e.g., fingerprint, facial recognition, and / or other biometric parameters). The user authentication unit 705 can be configured to determine whether the user account is a shadow account mapped to a user account associated with another tenant. If the shadow account is mapped to a user account in another tenant, the user authentication unit 705 can be configured to authenticate the user using the authentication parameters associated with the user account in the other tenant. When authenticating an attempt to access the shadow account, the user authentication unit 705 can be configured to authenticate the user using the credentials that the user would use to access their primary account. For example, returning to reference Figure 3 , when attempting to access an application or other resource associated with the second tenant 110b using the shadow account 301, user A may be prompted to provide access credentials. User A may provide their access credentials for accessing content in a tenant associated with the first department of the organization. The user authentication unit 705 may authenticate the user using credentials associated with the first department's primary user account 111, but the authentication unit 705 may provide an access token associated with the second tenant 110b to the application or other resource that the user requests access to. The cross-tenant authentication process may be completely transparent to the application or other resource that the user requests access to. The application or resource may not be aware that the user has been authenticated using credentials associated with a user account in another tenant of the access management service 135.

[0065] The user account management unit 710 can be configured to provide a user interface through which the administrator of the tenant of the access management service 135 can establish and / or configure user accounts. The user account management unit 710 can provide the administrator with the ability to establish member accounts and guest accounts. Users with member accounts can create content in the tenant and invite other users to collaborate on the content. Users with guest accounts have more limited access to tenant resources. Guest accounts may not allow the creation of new content, nor may they be allowed to invite other users to collaborate on content. The access management service 135 can be configured to limit the number of guest accounts that can be created for a specific tenant. In some embodiments, the user account management unit 710 can limit the number of guest accounts so that the ratio of guest accounts to member accounts does not exceed a predetermined threshold. Due to the restrictions imposed on guest accounts, the shadow accounts discussed in the previous examples are created as member accounts. The user account management unit 710 can also be configured to suspend or delete user accounts and remove the mapping back to another user account.

[0066] The access rights verification unit 715 may be configured to determine whether the member account has a valid license for a software product in response to a user associated with the member account attempting to access an internal or external software application associated with a tenant of the access management service 135. The access rights verification unit 715 may also be configured to perform a nested license check to determine whether the user account is associated with another user account that is associated with a valid license for the software product. The access rights verification unit 715 may be configured to perform a nested license check on one or more user accounts mapped or linked to the member user account, wherein the one or more user accounts are associated with the same organization. As discussed in the previous example, an organization may include more than one tenant in the access management service. The nested license check allows a user account in multiple tenants to be assigned a license for a specific software application in one of these tenants, and use this license to access this software application when working in another tenant associated with the same organization. This avoids the administrators of these tenants having to obtain duplicate licenses for users in each tenant where the user can access the software application. The access rights verification unit 715 does not allow the use of a license associated with a user account from another organization to access content. This prevents users from circumventing licensing requirements by creating a shadow account in your tenant for a user from another organization's tenant and linking the shadow account with the user account in the other organization.

[0067] Access right verification unit 715 can also be configured to determine whether a guest license is available in response to a user associated with a guest account attempting to access a resource. If a group license is available from a group license pool, a guest license can be temporarily allocated to a guest user account to allow the guest user to access a specific resource.

[0068] The access rights management unit 720 can be configured to provide a user interface for the administrator of the tenant to configure the access rights associated with the user account including but not limited to software licenses. The access rights management unit 720 can be configured to provide a user interface for adding a new software license to the tenant, associating a software license with a user account, and / or adding a new guest license to the tenant. The access rights management unit 720 can also be configured to remove a license from the tenant and / or from the user account. The license removed from the user account can be placed in a license pool associated with the member user account of the tenant. The access rights management unit 720 can also be configured to provide a user interface for the administrator to define user groups and assign license pools that can be used by users from the user groups.

[0069] Combination Figure 1-7 right Figure 8 The examples of the operations shown in the flowchart shown in FIG. Figure 8The specific order or hierarchy of elements and / or operations disclosed in the EMBODIMENTS is an example approach. Based on design preferences, it is understood that Figure 8 The specific order or hierarchy of elements and / or operations in the description may be rearranged while remaining within the scope of the present disclosure. Figure 8 The elements of various operations are presented in an example order and are not meant to be limited to the specific order or hierarchy presented. Furthermore, the appended claims present various elements and / or various elements of operations in an example order and are not meant to be limited to the specific elements, order or hierarchy presented.

[0070] Combination Figure 1-8 Detailed examples of the described systems, devices, and techniques are presented here to illustrate the disclosure and its benefits. Such usage examples should not be construed as limitations on the logical process embodiments of the disclosure, nor should variations of the user interface methods from those described herein be considered outside the scope of the disclosure. It should be understood that references to displaying or presenting an item (such as, but not limited to, presenting an image on a display device, presenting audio via one or more speakers, and / or vibrating a device) include issuing instructions, commands, and / or signals that cause or are reasonably expected to cause a device or system to display or present the item. In some embodiments, Figure 1-8 The various features described in the present invention are implemented in corresponding modules, which may also be referred to as and / or include logic, components, units and / or mechanisms. The modules may constitute software modules (eg, codes embodied on a machine-readable medium) or hardware modules.

[0071] In some examples, the hardware module can be implemented mechanically, electronically, or using any suitable combination thereof. For example, the hardware module may include a dedicated circuit or logic configured to perform certain operations. For example, the hardware module may include a dedicated processor, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC). The hardware module may also include a programmable logic or circuit temporarily configured by software to perform certain operations, and may include a portion of machine-readable medium data and / or instructions for such configuration. For example, the hardware module may include software contained in a programmable processor that is configured to execute a set of software instructions. It should be understood that the decision to implement the hardware module mechanically, in a dedicated and permanently configured circuit, or in a temporarily configured circuit (e.g., configured by software) may be driven by cost, time, support, and engineering considerations.

[0072] Therefore, the phrase "hardware module" should be understood to cover tangible entities that can perform certain operations and can be configured or arranged in a certain physical manner, that is, entities that are physically constructed, permanently configured (e.g., hardwired) and / or temporarily configured (e.g., programmed) to operate or perform certain operations described herein in a certain manner. As used herein, "hardware-implemented module" refers to a hardware module. Considering the example that the hardware module is temporarily configured (e.g., programmed), each hardware module does not need to be configured or instantiated at any one time instance. For example, in the case where the hardware module includes a programmable processor that is configured to be a special-purpose processor by software, the programmable processor can be configured as different special-purpose processors (e.g., including different hardware modules) at different times. The software can therefore configure one or more processors, for example, to constitute a specific hardware module at one time instance and to constitute different hardware modules at different time instances. Hardware modules implemented using one or more processors can be referred to as "processor-implemented" or "computer-implemented."

[0073] Hardware modules can provide information to other hardware modules and receive information from other hardware modules. Therefore, the described hardware modules can be considered to be communicatively coupled. In the case of multiple hardware modules being present at the same time, communication can be achieved by signal transmission (e.g., through appropriate circuits and buses) between or among two or more hardware modules. In embodiments where multiple hardware modules are configured or instantiated at different times, communication between these hardware modules can be achieved, for example, by storing and retrieving information in a memory device accessible to multiple hardware modules. For example, one hardware module can perform an operation and store the output in a memory device, and then another hardware module can access the memory device to retrieve and process the stored output.

[0074] In some examples, at least some operations of the method may be performed by one or more processors or processor-implemented modules. In addition, one or more processors may also operate to support the execution of related operations in a "cloud computing" environment or as "software as a service" (SaaS). For example, at least some operations may be performed by multiple computers (as an example of a machine including a processor) and / or among multiple computers, where these operations may be accessed via a network (e.g., the Internet) and / or via one or more software interfaces (e.g., application program interfaces (APIs)). The execution of certain operations may be distributed among the processors, not only residing in a single machine, but also deployed on multiple machines. The processor or processor-implemented module may be located in a single geographic location (e.g., in a home or office environment or a server farm), or may be distributed across multiple geographic locations.

[0075] Fig. 9is a block diagram 900 illustrating an example software architecture 902, portions of which may be used in conjunction with the various hardware architectures described herein that may implement any of the features described above. Fig. 9 is a non-limiting example of a software architecture, and it should be appreciated that many other architectures may be implemented to facilitate the functionality described herein. Software architecture 902 may be implemented in a system such as Fig.10 The system is executed on hardware such as a machine 1000, which includes a processor 1010, a memory 1030, and an input / output (I / O) component 1050. A representative hardware layer 904 is shown and can represent, for example, Fig.10 The machine 1000 of the embodiment of the present invention. The representative hardware layer 904 includes a processing unit 906 and associated executable instructions 908. The executable instructions 908 represent executable instructions of the software architecture 902, including implementations of the methods, modules, etc. described herein. The hardware layer 904 also includes a memory / storage device 910, which also includes executable instructions 908 and accompanying data. The hardware layer 904 may also include other hardware modules 912. The instructions 908 maintained by the processing unit 906 may be part of the instructions 908 maintained by the memory / storage device 910.

[0076] Example software architecture 902 can be conceptualized as layers, each providing various functionality. For example, software architecture 902 may include layers and components, such as operating system (OS) 914, library 916, framework 918, application 920, and presentation layer 944. In operation, application 920 and / or other components within a layer may invoke API calls 924 to other layers and receive corresponding results 926. The layers shown are representative in nature, and other software architectures may include additional layers or different layers. For example, some mobile or dedicated operating systems may not provide framework / middleware 918.

[0077] OS 914 can manage hardware resources and provide public services. OS 914 may include, for example, kernel 928, service 930, and driver 932. Kernel 928 may serve as an abstraction layer between hardware layer 904 and other software layers. For example, kernel 928 may be responsible for memory management, processor management (e.g., scheduling), component management, network, security settings, etc. Service 930 may provide other public services for other software layers. Driver 932 may be responsible for controlling or engaging with underlying hardware layer 904. For example, driver 932 may include display driver, camera driver, memory / storage device driver, peripheral device driver (e.g., via universal serial bus (USB)), network and / or wireless communication driver, audio driver, etc. (depending on hardware and / or software configuration).

[0078] The library 916 may provide a common infrastructure that may be used by the application 920 and / or other components and / or layers. The library 916 may generally provide functionality for other software modules to perform tasks, rather than directly interacting with the OS 914. The library 916 may include a system library 934 (e.g., a C standard library) that may provide functions such as memory allocation, string manipulation, and file operations. In addition, the library 916 may include an API library 936, such as a media library (e.g., supporting the presentation and manipulation of image, sound, and / or video data formats), a graphics library (e.g., an OpenGL library for rendering 2D and 3D graphics on a display), a database library (e.g., SQLite or other relational database functions), and a Web library (e.g., WebKit that may provide Web browsing functionality). The library 916 may also include various types of other libraries 938 to provide many functions for the application 920 and other software modules.

[0079] Framework 918 (sometimes also referred to as middleware) provides a higher level common infrastructure that can be used by applications 920 and / or other software modules. For example, framework 918 can provide various graphical user interface (GUI) functions, advanced resource management, or advanced location services. Framework 918 can provide a variety of other APIs for applications 920 and / or other software modules.

[0080] Applications 920 include built-in applications 940 and / or third-party applications 942. Examples of built-in applications 940 may include, but are not limited to, contact applications, browser applications, location applications, media applications, messaging applications, and / or game applications. Third-party applications 942 may include any application developed by an entity other than the supplier of a particular platform. Applications 920 may use the functions available via OS 914, library 916, framework 918, and presentation layer 944 to create a user interface to interact with a user.

[0081] Some software architectures use virtual machines, such as virtual machine 948. Virtual machine 948 provides an execution environment in which applications / modules can run as they would on a hardware machine (e.g., Fig.10 The virtual machine 948 may be hosted by a host OS (e.g., OS 914) or a hypervisor and may have a virtual machine monitor 946 that manages the operation of the virtual machine 948 and interoperation with the host operating system. A software architecture that may be different from the software architecture 902 outside the virtual machine is executed within the virtual machine 948, such as the OS 914, libraries 952, frameworks 954, applications 956, and / or presentation layer 958.

[0082] Fig.101 is a block diagram illustrating components of an example machine 1000 that is configured to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any of the features described herein. The example machine 1000 is in the form of a computer system within which instructions 1016 (e.g., in the form of software components) for causing the machine 1000 to perform any of the features described herein may be executed. Thus, the instructions 1016 may be used to implement the modules or components described herein. The instructions 1016 cause the unprogrammed and / or unconfigured machine 1000 to act as a specific machine configured to perform the described features. The machine 1000 may be configured to act as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the machine 1000 may operate as a server machine or a client machine in a server-client network environment, or as a node in a peer-to-peer or distributed network environment. The machine 1000 may be embodied as, for example, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a gaming and / or entertainment system, a smartphone, a mobile device, a wearable device (e.g., a smart watch), and an Internet of Things (IoT) device. Furthermore, while only a single machine 1000 is shown, the term "machine" includes a collection of machines that individually or jointly execute instructions 1016.

[0083] The machine 1000 may include a processor 1010, a memory 1030, and I / O components 1050, which may be communicatively coupled via, for example, a bus 1002. The bus 1002 may include multiple buses that couple various elements of the machine 1000 via various bus technologies and protocols. In an example, the processor 1010 (including, for example, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an ASIC, or a suitable combination thereof) may include one or more processors 1012a to 1012n that can execute instructions 1016 and process data. In some examples, one or more processors 1010 may execute instructions provided or identified by one or more other processors 1010. The term "processor" includes a multi-core processor, which includes cores that can execute instructions simultaneously. Although Fig.10 Multiple processors are shown, but machine 1000 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors each with a single core, multiple processors each with multiple cores, or any combination thereof. In some examples, machine 1000 may include multiple processors distributed among multiple machines.

[0084] The memory / storage 1030 may include a main memory 1032, a static memory 1034 or other memory, and a storage unit 1036, both of which are accessible by the processor 1010, for example, via the bus 1002. The storage unit 1036 and the memories 1032, 1034 store instructions 1016 that embody any one or more of the functions described herein. The memory / storage 1030 may also store temporary, intermediate, and / or long-term data for the processor 1010. During execution thereof, the instructions 1016 may also reside, in whole or in part, within the memories 1032, 1034, within the storage unit 1036, within at least one of the processors 1010 (e.g., within a command buffer or cache), within a memory, within at least one I / O component 1050, or any suitable combination thereof. Therefore, the memories 1032, 1034, the storage unit 1036, the memory in the processor 1010, and the memory in the I / O component 1050 are examples of machine-readable media.

[0085] As used herein, a "machine-readable medium" refers to a device capable of temporarily or permanently storing instructions and data that cause the machine 1000 to operate in a particular manner, and may include, but is not limited to, random access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical storage media, magnetic storage media and devices, cache memory, network-accessible or cloud storage devices, other types of storage devices, and / or any suitable combination thereof. The term "machine-readable medium" applies to a single medium or a combination of multiple media used to store instructions (e.g., instructions 1016) for execution by the machine 1000, such that the instructions, when executed by one or more processors 1010 of the machine 1000, cause the machine 1000 to perform one or more features described herein. Thus, a "machine-readable medium" may refer to a single storage device, as well as a "cloud-based" storage system or storage network that includes multiple storage devices or devices. The term "machine-readable medium" does not include the signal itself.

[0086] I / O components 1050 may include a variety of hardware components suitable for receiving input, providing output, generating output, transmitting information, exchanging information, capturing measurements, etc. The specific I / O components 1050 included in a particular machine will depend on the type and / or function of the machine. For example, a mobile device such as a mobile phone may include a touch input device, while a headless server or IoT device may not include such a touch input device. Fig.10The specific examples of I / O components shown are by no means limiting, and other types of components may be included in the machine 1000. The grouping of I / O components 1050 is merely to simplify the discussion, and the grouping is by no means limiting. In various examples, the I / O components 1050 may include a user output component 1052 and a user input component 1054. The user output component 1052 may include, for example, a display component (e.g., a liquid crystal display (LCD) or a projector) for displaying information, an acoustic component (e.g., a speaker), a tactile component (e.g., a vibration motor or a force feedback device), and / or other signal generators. The user input component 1054 may include, for example, an alphanumeric input component (e.g., a keyboard or a touch screen), a pointing component (e.g., a mouse device, a touch pad, or another pointing tool), and / or a tactile input component (e.g., a physical button or a touch screen that provides a position and / or a touch force or a touch gesture), which is configured to receive various user inputs, such as user commands and / or selections.

[0087] In some examples, I / O components 1050 may include biometric components 1056, motion components 1058, environment components 1060, and / or positioning components 1062, as well as a wide range of other physical sensor components. Biometric components 1056 may include, for example, components that detect body expressions (e.g., facial expressions, vocal expressions, hand or body gestures, or eye tracking), measure biosignals (e.g., heart rate or brain waves), and identify people (e.g., via voice, retina, fingerprint, and / or face-based recognition). Motion components 1058 may include, for example, acceleration sensors (e.g., accelerometers) and rotation sensors (e.g., gyroscopes). Environment components 1060 may include, for example, lighting sensors, temperature sensors, humidity sensors, pressure sensors (e.g., barometers), acoustic sensors (e.g., microphones for detecting ambient noise), proximity sensors (e.g., infrared sensing of nearby objects), and / or other components that may provide indications, measurements, or signals corresponding to the surrounding physical environment. Positioning component 1062 may include, for example, a position sensor (e.g., a global positioning system (GPS) receiver), an altitude sensor (e.g., a barometric pressure sensor from which altitude may be derived), and / or an orientation sensor (e.g., a magnetometer).

[0088] The I / O components 1050 may include a communication component 1064 that implements a variety of technologies operable to couple the machine 1000 to a network 1070 and / or a device 1080 via respective communication couplings 1072 and 1082. The communication component 1064 may include one or more network interface components or other suitable devices to interface with the network 1070. The communication component 1064 may include, for example, components suitable for providing wired communication, wireless communication, cellular communication, near field communication (NFC), Bluetooth communication, Wi-Fi, and / or communication via other means. The device 1080 may include other machines or various peripheral devices (e.g., via USB coupling).

[0089] In some examples, the communication component 1064 can detect the identifier or include a component suitable for detecting the identifier. For example, the communication component 1064 can include a radio frequency identification (RFID) tag reader, an NFC detector, an optical sensor (e.g., a one-dimensional or multi-dimensional barcode, or other optical code), and / or an acoustic detector (e.g., a microphone for identifying an audio signal of a tag). In some examples, the location information can be determined based on information from the communication component 1064, such as, but not limited to, a geographic location via an Internet Protocol (IP) address, a location via Wi-Fi, cellular, NFC, Bluetooth, or other wireless station identification and / or signal triangulation.

[0090] In the following, further features, characteristics and advantages of the system and method will be described by the following items: Item 1. 1. A computing device comprising: a processor; and a computer-readable medium storing executable instructions for causing the processor to perform operations, the operations comprising: receiving a first signal via a communication network, the first signal requesting the following indication: whether a user has access rights to access resources associated with a first tenant of an access management service, or to perform operations using the resources through a data processing system; in response to receiving the first signal, accessing first user account data of the user stored in a memory and associated with the first tenant of the access management service, wherein the first user account data includes a linked account identifier attribute, the linked account identifier attribute including a first identifier associated with a second tenant of the access management service and a second identifier associated with the second tenant. The invention relates to a method for controlling the access management service of the present invention to a second tenant of the access management service and a second identifier associated with the second user account data of the second tenant of the access management service; determining that the first user account data does not include an access permission attribute that allows access to the resource; in response to determining that the first user account data does not have access permission to access the resource, performing a nested access permission check by: accessing the linked account identifier attribute of the first user account data to determine whether the user is associated with the second user account data of the second tenant; when it is determined that the user is associated with the second user account data, accessing the second user account data in the second tenant of the access management service; and determining that the second user account data includes the access permission attribute that indicates that the user is allowed to access the resource; and in response to the nested access permission check determining that the user is allowed to access the resource, granting access to the resource via the communication network.

[0091] Item 2. A computing device according to Item 1, wherein the resources managed by the access management service include applications, the access management service manages access rights to access the applications, and wherein the instructions for receiving the first signal requesting whether a user's indication is valid also include instructions configured to cause the processor to perform operations, the operations comprising: receiving the first signal via an access rights verification application programming interface (API) associated with the access management service.

[0092] Item 3. A computing device according to Item 2, wherein the instructions for granting access to the resource also include instructions configured to cause the processor to perform operations, the operations comprising: in response to the user being associated with a second user account that has the access rights to the resource, sending a second signal to the application via the access rights verification API indicating that access to the application should be granted.

[0093] Item 4. The computing device according to Item 1 further includes instructions configured to cause the processor to perform the following operations: determine whether the first tenant and the second tenant are part of the same organization; and in response to a result of the nested access permission check, grant access to the resource in response to the nested access permission check determining that the user is associated with the second user account, the second user account is associated with the access permission to access the resource, and the first tenant and the second tenant are part of the same organization.

[0094] Item 5. The computing device according to Item 1 further includes instructions configured to cause the processor to perform the following operations: in response to receiving the request from the user, determining that the user does not have a user account associated with the first tenant; determining that the user has the second user account associated with the second tenant; and in response to determining that the user does not have a user account associated with the first tenant and the user has the second user account associated with the second tenant, creating the first user account associated with the first tenant.

[0095] Item 6. The computing device of Item 5 further includes instructions configured to cause the processor to perform the following operations: link the first user account to the second user account in the access management service.

[0096] Item 7. A computing device according to Item 5, wherein the instructions for creating the first user account in response to determining that the user does not have a user account associated with the first tenant also include instructions configured to cause the processor to perform the following operations: create a member account for the first user, and the member account is not associated with any access rights to access resources associated with the first tenant.

[0097] Item 8. A computing device according to Item 1, wherein the instructions for performing the nested access permission check also include instructions for causing the processor to perform the following operations: determining that a first user account of the user is associated with multiple user accounts managed by the access management service; determining whether a corresponding user account among the multiple user accounts is associated with access permission to access the resource; and in response to a corresponding user account among the multiple user accounts being associated with the access permission, determining that the user is associated with a second user account, and the second user account is associated with the access permission to access the resource.

[0098] Item 9. A method performed by an access management service, the method comprising: receiving a first signal via a communication network, the first signal requesting an indication of whether a user has access rights to access resources associated with a first tenant of the access management service, or to perform operations using the resources through a data processing system; in response to receiving the first signal, accessing first user account data of the user stored in a memory and associated with the first tenant of the access management service, wherein the first user account data includes a linked account identifier attribute, the linked account identifier attribute including a first identifier associated with a second tenant of the access management service and a second identifier associated with second user account data of the second tenant; determining that the first user account data does not include permission access permission attribute for accessing the resource; in response to determining that the first user account data does not have the access permission to access the resource, performing a nested access permission check by: accessing the linked account identifier attribute of the first user account data to determine whether the user is associated with the second user account data of the second tenant; when it is determined that the user is associated with the second user account data, accessing the second user account data in the second tenant of the access management service; and determining that the second user account data includes the access permission attribute indicating that the user is allowed to access the resource; and in response to the nested access permission check determining that the user is allowed to access the resource, granting access to the resource via the communication network.

[0099] Item 10. A method according to Item 9, wherein the resources managed by the access management service include applications, the access management service manages access rights to access the applications, and wherein receiving the first signal including the request from the user includes: receiving the first signal from the application via an access rights verification application programming interface (API) associated with the access management service.

[0100] Item 11. A method according to Item 10, wherein granting access to the resource further includes: in response to the user being associated with a second user account having the access rights to the resource, sending a second signal to the application via the access rights verification API indicating that the user should be granted access to the application.

[0101] Item 12. The method according to Item 9 also includes: determining whether the first tenant and the second tenant are part of the same organization; and in response to the result of the nested access permission check, granting access to the resource in response to the nested access permission check determining that the user is associated with the second user account, the second user account is associated with the access permission to access the resource, and the first tenant and the second tenant are part of the same organization.

[0102] Item 13. The method according to Item 12 also includes: in response to receiving the request from the user, determining that the user does not have an account associated with the first tenant; determining that the user has a user account associated with the second tenant associated with the first tenant; and creating the first user account in response to determining that the user does not have an account associated with the first tenant.

[0103] Item 14. The method according to Item 13 also includes: linking the first user account to the second user account in the access management service.

[0104] Item 15. A method according to Item 9, wherein performing the nested access permission check also includes: determining that the first user account of the user is associated with multiple user accounts managed by the access management service; determining whether a corresponding user account among the multiple user accounts is associated with access permissions to access the resource; and in response to a corresponding user account among the multiple user accounts being associated with the access permissions, determining that the user is associated with a second user account, and the second user account is associated with the access permissions to access the resource.

[0105] Item 16. A memory device storing instructions that, when executed on a processor of a computing device, cause the computing device to provide an access management service on the computing device in the following manner: receiving a first signal via a communication network requesting an indication of whether a user has access rights to access resources associated with a first tenant of the access management service, or to perform operations using the resources by a data processing system; in response to receiving the first signal, accessing first user account data of a user stored in a memory and associated with the first tenant of the access management service, wherein the first user account data includes a linked account identifier attribute, the linked account identifier attribute including a first identifier associated with a second tenant of the access management service and a second identifier associated with second user account data of the second tenant identifier; determining that the first user account data does not include an access permission attribute that allows access to the resource; in response to determining that the first user account data does not have access permission to access the resource, performing a nested access permission check by: accessing a linked account identifier attribute of the first user account data to determine whether the user is associated with second user account data of the second tenant; upon determining that the user is associated with the second user account data, accessing second user account data in the second tenant of the access management service; and determining that the second user account data includes an access permission attribute that indicates that the user is allowed to access the resource; and in response to the nested access permission check determining that the user is allowed to access the resource, granting access to the resource via the communication network.

[0106] Item 17. A memory device according to Item 16, wherein the resources managed by the access management service include applications, the access management service manages access rights to access the applications, and wherein the instructions for receiving a signal including a request from a user also include instructions configured to cause the computing device to perform operations, the operations including: receiving a first signal from the application via an access rights verification application programming interface (API) associated with the access management service; and wherein the instructions for granting access to resources also include instructions configured to cause the computing device to perform operations, the operations including: in response to the user being associated with a second user account having access rights to the resources, sending a second signal to the application via the access rights verification API indicating that the user should be granted access to the application.

[0107] Item 18. The memory device of Item 16 further comprises instructions configured to cause the computing device to perform the following operations: determine whether the first tenant and the second tenant are part of the same organization; and in response to a result of the nested access permission check, grant access to the resource in response to the nested access permission check determining that the user is associated with a second user account, the second user account is associated with access permission to access the resource, and the first tenant and the second tenant are part of the same organization.

[0108] Item 19. The memory device according to Item 18 further includes instructions configured to cause the computing device to perform the following operations: in response to receiving a request from a user, determine that the user does not have an account associated with the first tenant; determine that the user has a user account associated with a second tenant associated with the first tenant; and create the first user account in response to determining that the user does not have an account associated with the first tenant.

[0109] Item 20. The memory device of Item 19, further comprising instructions configured to cause the computing device to perform the following operations: link the first user account to the second user account in the access management service.

[0110] Although various embodiments have been described, the description is intended to be exemplary rather than restrictive, and it should be understood that many more embodiments and implementations within the scope of the embodiments are possible. Although many possible feature combinations are shown in the drawings and discussed in this detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature of any embodiment can be used in combination with any other feature or element in any other embodiment or replace any other feature or element. Therefore, it should be understood that any feature shown and / or discussed in this disclosure can be implemented together in any suitable combination. Therefore, the embodiments are not limited except according to the attached claims and their equivalents. In addition, various modifications and changes can be made within the scope of the attached claims.

[0111] Although what is considered to be the best mode and / or other examples have been described above, it should be understood that various modifications may be made therein and the subject matter disclosed herein may be implemented in various forms and examples, and that the teachings may be applied to many applications, only some of which are described herein. The appended claims are intended to claim any and all applications, modifications, and variations that fall within the true scope of the present teachings.

[0112] Unless otherwise indicated, all measurements, values, ratings, positions, amplitudes, dimensions and other specifications set forth in this specification (including the appended claims) are approximate and not exact. They are intended to have a reasonable range consistent with the functions to which they are related and the customary practices in the art to which they belong.

[0113] The scope of protection is limited only by the claims now appended hereto. When interpreted in light of this specification and the subsequent prosecution history, the scope is intended and should be interpreted to be as broad as consistent with the ordinary meaning of the language used in the claims and to encompass all structural and functional equivalents. Nevertheless, no claims are intended to include subject matter that does not satisfy the requirements of Sections 101, 102, or 103 of the Patent Act, nor should they be interpreted in such a manner. Any unexpected inclusion of such subject matter is hereby disclaimed.

[0114] Except as stated immediately above, nothing stated or described is intended or should be construed as causing any component, step, feature, object, benefit, advantage or equivalent to be conferred to the public regardless of whether or not it is recited in the claims.

[0115] It should be understood that the terms and expressions used herein have the ordinary meanings assigned to them relative to their corresponding fields of investigation and study, unless otherwise specified herein. Relational terms such as first and second may be used alone to distinguish one entity or action from another without requiring or implying any actual such relationship or order between these entities or actions. The terms "include", "comprises" or any other variants are intended to cover non-exclusive inclusions, so that the process, method, article or device containing a list of elements includes not only those elements, but may also include other elements that are not explicitly listed or inherent to such processes, methods, articles or devices. Without further limitation, an element beginning with "one" or "an" does not exclude the presence of additional identical elements in the process, method, article or device containing the element.

[0116] The Abstract of the present disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing detailed description, it can be seen that various features are grouped together in various examples for the purpose of simplifying the present disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claims require more features than each claim expressly recites. On the contrary, as reflected in the appended claims, the inventive subject matter lies in less than all the features of a single disclosed example. Therefore, the appended claims are hereby incorporated into the detailed description, with each claim standing alone as a separately claimed subject matter.

Claims

1. A system for managing access rights of users of an organization having multiple tenants, the multiple tenants including a first tenant and a second tenant, each tenant being associated with one or more user accounts, the system comprising: processor; as well as a computer-readable medium in communication with the processor, the computer-readable medium comprising instructions that, when executed by the processor, cause the processor to control the system to perform: storing, at a data storage device, first user account data of a first user account associated with a first user of the first tenant, the first user account data comprising: (1) a first object identifier identifying the first user account data, (2) a first tenant identifier identifying the first tenant associated with the first user account data, and (3) first access permission information comprising one or more access permissions granted to the first user account of the first tenant to access one or more resources; creating, for the first user associated with the first tenant: (1) a second user account of the second tenant and (2) second user account data for the second user account; configuring the second user account data to include linked account information, the linked account information including the first object identifier and the first tenant identifier of the first user account data; and The second user account data including the linked account information is stored at the data storage device.

2. The system according to claim 1, wherein: The one or more resources include a software application, and the one or more access permissions include a permission to use the software application.

3. The system according to claim 1, wherein: The instructions, when executed by the processor, further cause the processor to control the system to perform: determining whether the first access permission information includes a first access permission for accessing a first resource; and In response to determining that the first access permission information includes the first access permission to access the first resource, the first access permission to access the first resource is granted to the second user account of the second tenant.

4. The system according to claim 1, wherein: The instructions, when executed by the processor, further cause the processor to control the system to perform: receiving a request for determining whether the second user account is granted first user access rights to access a first resource; In response to receiving the request, determining whether the first user access right is granted to the second user account based on the second user account data; In response to determining that the first user access right is not granted to the second user account, determining whether the second user account is linked to another user account of another tenant based on the linked account information; In response to determining that the second user account is linked to the first user account of the first tenant, accessing the first access permission information of the first user account data based on the first object identifier of the linked account information and the first tenant identifier; Based on the first access permission information, determining whether the first user account is granted the first user access permission to access the first resource; as well as In response to determining that the first user account is granted the first user access right, granting the first user access right to access the first resource to the second user account of the second tenant.

5. The system according to claim 1, wherein: The instructions, when executed by the processor, further cause the processor to control the system to perform: determining whether the first tenant and the second tenant are part of the same organization; In response to determining that the first tenant and the second tenant are part of the same organization, determining whether the first access permission information includes a first access permission to access a first resource; as well as In response to determining that the first access permission information includes the first access permission, granting the first access permission to the second user account of the second tenant to access the first resource.

6. The system of claim 5, wherein: The first user account data includes first tenant attribute information identifying a first organization to which the first tenant belongs. The second user account data includes second tenant attribute information identifying a second organization to which the second tenant belongs, and In order to determine that the first tenant and the second tenant are part of the same organization, the instructions, when executed by the processor, also cause the processor to control the system to perform: determining that the first organization and the second organization respectively identified in the first tenant information and the second tenant information correspond to each other.

7. The system according to claim 1, wherein: The second user account data includes: a second object identifier identifying the second user account data; a second tenant identifier identifying the second tenant associated with the second user account data; and The second access permission information includes one or more access permissions granted to the second user account of the second tenant to access one or more resources.

8. The system according to claim 1, wherein: To create the second user account of the second tenant, the instructions, when executed by the processor, further cause the processor to control the system to perform: determining whether the first user has a user account with the second tenant; In response to determining that the first user does not have a user account with the second tenant, determining whether the first user has a user account with the first tenant; as well as In response to determining that the user has the first user account with the first tenant, the second user account with the second tenant is created.

9. The system of claim 1, wherein: The data storage device comprises a first data storage device and a second data storage device provided for the first tenant and the second tenant respectively, The first user account data and the second user account data are stored at the first data storage device and the second data storage device, respectively, and The first tenant has no access rights to the second data storage device, and the second tenant has no access rights to the first data storage device.

10. A method for managing access rights of users of an organization having multiple tenants, the multiple tenants comprising a first tenant and a second tenant, each tenant being associated with one or more user accounts, the method comprising: storing, at a data storage device, first user account data of a first user account associated with a first user of the first tenant, the first user account data comprising: (1) a first object identifier identifying the first user account data, (2) a first tenant identifier identifying the first tenant associated with the first user account data, and (3) first access permission information comprising one or more access permissions granted to the first user account of the first tenant to access one or more resources; creating, for the first user associated with the first tenant: (1) a second user account of the second tenant and (2) second user account data for the second user account; configuring the second user account data to include linked account information, the linked account information including the first object identifier and the first tenant identifier of the first user account data; and The second user account data including the linked account information is stored at the data storage device.

11. The method according to claim 10, wherein: The one or more resources include a software application, and the one or more access permissions include a permission to use the software application.

12. The method according to claim 10, further comprising: determining whether the first access permission information includes a first access permission for accessing a first resource; as well as In response to determining that the first access permission information includes the first access permission to access the first resource, the first access permission to access the first resource is granted to the second user account of the second tenant.

13. The method according to claim 10, further comprising: receiving a request for determining whether the second user account is granted first user access rights to access a first resource; In response to receiving the request, determining whether the first user access right is granted to the second user account based on the second user account data; In response to determining that the first user access right is not granted to the second user account, determining whether the second user account is linked to another user account of another tenant based on the linked account information; In response to determining that the second user account is linked to the first user account of the first tenant, accessing the first access permission information of the first user account data based on the first object identifier of the linked account information and the first tenant identifier; Based on the first access permission information, determining whether the first user account is granted the first user access permission to access the first resource; as well as In response to determining that the first user account is granted the first user access right, granting the first user access right to access the first resource to the second user account of the second tenant.

14. The method according to claim 10, further comprising: determining whether the first tenant and the second tenant are part of the same organization; In response to determining that the first tenant and the second tenant are part of the same organization, determining whether the first access permission information includes a first access permission to access a first resource; as well as In response to determining that the first access permission information includes the first access permission, granting the first access permission to the second user account of the second tenant to access the first resource.

15. The method according to claim 5, wherein: The first user account data includes first tenant attribute information identifying a first organization to which the first tenant belongs. The second user account data includes second tenant attribute information identifying a second organization to which the second tenant belongs, and Determining that the first tenant and the second tenant are part of the same organization includes determining that the first organization and the second organization respectively identified in the first tenant information and the second tenant information correspond to each other.

16. The method according to claim 10, wherein: The second user account data includes: a second object identifier identifying the second user account data; a second tenant identifier identifying the second tenant associated with the second user account data; and The second access permission information includes one or more access permissions granted to the second user account of the second tenant to access one or more resources.

17. The method according to claim 10, wherein: Creating the second user account of the second tenant includes: determining whether the first user has a user account with the second tenant; In response to determining that the first user does not have a user account with the second tenant, determining whether the first user has a user account with the first tenant; and In response to determining that the first user has the first user account with the first tenant, the second user account with the second tenant is created.

18. The method of claim 10, wherein: The data storage device comprises a first data storage device and a second data storage device provided for the first tenant and the second tenant respectively, The first user account data and the second user account data are stored at the first data storage device and the second data storage device, respectively, and The first tenant has no access rights to the second data storage device, and the second tenant has no access rights to the first data storage device.

19. A non-transitory computer-readable medium comprising instructions that, when executed by a processor, cause the processor to control a system for managing access rights of users of an organization having a plurality of tenants to perform operations, the plurality of tenants comprising a first tenant and a second tenant, each tenant being associated with one or more user accounts, the operations comprising: storing, at a data storage device, first user account data of a first user account associated with a first user of the first tenant, the first user account data comprising: (1) a first object identifier identifying the first user account data, (2) a first tenant identifier identifying the first tenant associated with the first user account data, and (3) first access permission information comprising one or more access permissions granted to the first user account of the first tenant to access one or more resources; creating, for the first user associated with the first tenant: (1) a second user account of the second tenant and (2) second user account data for the second user account; configuring the second user account data to include linked account information, the linked account information including the first object identifier and the first tenant identifier of the first user account data; and The second user account data including the linked account information is stored at the data storage device.

20. The non-transitory computer readable medium of claim 19, wherein: The instructions, when executed by the processor, cause the processor to control the system to perform: determining whether the first access permission information includes a first access permission for accessing a first resource; as well as In response to determining that the first access permission information includes the first access permission to access the first resource, the first access permission to access the first resource is granted to the second user account of the second tenant.

Images