User permissions in a multi-tenant environment

Abstract

A cross-tenant authentication system is described. The system receives a user token from a client device registered with a first tenant of a service application to a server. The system receives a request from the client device to access a second feature of a second tenant of the service application. The second feature of the second tenant of the service application is separate from a first feature of the first tenant of the service application. The second feature is only accessible to devices registered with the second tenant of the service application. The system authenticates the request by verifying the user token from the client device and determines a cross-tenant policy of the second tenant of the service application based on the user token. The system forms an identity object based on the cross-tenant policy.

Description

[0001] Priority requirements

[0002] This application claims priority to Luxembourg patent application No. LU102236, filed on November 27, 2020, which is incorporated herein by reference in its entirety. Technical Field

[0003] The subject matter disclosed herein generally relates to managing resource access from users in a multi-tenant environment. Specifically, this disclosure relates to systems and methods for authenticating and granting permissions for cross-tenant users to access services in a multi-tenant environment. Background Technology

[0004] The server can provide services from the service application to users in different organizations. Users within an organization are authenticated to access resources assigned to their respective organizations. A user in one organization can request access to resources assigned to another organization (e.g., files stored in a storage location). One solution involves providing users with guest accounts. However, adding guest accounts requires manually creating new guest accounts and adding each guest account individually. Therefore, if a user is a guest in three different organizations, he / she will need to maintain and switch between three different accounts when accessing resources in different organizations. Attached Figure Description

[0005] To facilitate identification of any discussion of a particular element or action, the highest significant digit in the figure reference numerals refers to the figure number in which that element was first introduced.

[0006] Figure 1 It is a graphical representation of a network environment in which the present disclosure may be deployed, according to some exemplary embodiments.

[0007] Figure 2 This is a block diagram illustrating an example of the operation of a cross-tenant authentication application according to an exemplary embodiment.

[0008] Figure 3 The diagram illustrates a block diagram of components of a cross-tenant authentication application according to an exemplary embodiment.

[0009] Figure 4 The diagram illustrates an interaction according to an exemplary embodiment.

[0010] Figure 5 This is a flowchart illustrating a method for generating an identity object according to an exemplary embodiment.

[0011] Figure 6 This is a flowchart illustrating a method for accessing a service using an identity object, according to an exemplary embodiment.

[0012] Figure 7 This is a block diagram illustrating a software architecture in which the present disclosure can be implemented according to exemplary embodiments.

[0013] Figure 8 It is a schematic representation of a machine in the form of a computer system according to exemplary embodiments, in which a set of instructions can be executed to cause the machine to perform any one or more of the methods discussed herein. Detailed Implementation

[0014] The following description illustrates systems, methods, techniques, instruction sequences, and computer machine program products that illustrate exemplary embodiments of the subject matter. In this description, numerous specific details are set forth for purposes of explanation in order to provide an understanding of various embodiments of the subject matter. However, it will be apparent to those skilled in the art that embodiments of the subject matter can be practiced without some or other of these specific details. Examples merely represent possible variations. Unless explicitly stated otherwise, structures (e.g., structural components, such as modules) are optional and can be combined or subdivided, while operations (e.g., in processes, algorithms, or other functions) can vary sequentially or can be combined or subdivided.

[0015] This application describes a system for enabling cross-tenant access to shared resources. The term "tenant" is used herein to refer to an organization's representation relative to a service application. A tenant can be a dedicated instance of a cloud-based identity and access management service received by an organization or application developer. The cloud-based identity and access management service enables users of an organization to log in and access resources in external resources (e.g., Microsoft 365™, SaaS applications) and internal resources (e.g., applications within the organization's network and intranet, cloud applications developed by the organization). In another example, a tenant represents a container of items (such as users, domains, subscriptions, groups) of an organization operating within a larger environment (e.g., a Microsoft Office 365 datacenter).

[0016] In a multi-tenant environment, each tenant can be represented as a silo. Users of a tenant access resources within their own tenant, such as mailboxes, groups, and files. In other words, users authenticate to the same lease where the resource resides. Since access to a resource also requires authorization, this authorization is given within the context of the tenant to which the user is authenticated.

[0017] Because the access pattern remains the same within the same lease, there is no distinction between the tenant authenticating the user (e.g., the home tenant) and the tenant where the resource the user is trying to access resides (e.g., the resource tenant). The permission the user obtains to access the home tenant's resources is included as part of the home tenant's access token as a result of successful authentication of the home tenant.

[0018] However, in cases where resources are shared between tenants, authorization granted to the application within the same resource context of user authentication no longer holds. Since the home tenant and the resource tenant are no longer the same, the permission included in the access token as a result of successful authentication no longer applies to the accessing resource tenant.

[0019] Additionally, resource tenant administrators may want to be able to configure which resources are shareable or accessible outside their leases. For example, these administrators might not understand how to configure permission mappings to access individual application programming interfaces (APIs). For instance, administrators typically understand higher-level concepts such as access capabilities (e.g., "Allow idle / busy" or "Allow group access") and are able to specify which tenant resources are shareable. However, when capabilities are configured to be shareable, this can mean being able to invoke multiple services and APIs. Therefore, different permissions need to be included in the request to trigger specific capabilities.

[0020] This application describes a system that enables users logged into different home tenants to access resources while maintaining secure and manageable access. To achieve these features, the system performs two main operations: (1) removing permissions included as a result of successful authentication (e.g., when authorizing an application to access resources within the same tenant) and (2) re-establishing / rehydrating permissions in cross-tenant resource access requests as a result of successful authorization, based on rules controlled by the administrator. This application also describes a system that maps concepts and capabilities understood by tenant administrators to concepts and corresponding permissions understood by APIs. Permissions can be dynamically added when requests are made to access different resources.

[0021] Each service (API) owner provides configuration to map capabilities to allow its API to understand and enforce the necessary authorizations to grant access to resources. Such configurations are then used and enforced to rehydrate permissions, enabling secure access to resources using the minimum configurations from the tenant administrator or service (API) owner.

[0022] In one exemplary embodiment, a system and method for cross-tenant authentication are described. A computer-implemented method includes: receiving a user token from a client device registered with a first tenant of a service application on a server, the user token being provided to the client device by a directory service application after authentication of the client device; receiving from the client device a request to access a second feature of a second tenant of the service application, the second feature of the second tenant of the service application being separate from a first feature of the first tenant of the service application, the second feature being accessible only to devices registered with the second tenant of the service application; authenticating the request by verifying the user token from the client device; in response to verifying the user token, determining a cross-tenant policy for the second tenant of the service application based on the user token; and forming an identity object at the server based on the cross-tenant policy, the identity object including a permission value of a permission attribute, the permission value identifying an access level of the client device to the second feature of the second tenant of the service application.

[0023] As a result, one or more of the methods described herein facilitate solutions to the technical problem of providing cross-tenant access to services from service applications configured for other tenants. As previously described, this application addresses the following problems: the creation of different individual accounts to access different tenants, the lack or difficulty in configuring guest permissions, and the lack of a centralized system for managing auditable resource sharing. For example, other mechanisms can be used to share resources, such as email (by forwarding internal documents) or third-party applications (using third-party applications to communicate with users outside the tenant). Although both are initiated by the end user, the tenant administrator loses control over tenant resources. Thus, one or more of the methods described herein can avoid the need for specific efforts or computing resources (e.g., creating additional individual guest accounts). Examples of such computing resources include processor cycles, network traffic, memory usage, data storage capacity, power consumption, network bandwidth, and cooling capacity.

[0024] Figure 1This is a schematic representation of a network environment 100 in which some exemplary embodiments of this disclosure may be implemented or deployed. One or more application servers 104 provide server-side functionality to networked user devices (in the form of client devices 106) via network 102. Client devices 106 include web clients 110 (e.g., browsers) and programming clients 108 (e.g., communication applications such as Microsoft Teams™, cross-tenant policy configurator applications, document writing applications, and shared document storage applications) hosted and executed on client devices 106. The policy configurator application may operate in conjunction with web client 110 and / or programming client 108. In another exemplary embodiment, the policy configurator is part of programming client 108 or web client 110.

[0025] Application Programming Interface (API) server 124 and web server 126 provide corresponding programming and web interfaces to application server 104. Application-specific server 116 hosts server-side service application 118, Active Directory token authenticator 120, and cross-tenant authentication application 122. Each application may also include additional components, modules, and applications.

[0026] Server-side service application 118 includes, for example, server-side email / calendar enterprise applications, server-side instant messaging enterprise applications, document creation enterprise applications, or shared document storage enterprise applications. Service application 122 enables users of the enterprise (e.g., tenants of server-side service application 118) to collaborate with each other and share documents, messages, and other data (e.g., meeting information, shared projects). For example, user 132 at client device 106 accesses and uses server-side service application 118 to edit documents shared with other users of the same tenant or other users of another tenant. In another example, client device 106 accesses and uses server-side service application 118 to retrieve or send messages or emails to other peers of the same or different tenants. Other examples of server-side service application 118 include enterprise systems, content management systems, and knowledge management systems.

[0027] Active Directory token validator 120 verifies tokens issued by a directory service application (e.g., Active Directory application 134). Active Directory application 134 may reside at application server 104 or a third-party server 112. Active Directory application 134 includes cloud-based identity and access management services (e.g., Microsoft Azure Active Directory), which help enterprise users log in and access resources in (1) external resources (e.g., Microsoft 365, SaaS applications) and (2) internal resources such as those on an organizational network or intranet, as well as resources in any cloud applications developed by the organization. Thus, Active Directory token validator 120 can be used to authenticate users of the organization by verifying user tokens (e.g., native federated tokens) with the user.

[0028] Cross-tenant authentication application 122 enables resource sharing among users of different tenants. In one example, cross-tenant authentication application 122 performs an authentication process that allows a user of a first tenant to access resources from a second tenant without requiring a new individual guest account to be created for the first tenant's user. In one example, Active Directory token validator 120 authenticates the first tenant's user based on the verification of a user token provided by client device 106 (Active Directory application 134 provides the user token to client device 106). Once Active Directory token validator 120 verifies the user token, cross-tenant authentication application 122 can access the policy library to identify access / permission rights for the user and the second tenant. Cross-tenant authentication application 122 forms an identity object for the user based on the permissions retrieved from the policy library for the user. The user 132 can then access services from server-side service application 118 according to the permissions defined in the identity object.

[0029] In another exemplary embodiment, cross-tenant authentication application 122 enables tenant administrators to configure and specify different levels of access / permissions for services from a second tenant for users of a first tenant. For example, a tenant may be granted access to a specific communication channel provided by server-side service application 118, but may not be able to perform a user directory search operation with server-side service application 118. The following is relative to... Figure 3 Exemplary components of the cross-tenant authentication application 122 are further described.

[0030] Server-side service application 118, Active Directory token validator 120, and cross-tenant authentication application 122 communicate with programming client 108 via a programming interface provided by application programming interface (API) server 124. In another example, server-side service application 118, Active Directory token validator 120, and cross-tenant authentication application 122 communicate with web client 110 via web server 126.

[0031] Application server 116 is shown communicatively coupled to database server 128, which provides easy access to an information repository or database 130. In an exemplary embodiment, database 130 includes storage devices for storing information to be processed by server-side service application 118, Active Directory token authenticator 120, and cross-tenant authentication application 122. In another exemplary embodiment, database 130 includes storage devices for storing cross-tenant application license mappings configured by cross-tenant authentication application 122.

[0032] Third-party application 114 stores Active Directory application 134 and third-party application 114. Third-party application 114, executing on third-party server 112, is shown to have programmatic access to application server 116 via a programming interface provided by application programming interface (API) server 124. For example, third-party application 114, using information retrieved from application server 116, may support one or more features or functionalities on a website hosted by a third party. In another example, third-party server 112 may store cross-tenant application license mappings configured by cross-tenant authentication application 122. In yet another example, third-party application 114 may store server-side service application 118, Active Directory token validator 120, or cross-tenant authentication application 122.

[0033] Figure 2 This is a block diagram illustrating a network environment 200 according to an exemplary embodiment, showing the operation of a cross-tenant authentication application 122. The network environment 200 includes client device 206, client device 208, application server 116, and client device 106.

[0034] User 132 may be an administrator of a tenant (e.g., tenant B). User 132 uses policy configurator 210 to operate client device 106 to define cross-tenant policies and set permissions / permissions for users other than tenant B. For example, user 132 defines a cross-tenant policy for tenant B that allows other user tenants to read the shared communication channel provided by server-side service application 118. User 132 may also operate policy configurator 210 to define that users other than tenant B cannot search or view tenant B's user directory. Policy configurator 210 communicates with cross-tenant authentication application 122 to define attribute values ​​for permission attributes stored in the cross-tenant policy library. In one exemplary embodiment, the cross-tenant policy library defines access permissions to tenant B for all user tenants other than tenant B. In another exemplary embodiment, the cross-tenant policy library defines access permissions to tenant B for specific user tenants other than tenant B. In yet another exemplary embodiment, the cross-tenant policy library defines access permissions to tenant B for users of a specific tenant (e.g., tenant A).

[0035] User 202 is a user associated with tenant A. Client device 206 includes client-side service application 212 that accesses tenant A service 216 of server-side service application 118. For example, user 202 accesses files or communication channels that are only accessible to users of tenant A. To access tenant A's files or communication channels, client-side service application 212 sends a home tenant access request to server-side service application 118. Active Directory token authenticator 120 verifies the user token provided by user 202 to authenticate user 202's identity and confirm that client device 206 has access to tenant A service 216. Once user 202's identity is verified along with the corresponding tenant permission (e.g., allowing user 202 to read files from tenant A service 216), server-side service application 118 grants client-side service application 212 home tenant authorized access to tenant A service 216 authorized for user 202.

[0036] User 204 is a user associated with another tenant (tenant B). Client device 208 includes client-side service application 214 that accesses tenant B's service 218 of server-side service application 118. For example, user 204 accesses files or communication channels that are only accessible to users of tenant B. To access tenant B's files or communication channels, client-side service application 214 sends a home tenant access request to server-side service application 118. Active Directory token authenticator 120 verifies the user token provided by user 204 to authenticate user 204's identity and confirm that client device 208 has access to tenant B's service 218. Once user 204's identity is verified along with the corresponding tenant permission (e.g., allowing user 204 to read files from tenant B's service 218), server-side service application 118 grants client-side service application 214 home tenant authorized access to tenant B's service 218, which is authorized for user 204.

[0037] In one exemplary embodiment, user 204 seeks access to a shared communication channel from tenant A service 216. Client-side service application 214 sends a cross-tenant request (e.g., a resource tenant access request) to tenant A service 216. Cross-tenant authentication application 122 determines the cross-tenant access request (e.g., user 204 from tenant B is attempting to access the shared communication channel of tenant A service 216). Active Directory token authenticator 120 first authenticates user 204 by verifying a user token received from client device 208. After user 204 is authenticated, cross-tenant authentication application 122 accesses the cross-tenant policy library to identify / map user 204's permissions / access rights relative to tenant A service 216. Cross-tenant authentication application 122 forms an identity object based on the mapped permissions. Tenant A service 216 processes the identity object and provides services from tenant A service 216 to client-side service application 214 based on the permission attribute values ​​described in the identity object.

[0038] Figure 3 The diagram illustrates the components of a cross-tenant authentication application 122 according to an exemplary embodiment. The cross-tenant authentication application 122 includes a service application middleware 302, a cross-tenant API 304, API authentication metadata 306, and a cross-tenant policy module 308.

[0039] Client device 208 is authenticated to access the services of the home tenant by obtaining a user token after being authenticated at Active Directory token authenticator 120. Client device 208 uses the same user token to access the services of another tenant (e.g., tenant A service 216). Thus, client device 208 does not need to obtain a separate access token with a new guest account to access the services of other tenants. Client device 208 provides the user token to cross-tenant authentication application 122.

[0040] Service application middleware 302 receives a user token and identifies a cross-tenant access request from client device 208 to access a service of a tenant different from the tenant associated with the user token. In one exemplary embodiment, service application middleware 302 identifies user 204 of client device 208, the tenant associated with user 204 (e.g., tenant B), the tenant associated with the request (e.g., tenant A), and one or more shared services of tenant A.

[0041] The cross-tenant API 304 includes a token authentication library 310, a policy authentication library 312, and an authentication object builder 314. Client device 206 includes metadata (e.g., base API authorization metadata) indicating whether tenant A has chosen to share tenant A's services. The following code illustrates an example of base API authorization metadata:

[0042] CrossTenantAccessEnabled:true

[0043] CorssTenantCapabilityPermissionMap[{

[0044] ALLowSharedChannel :

[0045] Groups.ReadWrite.All

[0046] }]

[0047] API authentication metadata 306 can be stored in a permission mapping for cross-tenant capabilities. For example, the permission mapping indicates whether access to a shared service is permitted from another tenant.

[0048] Token authentication library 310 authenticates cross-tenant requests and invokes policy authentication library 312 after authenticating user 204. For example, token authentication library 310 verifies the user token provided by user 204 and verifies that the service permissions for tenant B are enabled. During user token verification, token authentication library 310 invokes the policy check procedure of policy authentication library 312.

[0049] The policy authentication library 312 accesses the cross-tenant policy module 308 to determine cross-tenant access policies and prevent cross-tenant data leakage. For example, the cross-tenant policy module 308 identifies whether a user of tenant A can perform a specific function or access a specific operation at tenant B. For instance, a cross-tenant policy might instruct user 204 to access tenant B's shared communication channel but not to search tenant B's user directory. The following code illustrates an example of a cross-tenant policy for tenant B:

[0050] XTAP Policy:

[0051] ToMyTenant:

[0052] AllowSharedChannel :true

[0053] AllowPeopleSeanch:false

[0054] AllowPeopleCard:true

[0055] The authentication object builder 314 forms an identity object based on user 204's user identifier, resource and home tenant identifiers (e.g., tenant A, tenant B), and permissions indicated in the cross-tenant policy. The server-side service application 118 provides user 204 with access to shared services based on the identity object.

[0056] Figure 4Interaction diagram 420 is illustrated according to an exemplary embodiment. Interaction diagram 420 illustrates the operation and interaction between client device 208, Active Directory token validator 120, cross-tenant authentication application 122, and tenant A service 216. Client device 208 of user 204 associated with tenant B requests a user token (e.g., token request 402) as part of its authentication / authentication process with Active Directory token validator 120 when accessing its home tenant (e.g., tenant B). Active Directory token validator 120 sends user token 404 to client device 208. Client device 208 seeks access to a service from another tenant (e.g., tenant B) and generates resource tenant request 406. Client device 208 submits user token + cross-tenant access request 408 to cross-tenant authentication application 122. Cross-tenant authentication application 122 verifies the cross-tenant access request based on user token 410. Cross-tenant authentication application 122 identifies the cross-tenant access policy based on the verified user token 412. Cross-tenant authentication application 122 forms an identity object based on cross-tenant access policy 414. Cross-tenant authentication application 122 sends the identity object 416 to tenant A service 216. Tenant A service 216 provides authorization service 418 to client device 208.

[0057] Figure 5 This is a flowchart illustrating a method 500 for generating an identity object according to an exemplary embodiment. The operations in method 500 can be used by the cross-tenant authentication application 122 as described above. Figure 3 The components described (e.g., modules, engines) are used to perform this operation. Therefore, method 500 is described by reference to the exemplary manner of cross-tenant authentication application 122. However, it should be appreciated that at least some of the operations in method 500 can be deployed on various other hardware configurations or performed by similar components residing elsewhere. For example, some of the operations can be performed at server-side service application 118.

[0058] In box 502, cross-tenant authentication application 122 receives an access token from the client device. In box 504, cross-tenant authentication application 122 determines that the client is requesting access to a service belonging to another tenant. In box 506, cross-tenant authentication application 122 authenticates the request by verifying the access token. In box 508, cross-tenant authentication application 122 identifies a cross-tenant policy based on the request and / or the access token. In box 510, cross-tenant authentication application 122 forms an identity object based on the identified cross-tenant policy.

[0059] Figure 6 This is a flowchart illustrating a method 600 for accessing a service using an identity object according to an exemplary embodiment. The operations in method 600 can be used by the server-side service application 118 and the cross-tenant authentication application 122, as described above. Figure 3 The components described (e.g., modules, engines) are used to execute this. Therefore, method 600 is described in an exemplary manner with reference to server-side service application 118 and cross-tenant authentication application 122. However, it should be appreciated that at least some of the operations in method 600 can be deployed on various other hardware configurations or performed by similar components residing elsewhere.

[0060] At box 602, server-side service application 118 receives an identity object from cross-tenant authentication application 122. At box 604, server-side service application 118 provides access to services for the first tenant to client devices registered for the second tenant based on the identity object.

[0061] Figure 7 This is a block diagram 700 illustrating a software architecture 704 that can be installed on any one or more devices described herein. The software architecture 704 is supported by hardware such as a machine 702 including a processor 720, memory 726, and I / O components 738. In this example, the software architecture 704 can be conceptualized as a stack of layers, each providing specific functionality. The software architecture 704 includes layers such as an operating system 712, libraries 710, frameworks 708, and applications 706. Operationally, application 706 invokes API calls 750 through the software stack and receives messages 752 in response to API calls 750.

[0062] Operating system 712 manages hardware resources and provides public services. Operating system 712 includes, for example, a kernel 714, services 716, and drivers 722. Kernel 714 acts as an abstraction layer between the hardware layer and other software layers. For example, kernel 714 provides memory management, processor management (e.g., scheduling), component management, network and security settings, and other functions. Services 716 can provide other public services to other software layers. Drivers 722 are responsible for controlling or interfacing with the underlying hardware. For example, drivers 722 may include display drivers, camera drivers, etc. or Low-power drives, flash drives, serial communication drives (e.g., Universal Serial Bus (USB) drives), Drivers, audio drivers, power management drivers, etc.

[0063] Library 710 provides low-level public infrastructure used by application 706. Library 710 may include system libraries 718 (e.g., the C standard library) that provide functions such as memory allocation functions, character manipulation functions, mathematical functions, etc. Furthermore, library 710 may include API libraries 724, such as media libraries (e.g., libraries supporting demonstrations and manipulations of various media formats such as Moving Picture Experts Group-4 (MPEG4), Advanced Video Coding (H.264 or AVC), Moving Picture Experts Group Layer 3 (MP3), Advanced Audio Coding (AAC), Adaptive Multi-Rate (AMR) audio codecs, Joint Photographic Experts Group (JPEG or JPG), or Portable Web Graphics (PNG),) graphics libraries (e.g., an OpenGL framework for rendering graphical content on a display in two-dimensional (2D) and three-dimensional (3D),) databases (e.g., SQLite providing various relational database functionalities), web libraries (e.g., WebKit providing web browsing functionality), etc. Library 710 may also include various other libraries 728 to provide application 706 with many other APIs.

[0064] Framework 708 provides high-level public infrastructure for use by application 706. For example, framework 708 provides various graphical user interface (GUI) functions, advanced resource management, and advanced location services. Framework 708 can provide a wide range of other APIs that can be used by application 706, some of which may be specific to a particular operating system or platform.

[0065] In an exemplary embodiment, application 706 may include a home application 736, a contacts application 730, a browser application 732, a book reader application 734, a location application 742, a media application 744, a messaging application 746, a game application 748, and a wide variety of other applications such as third-party application 740. Application 706 is a program that performs functions defined in a program. Various programming languages ​​can be used to create one or more of applications 706 structured in various ways, such as object-oriented programming languages ​​(e.g., Objective-C, Java, or C++) or procedural programming languages ​​(e.g., C or assembly language). In a particular example, third-party application 740 (e.g., used by an entity other than a vendor of a particular platform using Android) TM or iOS TM Applications developed using a Software Development Kit (SDK) can run on platforms such as iOS. TM ANDROID TM , Mobile software on a telephone or another mobile operating system. In this example, a third-party application 740 can invoke API call 750 provided by the operating system 712 to facilitate the functions described herein.

[0066] Figure 8 This is a schematic representation of machine 800, in which instructions 808 (e.g., software, programs, applications, applets, apps, or other executable code) can be executed to cause machine 800 to perform any one or more methods discussed herein. For example, instructions 808 can cause machine 800 to perform any one or more methods described herein. Instructions 808 transform a general, unprogrammed machine 800 into a specific machine 800 that is programmed to perform the functions described and shown in the manner described. Machine 800 can operate as a standalone device or can be coupled (e.g., networked) to other machines. In a network deployment, machine 800 can operate as a server machine or client in a server-client network environment, or as a peer-to-peer machine in a peer-to-peer (or distributed) network environment. Machine 800 may include, but is not limited to, server computers, client computers, personal computers (PCs), tablet computers, laptop computers, netbooks, set-top boxes (STBs), PDAs, entertainment media systems, cellular phones, smartphones, mobile devices, wearable devices (e.g., smartwatches), smart home devices (e.g., smart appliances), other smart devices, web devices, network routers, network switches, network bridges, or any machine capable of sequentially or otherwise executing instructions 808 specifying actions to be taken by machine 800. Furthermore, although only a single machine 800 is illustrated, the term "machine" should also be understood to include a collection of machines that individually or jointly execute instructions 808 to perform any one or more methods discussed herein.

[0067] Machine 800 may include processor 802, memory 804, and I / O components 842, which may be configured to communicate with each other via bus 844. In an exemplary embodiment, processor 802 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), an ASIC, a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 806 and processor 810 that execute instruction 808. The term "processor" is intended to include multi-core processors, which may include two or more independent processors (sometimes referred to as "cores") that can execute instructions simultaneously. Although Figure 8 Multiple processors 802 are illustrated, but machine 800 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.

[0068] Memory 804 includes main memory 812, static memory 814, and memory cells 816, all of which are accessible by processor 802 via bus 844. Main memory 804, static memory 814, and memory cells 816 store instructions 808 embodying any one or more of the methods or functions described herein. Instructions 808 may also reside wholly or partially within main memory 812, static memory 814, machine-readable medium 818 within memory cells 816, at least one of processors 802 (e.g., within the processor's cache memory), or any suitable combination thereof, during execution by machine 800.

[0069] I / O component 842 may include various components for receiving input, providing output, generating output, transmitting information, exchanging information, capturing measurements, etc. The specific I / O component 842 included in a particular machine will depend on the type of machine. For example, a portable machine such as a mobile phone may include a touch input device or other such input structure, while a headless server machine may not include such a touch input device. It is understood that I / O component 842 may include... Figure 8 Many other components are not shown. In various exemplary embodiments, I / O component 842 may include output component 828 and input component 830. Output component 828 may include visual components (e.g., a display such as a plasma display panel (PDP), a light-emitting diode (LED) display, a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)), acoustic components (e.g., a speaker), haptic components (e.g., a vibration motor, a resistance mechanism), other signal generators, etc. Input component 830 may include alphanumeric input components (e.g., a keyboard, a touchscreen configured to receive alphanumeric input, an optical keyboard, or other alphanumeric input components), point-based input components (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or another pointing instrument), haptic input components (e.g., a physical button, a touchscreen that provides the position and / or force of a touch or touch gesture, or other haptic input components), audio input components (e.g., a microphone), etc.

[0070] In a further exemplary embodiment, I / O component 842 may include a wide array of other components, such as biometric component 832, motion component 834, environmental component 836, or position component 838. For example, biometric component 832 includes components for detecting facial expressions (e.g., hand gestures, facial expressions, vocal expressions, body posture, or eye tracking), measuring biosignals (e.g., blood pressure, heart rate, body temperature, sweating, or brain waves), and recognizing a person (e.g., voice recognition, retinal recognition, facial recognition, fingerprint recognition, or EEG-based recognition). Motion component 834 includes accelerometer components (e.g., accelerometers), gravity sensor components, rotation sensor components (e.g., gyroscopes), and the like. Environmental component 836 includes, for example, a lighting sensor component (e.g., a photometer), a temperature sensor component (e.g., one or more thermometers for detecting ambient temperature), a humidity sensor component, a pressure sensor component (e.g., a barometer), an acoustic sensor component (e.g., one or more microphones for detecting background noise), a proximity sensor component (e.g., an infrared sensor for detecting nearby objects), a gas sensor (e.g., a gas detection sensor for detecting hazardous gas concentrations or measuring pollutants in the atmosphere for safety purposes), or other components that can provide indications, measurements, or signals corresponding to the surrounding physical environment. Position component 838 includes a position sensor component (e.g., a GPS receiver component), an altitude sensor component (e.g., an altimeter or barometer for detecting air pressure from which altitude is derived), a direction sensor component (e.g., a magnetometer), and the like.

[0071] Communication can be implemented using a variety of technologies. I / O component 842 also includes communication component 840, operable to couple machine 800 to network 820 or device 822 via coupler 824 and coupler 826, respectively. For example, communication component 840 may include a network interface component or another suitable device interfaced with network 820. In further examples, communication component 840 may include a wired communication component, a wireless communication component, a cellular communication component, a near field communication (NFC) component, etc. Components (e.g.) (low energy) Components and other communication components to provide communication via other modes. Device 822 can be another machine or any of a variety of peripheral devices (e.g., a peripheral device coupled via USB).

[0072] Furthermore, the communication component 840 can detect identifiers or include components operable to detect identifiers. For example, the communication component 840 may include a radio frequency identification (RFID) tag reader component, an NFC smart tag detection component, an optical reader component (e.g., for detecting one-dimensional barcodes such as Universal Product Code (UPC) barcodes, multi-dimensional barcodes such as Quick Response (QR) codes, Aztec codes, Data Matrix, Dataglyph, MaxiCode, PDF417, Super Code, UCC RSS-2D barcodes, and other optical codes) or an acoustic detection component (e.g., a microphone for identifying tagged audio signals). Additionally, various information can be exported via the communication component 840, such as location via Internet Protocol (IP) geolocation, etc. Location can be determined by signal triangulation, or by detecting the location of NFC beacon signals that indicate a specific location.

[0073] Various memories (e.g., memory 804, main memory 812, static memory 814, and / or the memory of processor 802) and / or storage units 816 may store one or more sets of instructions and data structures (e.g., software) that embody or are used by one or more methods or functions described herein. When executed by processor 802, these instructions (e.g., instruction 808) cause various operations to implement the disclosed embodiments.

[0074] Instruction 808 can be sent or received via network 820 using a transmission medium, via a network interface device (e.g., a network interface component included in communication component 840), and using any of a number of well-known transmission protocols (e.g., Hypertext Transfer Protocol (HTTP)). Similarly, instruction 808 can be sent or received by device 822 via a transmission medium via coupler 826 (e.g., a peer-to-peer coupler).

[0075] Although an overview of the subject matter has been described with reference to specific exemplary embodiments, various modifications and changes can be made to these embodiments without departing from the broader scope of the embodiments of the invention. For example, various embodiments or features thereof may be mixed and matched or made optional by those skilled in the art. These embodiments of the subject matter of the invention may be referred to herein individually or collectively by the term "invention" for convenience only, and are not intended to voluntarily limit the scope of this application to any single invention or inventive concept if, in fact, more than one invention or inventive concept is disclosed.

[0076] The embodiments illustrated herein are considered to have been described in sufficient detail to enable those skilled in the art to practice the disclosed teachings. Other embodiments may be used and derived therefrom, allowing for structural and logical substitutions and changes without departing from the scope of this disclosure. Therefore, this detailed description should not be construed as limiting, and the scope of the various embodiments is defined only by the appended claims and the full scope of their equivalents.

[0077] Furthermore, multiple instances may be provided for a resource, operation, or structure described herein as a single instance. Additionally, the boundaries between various resources, operations, modules, engines, and data stores are somewhat arbitrary, with specific operations described within the context of a particular illustrative configuration. Other allocations of functionality are contemplated and may fall within the scope of various embodiments of the invention. Generally, structures and functions presented as separate resources in exemplary configurations may be implemented as combined structures or resources. Similarly, structures and functions presented as single resources may be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within the scope of embodiments of the invention as represented by the appended claims. Therefore, the specification and drawings are to be regarded as illustrative rather than restrictive.

[0078] Example

[0079] Example 1 is a computer-implemented method comprising: receiving a user token from a client device registered with a first tenant of a service application on a server, the user token being provided to the client device by a directory service application after authentication of the client device; receiving from the client device a request to access a second feature of a second tenant of the service application, the second feature of the second tenant of the service application being separate from a first feature of the first tenant of the service application, the second feature being accessible only to devices registered with the second tenant of the service application; authenticating the request by verifying the user token from the client device; determining a cross-tenant policy for the second tenant of the service application based on the user token in response to verifying the user token; and forming an identity object at the server based on the cross-tenant policy, the identity object including a permission value of a permission attribute, the permission value identifying the access level of the client device to the second feature of the second tenant of the service application.

[0080] Example 2 includes Example 1, and further includes: providing the identity object to the service application associated with the second tenant; determining that the permission value of the permission attribute in the identity object indicates support for the client device to access the second feature of the second tenant of the service application; and in response to determining that the permission value of the permission attribute in the identity object indicates support for the client device to access the second feature of the second tenant of the service application, allowing the client device to access the second feature of the second tenant of the service application.

[0081] Example 3 includes any of the examples above, and further includes: accessing a cross-tenant library that maps the permissions of the features of the service application of the second tenant to users of the first tenant, wherein the cross-tenant policy is determined based on the permissions of the features of the service application of the second tenant mapped to the first tenant.

[0082] Example 4 includes any of the examples above, and further includes: accessing a cross-tenant library that maps the permission rights of the features of the service application of the second tenant to the user identified in the user token, wherein the cross-tenant policy is determined based on the permission rights of the features of the service application of the second tenant mapped to the user associated with the user token.

[0083] Example 5 includes any of the examples above, and further includes: accessing a cross-tenant license mapping; and identifying cross-tenant API metadata associated with the second tenant from the cross-tenant license mapping, the cross-tenant API metadata indicating the cross-tenant access license rights of the second tenant.

[0084] Example 6 includes any of the examples above, wherein the directory service application is configured to manage security permissions for users of the service application, wherein the first tenant indicates a first group of users in a first organization, and wherein the second tenant indicates a second group of users in a second organization.

[0085] Example 7 includes any of the examples above, wherein the service application includes a communication application, wherein the second feature of the second tenant of the service application includes a second communication channel of the communication application, and wherein the request indicates access to the second communication channel of the communication application.

[0086] Example 8 includes any of the examples above, wherein the service application includes a file-sharing application, wherein the second feature of the file-sharing application includes a file storage device, and wherein the request indicates access to a file on the file storage device.

[0087] Example 9 includes any of the examples above, wherein the identity object identifies: a user identifier associated with the user token, a first tenant indicating a family tenant of the user associated with the user identifier, a second tenant indicating a resource tenant of the user associated with the user identifier, the service application, and a licensed access right to the service application of the second tenant.

[0088] Example 10 includes any of the examples above, and further includes: receiving the license value of the license attribute, the license value indicating the license level of the second feature of the second tenant of the service application for users other than the second tenant; updating the cross-tenant library, the cross-tenant library mapping the license rights of the second feature of the second tenant of the service application to users of the first tenant of the service application; and updating the identity object based on the updated cross-tenant library.

[0089] Example 11 is a computing device including: a processor; and a memory storing instructions that, when executed by the processor, configure the device to: receive a user token from a client device registered with a first tenant of a service application on a server, the user token being provided to the client device by a directory service application after authentication of the client device; receive from the client device a request to access a second feature of a second tenant of the service application, the second feature of the second tenant of the service application being separate from a first feature of the first tenant of the service application, the second feature being accessible only to devices registered with the second tenant of the service application; authenticate the request by verifying the user token from the client device; determine a cross-tenant policy for the second tenant of the service application based on the user token in response to verifying the user token; and form an identity object at the server based on the cross-tenant policy, the identity object including a permission value of a permission attribute that identifies the access level of the client device to the second feature of the second tenant of the service application.

[0090] Example 12 includes Example 11, wherein the instructions further configure the apparatus to: provide the identity object to the service application associated with the second tenant; determine that the permission value of the permission attribute in the identity object indicates support for the client device to access the second feature of the second tenant of the service application; and in response to determining that the permission value of the permission attribute in the identity object indicates support for the client device to access the second feature of the second tenant of the service application, allow the client device to access the second feature of the second tenant of the service application.

[0091] Example 13 includes any of the examples above, wherein the instructions further configure the device to: access a cross-tenant library that maps permissions of the features of the service application of the second tenant to users of the first tenant, wherein the cross-tenant policy is determined based on the permissions of the features of the service application of the second tenant mapped to the first tenant.

[0092] Example 14 includes any of the examples above, wherein the instructions further configure the device to: access a cross-tenant library that maps permissions of the features of the service application of the second tenant to the user identified in the user token, wherein the cross-tenant policy is determined based on the permissions of the features of the service application of the second tenant mapped to the user associated with the user token.

[0093] Example 15 is a non-transitory computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to: receive a user token from a client device registered with a first tenant of a service application on a server, the user token being provided to the client device by a directory service application after authentication of the client device; receive from the client device a request to access a second feature of a second tenant of the service application, the second feature of the second tenant of the service application being separate from a first feature of the first tenant of the service application, the second feature being accessible only to devices registered with the second tenant of the service application; authenticate the request by verifying the user token from the client device; in response to verifying the user token, determine a cross-tenant policy for the second tenant of the service application based on the user token; and form an identity object at the server based on the cross-tenant policy, the identity object including a permission value of a permission attribute, the permission value identifying the access level of the client device to the second feature of the second tenant of the service application.

Claims

1. A computer-implemented method, comprising: Receive a user token from the client device that has registered with the first tenant of the service application on the server. The user token is provided to the client device by the directory service application after the client device has been verified. The client device receives a request to access a second feature of a second tenant of the service application, wherein the second feature of the second tenant of the service application is separate from the first feature of the first tenant of the service application, and the second feature is accessible only to devices registered with the second tenant of the service application. The request is authenticated by verifying the user token from the client device. In response to verifying the user token, the cross-tenant policy of the service application for the second tenant is determined based on the user token through the following operations: Access cross-tenant license mapping; as well as Identify cross-tenant API metadata associated with the second tenant from the cross-tenant license map, the cross-tenant API metadata indicating cross-tenant access license rights for the second tenant; as well as An identity object is formed at the server based on the cross-tenant policy. The identity object includes a permission value of a permission attribute, which identifies the access level of the client device to the second characteristic of the second tenant of the service application. The identity object identification includes: a user identifier associated with the user token, a first tenant indicating a family tenant of the user associated with the user identifier, a second tenant indicating a resource tenant of the user associated with the user identifier, the service application, and the authorized access rights to the service application of the second tenant.

2. The computer-implemented method according to claim 1 further includes: Provide the identity object to the service application associated with the second tenant; Determining the permission value of the permission attribute in the identity object indicates that the client device is authorized to access the second feature of the second tenant of the service application; as well as In response to determining that the permission value of the permission attribute in the identity object indicates support for the client device's access to the second feature of the second tenant of the service application, the client device is allowed to access the second feature of the second tenant of the service application.

3. The computer-implemented method according to claim 1 further includes: Access a cross-tenant library that maps the permissions of the service application features of the second tenant to users of the first tenant, wherein the cross-tenant policy is determined based on the permissions of the service application features of the second tenant that are mapped to the first tenant.

4. The computer-implemented method according to claim 1 further includes: Access a cross-tenant library that maps the permission rights of the second tenant's service application features to the user identified in the user token, wherein the cross-tenant policy is determined based on the permission rights of the second tenant's service application features mapped to the user associated with the user token.

5. The computer-implemented method according to claim 1, wherein, The directory service application is configured to manage security permissions for users of the service application. Wherein, the first tenant refers to the first group of users of the first organization, and the second tenant refers to the second group of users of the second organization.

6. The computer-implemented method according to claim 1, wherein, The service application includes a communication application, wherein the second feature of the second tenant of the service application includes a second communication channel of the communication application, and wherein the request indicates access to the second communication channel of the communication application.

7. The computer-implemented method according to claim 1, wherein, The service application includes a file-sharing application, wherein the second feature of the file-sharing application includes a file storage device, and wherein the request indicates access to a file on the file storage device.

8. The computer-implemented method according to claim 1, further comprising: Receive the license value of the license attribute, the license value indicating the license level of the second feature of the second tenant of the service application for users other than the second tenant; Update the cross-tenant library, which maps the permissions of the second feature of the second tenant of the service application to the users of the first tenant of the service application; as well as The identity object is updated based on the updated cross-tenant library.

9. A computing device, comprising: processor; as well as A memory for storing instructions that, when executed by the processor, configure the device to: Receive a user token from the client device that has registered with the first tenant of the service application on the server. The user token is provided to the client device by the directory service application after the client device has been verified. The client device receives a request to access a second feature of a second tenant of the service application, wherein the second feature of the second tenant of the service application is separate from the first feature of the first tenant of the service application, and the second feature is accessible only to devices registered with the second tenant of the service application. The request is authenticated by verifying the user token from the client device. In response to verifying the user token, the cross-tenant policy of the service application for the second tenant is determined based on the user token through the following operations: Access cross-tenant license mapping; as well as Identify cross-tenant API metadata associated with the second tenant from the cross-tenant license map, the cross-tenant API metadata indicating cross-tenant access license rights for the second tenant; as well as An identity object is formed at the server based on the cross-tenant policy. The identity object includes a permission value of a permission attribute, which identifies the access level of the client device to the second characteristic of the second tenant of the service application. The identity object identification includes: a user identifier associated with the user token, a first tenant indicating a family tenant of the user associated with the user identifier, a second tenant indicating a resource tenant of the user associated with the user identifier, the service application, and the authorized access rights to the service application of the second tenant.

10. The computing device according to claim 9, wherein, The instructions also configure the device as follows: Provide the identity object to the service application associated with the second tenant; Determining the permission value of the permission attribute in the identity object indicates that the client device is authorized to access the second feature of the second tenant of the service application; as well as In response to determining that the permission value of the permission attribute in the identity object indicates support for the client device's access to the second feature of the second tenant of the service application, the client device is allowed to access the second feature of the second tenant of the service application.

11. The computing device according to claim 9, wherein, The instructions also configure the device as follows: Access a cross-tenant library that maps the permissions of the service application features of the second tenant to users of the first tenant, wherein the cross-tenant policy is determined based on the permissions of the service application features of the second tenant that are mapped to the first tenant.

12. The computing device according to claim 9, wherein, The instructions also configure the device as follows: Access a cross-tenant library that maps the permission rights of the second tenant's service application features to the user identified in the user token, wherein the cross-tenant policy is determined based on the permission rights of the second tenant's service application features mapped to the user associated with the user token.

13. A non-transitory computer-readable storage medium, the computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to perform operations including: Receive a user token from the client device that has registered with the first tenant of the service application on the server. The user token is provided to the client device by the directory service application after the client device has been verified. The client device receives a request to access a second feature of a second tenant of the service application, wherein the second feature of the second tenant of the service application is separate from the first feature of the first tenant of the service application, and the second feature is accessible only to devices registered with the second tenant of the service application. The request is authenticated by verifying the user token from the client device. In response to verifying the user token, the cross-tenant policy of the service application for the second tenant is determined based on the user token through the following operations: Access cross-tenant license mapping; as well as Identify cross-tenant API metadata associated with the second tenant from the cross-tenant license map, the cross-tenant API metadata indicating cross-tenant access license rights for the second tenant; as well as An identity object is formed at the server based on the cross-tenant policy. The identity object includes a permission value of a permission attribute, which identifies the access level of the client device to the second characteristic of the second tenant of the service application. The identity object identification includes: a user identifier associated with the user token, a first tenant indicating a family tenant of the user associated with the user identifier, a second tenant indicating a resource tenant of the user associated with the user identifier, the service application, and the authorized access rights to the service application of the second tenant.

Images