CN115698998A

CN115698998A - Secure resource authorization for external identities using remote subject objects

Info

Publication number: CN115698998A
Application number: CN202180039222.2A
Authority: CN
Inventors: C·P·R·达萨里; M·亚林; D·乔杜里; J·A·斯泰曼
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2020-05-29
Filing date: 2021-04-22
Publication date: 2023-02-03
Also published as: US20240114033A1; US20230121372A1; US20210377276A1; US11570181B2; US11888856B2; EP4158518A1; WO2021242454A1

Abstract

A method for secure resource authorization of an external identity using a remote subject object is performed by a system and device. An external entity creates a user group and defines the rights to the secure resources of all entities as a set of rights for the group. An immutable access template with permissions and an access policy for the secure resource are provided to all entities for approval. After approval, a remote subject object is created in the owner directory according to the rights and access policies. The remote principal, being a member of the group, requests access to the owner domain via the interface using the outside-domain credential. The identity of the remote principal is verified against the remote principal object by the token service. Validation results in the generation and issuance of a token with enumeration rights to the remote principal interface, thereby affecting redirection of access to secure resources.

Description

Secure resource authorization for external identities using remote subject objects

Background

Owners of data resources typically allow external identity access to their data resources for various reasons, such as collaboration, technical support, and so forth. One practice of external identity authorization and access is for the data resource owner to add an entry in its directory for a particular external identity to support login access, while other practices include variations of guest credential implementations that also include owner directory entries with limited permissions specific to the data resource to be accessed. In each case, however, the owner of the data resource defines the rights and is able to alter the type of access allowed and the data resource that the external identity can access.

Disclosure of Invention

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. 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.

A method for secure resource authorization of an external identity using a remote subject object is performed by a system and device. An external entity creates a group of users from within its domain and defines the rights of the owner entity of a different domain to a secure resource as a set of rights to the group. The access template with permissions and the access policy for the secure resource are provided to all entities for approval. Rights and access policies are immutable by all entities. When the owner entity grants access, a remote subject object is created in the owner directory according to the rights and access policy. The remote principal, being a member of the group, requests access to the owner domain via the user interface using the outside-domain credentials. The claims of the remote principal are verified against the remote principal object by the token service. Verification of resource access rights of the remote principal causes a token with enumeration rights to be generated and issued to the user interface of the remote principal, thereby affecting redirection of the user interface to access the secure resource.

Further features and advantages, as well as the structure and operation of various examples, are described in detail below with reference to the accompanying drawings. It is worthy to note that these concepts and technologies are not limited to the specific examples described herein. The examples presented herein are for illustration purposes only. Other examples will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

Drawings

The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present application and, together with the description, further serve to explain the principles of the embodiments and to enable a person skilled in the pertinent art to make and use the embodiments.

FIG. 1A illustrates a block diagram of a system for secure resource authorization of an external identity using a remote subject object, according to an example embodiment.

Fig. 1B illustrates a block diagram of a cloud-based system for secure resource authorization of an external identity using a remote principal object, according to an example embodiment.

FIG. 2 illustrates a block diagram of a computing system configured for secure resource authorization of an external identity using a remote subject object, according to an example embodiment.

FIG. 3 shows a block diagram of a system with links and permissions for remote subject objects, according to an example embodiment.

FIG. 4 illustrates a flow diagram for secure resource authorization of an external identity using a remote subject object, according to an example embodiment.

Fig. 5 shows a flowchart of an embodiment of a flowchart for secure resource authorization of an external identity using a remote principal object of fig. 4, according to an example embodiment.

FIG. 6 illustrates a token for secure resource authorization of an external identity using a remote principal object, according to an example embodiment.

FIG. 7 illustrates a flow diagram for secure resource authorization of an external identity using a remote principal object, according to an example embodiment.

Fig. 8 illustrates a group as a data structure for secure resource authorization of an external identity using a remote principal object, according to an example embodiment.

FIG. 9 illustrates a flow diagram for secure resource authorization of an external identity using a remote principal object, according to an example embodiment.

FIG. 10 illustrates a flow diagram for secure resource authorization of an external identity using a remote principal object, according to an example embodiment.

FIG. 11 illustrates a flow diagram for secure resource authorization of an external identity using a remote principal object, according to an example embodiment.

FIG. 12 illustrates a block diagram of an example mobile device that can be used to implement embodiments.

FIG. 13 illustrates a block diagram of an example computing device that can be used to implement embodiments.

Features and advantages of embodiments will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference characters identify corresponding elements throughout. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

Detailed Description

1. Introduction to

The following detailed description discloses numerous examples. The scope of the present application is not limited to the disclosed embodiments, but also includes combinations of the disclosed embodiments and modifications of the disclosed embodiments.

References in the specification to "one embodiment," "an embodiment," and "example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

In the discussion, unless otherwise specified, adjectives such as "substantially," "approximately," and "approximately" modify a condition or relational characteristic of one or more features of an embodiment of the disclosure, as understood to mean that the condition or characteristic is defined to be within an operationally acceptable tolerance of the embodiment for its intended application.

Moreover, it should be understood that the spatial descriptions (e.g., "above," "below," "upper," "left," "right," "lower," "top," "bottom," "vertical," "horizontal," etc.) used herein are for illustrative purposes only and that actual implementations of the structures and figures described herein may be spatially arranged in any orientation or manner. Furthermore, the drawings may not be to scale and the orientation or organization of the elements of the drawings may vary in embodiments.

A number of exemplary embodiments are described below. It is noted that any section/subsection headings provided herein are not limiting. Embodiments are described in this document, and any type of embodiment may be included in any section/subsection. Moreover, embodiments disclosed in any section/subsection may be combined in any manner with any other embodiments described in the same section/subsection and/or in a different section/subsection.

The second section below describes an example embodiment of secure resource authorization for external identities using remote subject objects. The third section below describes example mobile and computing devices that may be used to implement features of embodiments described herein. Additional examples and advantages are described in the fourth section below, and some conclusive comments are provided in the fifth section.

2. Example embodiments for secure resource authorization of external identities using remote subject objects

A method for secure resource authorization of an external identity using a remote subject object is performed by a system and device. Various embodiments herein relate to cloud-based systems such as, but not limited to, cloud services, cloud hosting leases, directories, code repository systems, file sharing services, and the like, as well as enterprise systems and other domain systems through which client/user systems and/or devices access secure data resources while performing tasks and, according to embodiments, enforce secure resource authorization for external identities using remote principal objects (also referred to herein as "RPOs").

To perform tasks involving secure data resources in a domain that is remote to itself, a user or principal needs to access the domain of secure data resources. As the size of large enterprise operations scale up, this demand is far beyond the reach of a few users/principals, developing into several teams or groups that may have multiple shifts, trainees, etc. For example, to provide support for certain applications and services, a provider may hire hundreds or thousands of engineers in platform applications and services, which are distributed across multiple geographic locations, including the provider. Further, for each task, several support engineers, technical consultants, and/or product group engineers may be assigned and/or involved in their execution. Access to secure data resources is also important in the context of collaborative tasks between domains.

Embodiments herein enable a remote user to be represented as a remote principal to access secure data resources in the domain of its owner to perform tasks.

A domain, as used herein, generally refers to a physical and/or logical boundary under control of an entity in which data resources are securely stored and access thereto requires domain-specific credentials, and in embodiments also includes sub-domains and/or the like. Exemplary non-limiting domains include, but are not limited to, web domains, leases of hosted cloud platforms, cloud service providers, enterprise systems, and/or any other type of network or system that requires domain-specific credentials for authentication and access. A tenant is a particular type of domain that is a representation of an organization in a cloud or identity platform. The domain of a tenant in the cloud platform is its tenancy, where the tenant registers and manages applications, stores data/files, accesses services, and the like. In an embodiment, a remote principal is an individual, a group of people, application(s), service(s), etc., or any combination thereof, belonging to a remote or external domain, that intends to access secure data resources in its owner's domain for performing tasks. A data resource or a secure data resource is a configuration setting of data, information, files, documents, services/applications and/or the like that resides securely in one domain and is not easily accessible to the principals of the other domain without the owner domain's credentials, and an Entitlement Lifecycle Manager (ELM) service is configured to manage entitlement grants for the secure data resource, and its lifecycle.

The described embodiments are also capable of capturing the rights to be granted to these remote users/remote principals. The remote principal and the rights it requests are defined (e.g., in a template generated and provided by the remote domain entity or domain of the data resource to be accessed, or as other data/information representation than a template) and provided to a directory of resource owner domains. Where the provider provides customer support, in embodiments the provider defines secure data resources that they need to access in order to provide appropriate support for the customer to complete the task. Embodiments provide the ability for data resource owners to approve or deny access requests per task. However, in some embodiments, the data resource owner may not have the ability to modify the requested set of permissions, as such an ability may prevent the remote principal from providing appropriate support (e.g., if the data resource owner deletes the required permissions), or expose the remote principal and/or its organization to unnecessary risk (e.g., if the permissions granted by the data resource owner exceed the required permissions). To this end, in embodiments, the request to expand or contract the set of access permissions comes from the organization of the remote principal, rather than the data resource owner. However, the data resource owner retains control over whether access rights are granted and when they may be revoked.

Accordingly, embodiments provide that the lifecycle of such access and the permissions sought by the remote principal are tightly controlled by the access policy and are immutable within the domain of the data resource owner. In an embodiment, at least two conditions control access to the data resource: the remote principal is a member of a group corresponding to a task created in the domain of the data resource owner, and the remote principal object exists in the domain of the data resource owner that points to the group. According to an embodiment, these conditions are based on the lifecycle of the access. For example, remote principal membership in a group created for data resource access is managed by an Entitlement Lifecycle Manager (ELM) service access packet created in the remote principal domain. When the access policy expires, the remote principal(s) are deleted from the group. This ensures that the remote principal(s) do not gain access to the data resource outside of the specified policy. In the same way, the creation and deletion of remote subject objects in the domain of the secure data resource owner is also managed by the ELM service. When access to a data resource is granted in an owner domain, an auto-grant access policy is created in this domain and corresponding access packets are linked to the policy. The access policy is responsible for expiring entitlement entitlements, and the ELM service is configured to clean up remote subject objects and their links. In embodiments, the access policy itself is cleared when a task is closed or completed, or when approval to access a data resource is withdrawn from the owner domain via a lockbox application/service or other equivalent application/service or the like (e.g., via an ELM service or other trusted service). In other words, ELM use in the context of remote principals and remote principal objects increases system utilization for accessing secure data resources, at least because accesses can be reliably and quickly added and/or deleted without having to track any remote user lists in the remote domain, or any specific access grant/permission lists that exist for remote principal objects in various workloads in the resource owner domain. More detailed information regarding ELM service and lockbox utilization is provided below.

As a non-limiting example, a cloud-based platform with services utilizes a remote subject object to allow users/members (such as partners or service providers) of the second domain to access secure data resources of tenants in the first domain. As another example, an enterprise network owner of a secure data resource allows a remote third party to access the secure data resource via a remote subject object. For example, embodiments enable the creation of remote principal objects in a directory of secured data resource owners and the assignment of authorization claims to remote principals linked via the remote principal objects based on access policies and permissions defining secured data resource access to the remote principals. In an embodiment, a remote principal is any principal, including users, applications, etc., from any identity provider (IdP), tenant, or domain (first or third party), trusted by the current IdP, such as a home tenant/domain/host. The remote principal object points to an authorization claim that is verified by incoming tokens from the remote IdP to issue a new token corresponding to the secure data resource requested at the current IdP. Embodiments herein describe the ability to assign authorization to any type of remote principal and to establish strong management of authorization and access due to the fact that it is a remote principal.

In the context of lease and support, a customer tenant of a cloud-based services platform may require the assistance of other tenants or support engineers in the domain of the platform. For example, to diagnose and solve customer problems with domain identification problems, support engineers need to review and analyze customer directory data and service telemetry to obtain solutions that can be presented to the customer. A customer problem with identity functionality may involve multiple services and/or products. Embodiments herein enable support engineers to access and browse client catalog data to quickly diagnose problems and provide solutions. Further, embodiments provide transparency when a support engineer accesses customer data for business reasons (such as providing support). More generally, the remote principal object enables the service to authorize requests by external users to access secured data resources using its existing authorization framework without requiring the implemented security system or the secured data resources themselves to have prior knowledge of specific, personally identifiable information about each remote principal that may access the secured data resources. That is, such information is not provided in the resource owner's directory or in the user profile store of the data resource itself. This preserves the ability of the outside domain to manage its own list of remote users/remote principals that are authorized to manage secure data resources.

To this end, embodiments provide for secure access to customer data, where access to customer data is user/owner based, approved by the customer, scoped to specific task needs, and automatically revoked upon expiration of a time limit, customer intent, and/or end of support case. As part of the solution provided in the examples described herein, certain features related to the projection of identities in the directory are used to meet the requirements of the customer support scenario. That is, identity projection provides a basic construct that allows applications at the level above it to rely on the same authentication and authorization model that they are built to understand, rather than injecting special case logic for various purposes. Embodiments also allow for extension to partners and solve problems associated with enterprise-to-enterprise collaboration at the organizational level, unlike at the individual user level, to access secure data resources. Thus, a third party, such as a support engineer, can access support tools and data resources, including customer-oriented product experiences hosted for customers corresponding to the support case the support engineer is handling, such as via a portal or other User Interface (UI), for example, using their primary tenant/domain identity (e.g., < thirdpartylame >. https:// portal. < cloudhostname >. Com/< customemame >. Com. In embodiments herein, a portal refers to a UI of a web page, service, or application that acts as a gateway or framework that controls access to resources, other web pages, services, or applications, etc. of a domain or sub-domain that is opened and accessed via credentials, although other types of portals are also contemplated herein, as will be appreciated by those skilled in the relevant art(s) having the benefit of this disclosure.

It should also be understood that the example references to lease, customer, and support are for illustration and explanation purposes only and are not intended to be limiting. Embodiments herein may be extended to collaboration, guest access, etc. between different users and owners of secure data resources between any two different domains. In embodiments herein, for the sake of brevity, a secure data resource may be referred to as a data resource. As used herein, a domain generally refers to a physical and/or logical boundary under control of an entity within which data resources are securely stored and to which access requires domain-specific credentials, and in embodiments also includes sub-domains and/or the like. Exemplary, non-limiting domains include, but are not limited to, web domains, leases to host cloud platforms, cloud service providers, enterprise systems, and/or any other type of network or system that requires domain-specific credentials for authentication and access.

Embodiments herein provide a solution to the problem of secure resource authorization of external identities through the use of remote principal objects. These and other embodiments are described in further detail in this section below in conjunction with the figures and the sections/subsections that follow.

The systems, devices and apparatus may be configured in a number of ways for authorizing a remote principal of a second domain to access secure data resources in a first domain. For example, fig. 1A and 1B will now be described. According to example embodiments, fig. 1A shows a block diagram of a system 100A, and fig. 1B shows a block diagram of a cloud-based system 100B, each configured for secure resource authorization of an external identity using a remote principal object.

As shown in fig. 1A, system 100A includes user device(s) 116, service platform 102, first domain master 104 and second domain master 106, presence service platform, first domain master and/or second domain master. Further, according to embodiments, any combination of the systems and/or components shown in fig. 1A are present in system 100A.

In embodiments, network 114 includes different numbers and/or types of communication links for connecting devices, platforms, and hosts/servers, such as, but not limited to, the internet, wired or wireless networks and portions thereof, peer-to-peer connections, local area networks, enterprise networks, cloud networks, and so forth.

The user device 116 in the different embodiments is any number, type, or combination of computing devices or computing systems, including terminals, personal computers, laptops, tablets, smartphones, personal digital assistants, servers, gaming consoles, and the like, including internal/external storage devices for performing the functions/operations described herein, for machine learning, for secure resource authorization of external identities using remote subject objects, and for performing client functions/operations associated with the embodiments (e.g., access to a domain master, including data resources thereof, through user credentials). In an embodiment, user device 116 also includes additional components (not shown for brevity and illustrative clarity), including, but not limited to, components and sub-components of other devices and/or systems herein.

The service platform host 102 includes one or more server computers or computing devices, which in embodiments may include one or more distributed or "cloud-based" servers, as described below. In embodiments, the service platform host 102 includes a local server in addition to or instead of a cloud-based server. Various systems/devices herein, such as the service platform host 102, are configured to provide services, such as business services and/or applications, used by the first domain host 104 and/or to perform functions/operations for authentication, such as IdP, for secure resource authorization of external identities using remote principal objects. For example, the service platform host 102 includes an IdP service configured to verify an identity of a user of the user device 116 associated with the second domain of the second domain host 106, and issue a token or the like to access a secure resource, e.g., the data resource 112 and/or the directory 110 of the first domain host 104, using a remote principal object, as further described herein.

The first domain master 104 includes one or more server computers or computing devices, such as a local server, in addition to the cloud-based servers associated with the first domain. As described above, the first domain master 104 also includes data resources 112 and a directory 110. The data resources 112 include one or more secure data resources such as, but not limited to, file/file systems, documents, databases, repositories, calendars, and/or other applications/information, including configuration information for applications and services, in embodiments, the directory 110 includes identity data and information (e.g., including access rights, credentials, etc.) for users associated with the first domain of the first domain master 104, and the generated RPO is stored in the directory 110. In an embodiment, the identity data and information in directory 110 comprises a portion of data resource 112, and according to an embodiment, applications and/or services of the intended domain and data/information related thereto are also data resources herein. The data resources 112 and the catalog 110 are securely stored at or associated with the first domain master 104 and are accessible through credentials associated with the first domain of the first domain master 04 (e.g., by a user of the user device 116 having such first domain credentials), and in some embodiments, through IdP of the service platform 102. The data resources 112 and the directory 110 are not accessible through authentication of the first domain master 104 using credentials of the second domain master 106 (e.g., by a user of the user device 116 having such second domain credentials). In an embodiment, the catalog 110 stores the generated RPO by which the user with the second domain credential is granted access to the data resource 112 and/or the catalog 110, e.g., idP using the service platform 102.

Second domain master 106 includes one or more server computers or computing devices, such as local servers, in addition to the cloud-based servers associated with the second domain. A user associated with the second domain can access the second domain master 106 through the user device 116 having the second domain credentials. Second domain master 106 is configured to generate a rights template via rights template generator 108. For example, a user in the second domain uses the rights template generator 106 to generate a rights template that defines the access rights/authorizations (e.g., reads, writes, etc.) required for a given data resource of the data resources 112, which includes identity data and information in the catalog 110, according to an embodiment. The rights template generated in the second domain is immutable in the first domain; that is, a user in the first domain cannot change aspects of the rights or other data and information in the rights template. The permission template is used to generate access groups including groups to access data resources, membership permissions for data resources, and the like.

When provided to the first domain master 104, the owner, administrator, or the like of the data resource in the first domain specified in the permission template accepts/approves or does not accept/approve the permission template, and if so, then an RPO is generated, as described below, that allows a user of the second domain to access the data resource in accordance with at least the permissions specified in the permission template.

Turning now to FIG. 1B, the system 100B is a cloud-based embodiment of the system 100A of FIG. 1A. As shown, the system 100B includes a cloud platform 118. In an embodiment, cloud platform 118s is a cloud-based platform, such as Microsoft Corporation of Redmond, washington

The platform may be accessible to a user of user device 126 via a network (not shown for clarity and brevity of illustration).

User device 126 can be any type and/or number of user devices, such as devices similar to those described for user device 116 in fig. 1A, and can correspond to users having credentials for different domains, such as different tenancies in cloud platform 118.

A tenant is a representation organized in a cloud or identity platform. The domain of a tenant in the cloud platform is its tenant in which the tenant registers and manages applications, stores data/files, accesses services, and the like. Tenants can deploy custom conditional access and tenant restrictions for respective tenants. Tenants are granted a dedicated instance of a catalog for their lease, each tenant being distinct from the other tenants and having its own identity representation and application registration. Registration within a tenant allows authentication only from accounts within the tenant to access secure data resources, while also allowing authentication from all tenants. In the context of RPO herein, access rights of all tenants are not assumed/used.

For example, cloud platform 118 includes tenant a 122 and tenant B/partner 124, although in embodiments different numbers of tenants are contemplated. In an embodiment, tenant a 122 corresponds to a first domain of system 100A and tenant B/partner 124 corresponds to a second domain of system 1000A. The user of the user device(s) 126 with the credentials of tenant a 122 is allowed to authenticate the lease and access data, information, services, applications, etc. of the cloud platform 118, e.g., services/applications 120 (also referred to herein as "services/applications" 120) allowed or instantiated for tenant a 122. Likewise, the user of the user device(s) 126 with the credentials of tenant B/partner 124 is allowed to authenticate the lease and access data, information, services, applications, etc., e.g., services/applications 120 of the cloud platform 118, allowed or instantiated for tenant B/partner 124. However, direct access to another tenant's domain using one tenant's user credentials is not allowed.

In embodiments, the authentication is performed via the catalog 128 of the cloud platform 118. The catalog 128 includes identity data and information that allows users to authenticate respective leases. For example, tenant a 122 and tenant B/partner 124 are each assigned or instantiated their own of directories 128 that are not accessible without credentials for the respective tenants or without using the RPO described herein. Thus, in embodiments, the directories in directory 118 store generated RPOs that allow access, e.g., specific and/or limited access, to data resources and directory data/information of entities outside the domain of the directory. In an embodiment, directory 128 is a cloud-based directory service, such as Microsoft Corporation of Redmond, washington

Active

Although the embodiments are not limited.

In an embodiment, the cloud platform 118 includes one or more distributed or "cloud-based" servers. That is, the cloud platform 118 is a network or "cloud" implementation of applications and/or services in a network architecture/cloud platform. According to an embodiment, a cloud platform includes a set of networked computing resources, including servers, routers, and the like, that are configurable, sharable, provide data security, and are accessible over a network, such as the internet. Cloud applications/services are configured to run on these computing resources, typically on top of an operating system running on the resources, for accessing entities of the applications/services locally and/or over a network. As described above, a cloud platform such as cloud platform 118 is configured to support multi-tenancy, where cloud platform-based software services a plurality of tenants, each tenant including one or more users that share common access to certain software services and applications of cloud platform 118, as described herein. In addition, the cloud platform is configured to support hypervisors implemented as hardware, software, and/or firmware that run virtual machines (emulating computer systems, including operating systems) for tenants. The hypervisor provides a virtual operating platform for the tenant.

In embodiments, the systems, apparatuses, and devices are configured in various ways to secure resource authorization of external identities using remote subject objects. Such as a graph. 2, 3 and 4 will now be described in this context.

Referring initially to FIG. 2, a block diagram of a system 200 for secure resource authorization of an external identity using a remote principal object is shown in accordance with an example embodiment. The system 200 is illustrated and described as being configured as an embodiment of the system 100A of FIG. 1A and/or the system 100B of FIG. 1B. The system 200 is described as follows.

System 200 includes a computing system 202, which as described elsewhere herein, or as otherwise known, is any type of server or computing system, including but not limited to cloud-based systems, local servers, distributed network architectures, and the like. As shown in fig. 2, the computing system 202 includes one or more processors ("processors") 204, one or more of memory and/or other physical storage ("memory") 206, and one or more network interfaces ("network interfaces") 230.

Computing system 202 also includes service/application 208 (also referred to herein as "service/application" 208), lease 224, and Security Token Service (STS) 232, service/application 208 being an embodiment of service platform 102 and/or service/application 120 in fig. 1A and 1B, respectively, lease 224 being an embodiment of first domain host 104 and/or second domain host 106 of fig. 1A and/or tenant a 122 and/or tenant B/partner 124 of fig. 1B. STS 232 is a trusted third party token service that, in various embodiments, comprises a portion of service platform 102 and/or service/application 120 of FIGS. 1A and 1B, respectively, comprises a separate service in system 200, or comprises a portion of service/application 208.

The processor 204 and the memory 206 may be any type of processor circuit(s) and memory(s), respectively, described herein and/or as would be appreciated by one of ordinary skill in the relevant art having the benefit of the present disclosure. The processor 204 and memory 206 may each include one or more processors or memories, different types of processors or memories (e.g., at least one cache for query processing), remote processors or memories, and/or distributed processors or memories. The processor 204 may be a multi-core processor configured to execute multiple processing threads simultaneously. Processor 204 may include circuitry configured to execute computer program instructions, such as but not limited to an embodiment of service/application 208 and/or STS 232, including one or more of its components described herein, which may be implemented as computer program instructions, as described herein.

Memory 206 includes volatile storage, such as Random Access Memory (RAM) and/or persistent storage, such as a hard drive, non-volatile RAM, and/or the like, for storing or configured to store computer program instructions/code for secure resource authorization of an external identity using a remote subject object as described herein, as well as, in various embodiments, other information and data described in this disclosure, including but not limited to service/application 208 and/or STS 232, including one or more components described herein and/or the like. In some embodiments, the memory 206 also includes storage of data resources and/or permission templates (e.g., in a template directory). For example, according to a cloud-based embodiment for the tenant of lease 224, a directory for the domain is stored in memory 206.

Network interface 230 can be any type or number of wired and/or wireless network adapters, modems or the like configured to enable system 200 (including computing system 202) to communicate with its components within the system, as well as with other devices and/or systems over a network, such as between computing system 202 and other devices, systems, hosts, system 100A in FIG. 1A and/or system 100B in FIG. 1B, over a network, such as network 114.

System 200 also includes additional components (not shown for brevity and illustrative clarity), including, but not limited to, components and sub-components of other devices and/or systems herein, as well as the description below with respect to the figures. 12-13, according to the examples.

Lease 224 includes tenant a226 and tenant B/partner 228 (or "tenant B/P228" herein), as shown by way of non-limiting example, although in embodiments any number of tenants may own the lease. Each tenant of tenants 224 is associated with a corresponding catalog as described herein, which stores identity data and information about the tenant user through which authentication of the tenant domain is performed, as will be described in further detail below. In an embodiment, a partner is a tenant that has a particular association or relationship with a platform host. For example, as described herein, a support center with support engineers performing tasks is considered a partner. In an embodiment, the partner's domain is a domain of the platform, a sub-domain of the platform, a domain associated with the platform, and the like. It is contemplated herein that in embodiments, tenants and computing resources are loosely coupled, with multiple tenants hosted on a single computing resource, or tenants hosted between multiple computing resources, or in any other implementation relationship combination.

Service/application 208 and STS 232 are configured to perform secure resource authorization of an external identity using a remote principal object, as described herein, to enable access to a data resource by a user of the data resource who owns a domain/lease other than the domain/tenant. As shown, services/applications 208 include a group controller 210, an access controller 212, an Entitlement Lifecycle Manager (ELM) 214, one or more portals 216 ("portals" 216), a directory 218, and a lockbox 222. The group controller 210 is configured to determine whether a principal is allowed to be a member of the group, or indeed a member of the group, for accessing the data resource when performing the task, and the access controller 212 is configured to generate the group, the permissions associated with the data resource, and an access policy for the permissions. Portal 216 is configured to provide users with services, applications, domains, and/or similar interfaces described herein, and directory 218 is configured to store domain users' identity data and information (e.g., tenant a226 and tenant B/P228 of tenant 224), including but not limited to permissions and access credentials, as well as RPOs described herein. Lockbox 222 is configured to provide a secure interface that an owner of the data resource can access, wherein the owner can view and accept/deny permission requests for the data resource (in embodiments, lockbox 223 comprises a portion of portal 216), ELM214 is configured to manage entitlement grants and its lifecycle, including group member requests with group controller 210 and permission approval request interfaces of lockbox 222. In an embodiment, ELM214 and access controller 212 comprise portions of a single service or application, e.g., access controller 212s comprises a portion of ELM 213. STS 232 is configured to issue tokens to members of the group to which the RPO points with the data resource rights specified in the RPO.

Although shown separately for purposes of illustration and conceptualization, in embodiments, one or more portions of services/applications 208 and/or STS 232 described herein are instantiated to and/or within tenant 224. That is, tenants, such as tenant A226 and/or tenant B/P228, may include instances of one or more portions of their own services/applications 208 and/or STSs 232 to perform their functions and services.

More detailed information regarding service/application 208 and STS 232 components is provided herein, including a description of the figures below.

Referring now to fig. 3, a block diagram of a system 300 with links and permissions for remote subject objects ("RPOs") is shown, according to an example embodiment. The system 300 is described as follows.

The system 300 includes a first domain302 and a second domain 304. First domain 301 and second domain304 are embodiments of any two different domains, as described herein, represented as hardware platforms, logical boundaries, software systems, etc. (e.g., tenants of tenant a226 and tenant B/partner 228 of system 200 in figure 2, enterprise networks, web domains, etc.). That is, a user associated with the first domain302 has access credentials, e.g., userl @ < FirstDomain302>, of the domain specifically associated therewith. com which enables and allows authorization of the first domain302 by the user, including data resources therein. Likewise, a user associated with the second domain304 has access credentials, e.g., user2@ < second domain304>, associated specifically with that domain. com that enables and allows authorization of the second domain304 by the user, including data resources therein. In the context of a cloud platform.

In the illustrated embodiment, the first domain302 has a directory 306 and the second domain304 has a directory 316, although any number of directories may exist and/or be allocated.

Directories

306 and 316 contain identity data and information, including but not limited to access rights, credentials, etc., of users associated with first domain302 and second domain304, respectively. Further, the generated RPO, such as exemplary RPO308, is stored in a tenant directory where it is desirable to allow external entities (e.g., other tenants, individuals, and/or any other entities outside of a particular domain) to access secure data resources, according to an embodiment. As previously mentioned, the identity data/information and any other information stored in the directory may comprise a portion of the domain data resources that own or allocate and manage the directory. In some embodiments,

directories

306 and 316 are tenant-specific directories to directory 218 of system 200 in fig. 2.

The second domain304 has a group 318 associated therewith. The group 316 is a data structure that, in embodiments, includes one or more task identifiers, at least one data resource associated with the task, and/or an identity of one or more users (or members) of the second domain304 that specify performing the task.

Remote subject object 308 in directory 306 of first domain302 represents a new type of directory object, of the type "group" as described herein. In an embodiment, RPO308 is a data structure that includes metadata and "links" for defining permissions associated with the bodies of applications and data resources. For example, as shown, the group 318 includes one or more members of the second domain304 that are remote entities of the first domain 302. The RPO308 in the first domain 305 points to a group 318 stored in the second domain 304. The RPO 309 illustratively includes three "links" defining three different permissions PI, P2 and P3, which are application permissions in embodiments, for respective secure data resources and/or applications in the first domain 302: a first secure data resource (SDR 1) 310, a second secure data resource (SDR 2) 312 and a third secure data resource, and the deterministic rights defined by these links are added to the token's claims of scope of rights.

The RPO, such as RPO308, includes attributes, such as data structures. For example, in an embodiment, the RPO has one or more of the following attributes: an object identifier ("ID" or "ID"), a type, a remote object ID, a remote domain ID, a display name, a source, an owner, a purpose, and the like. The object ID describes a unique ID of the RPO, and the type describes the type of object (e.g., a "group") that the RPO points to in a remote domain (e.g., the second domain 304). The remote object ID is an identifier of the object in the remote domain that the RPO points to, and the remote domain ID is an identifier of the remote domain in which the group is located. The display name is the name of the object in the remote domain that is pointed to and copied when the RPO is created, and there is no need to maintain synchronization if the display name of the object in the remote domain changes. The sourced by attribute is a unique ID that represents the source used to create the RPO, e.g., the ELM packet identifier generated by access controller 212 of fig. 2. The owner attribute is a globally unique ID representing an application ID of a service managing the RPO, such as an ELM application ID, for example, the ID of ELM 214. According to an embodiment, when populating an RPO with this attribute, the RPO cannot be deleted by any other application, nor its link modified, except for the applications listed for the attribute. The purpose attributes describe the purpose or task for which the RPO is created to facilitate querying the RPO for a given purpose or task, such as supporting cases, workloads, subscriptions, document collaboration, hosting service providers, and the like.

In an embodiment, the entitlements for the resource and application may include a resource/application ID and a claim derived from the authority to link the RPO to be included in the token. The right may include a resource ID "graph API" (application programming interface) and the statement of "direct. As non-limiting examples, finer grained rights and entitlements are also contemplated herein. In addition, an administrator assertion may be included in the token. Each task may require a different set of permissions based on the scope of data that the remote domain user requires access to or needs access to the data resource to address the particular task. The scope of the data may be determined based on task topics and/or the like.

In some embodiments, the set of permissions granted is limited, e.g., limiting enumeration of all objects, e.g., data objects with End User Identification Information (EUII). In such a case, queries related to such data may return a limited set of results that partially match. Furthermore, in embodiments, reading of strong authorization details is limited. For example, security issues for password resets, registering phone numbers, and the like are considered restricted access. In contrast, in embodiments, an indication of the presence of this type of data is provided, which does not reveal the actual data content. Furthermore, in embodiments, access to objects such as personal profile photos or other objects is restricted. However, in some embodiments, access to the portion of the identification information may be included in the permissions based on an agreement between the owner and the visitor of the data resource.

In an embodiment, the RPO and its links are created, read, updated, or deleted by a single service or application, such as the ELM 214's graphical API, which has no User Interface (UI) available to view or manage the RPO. Further, as described above, the RPO attribute "owner" may fill in an application ID or service principal ID (e.g., the ID of the ELM214 service), and only allow a particular application/service to create or modify an RPO and its links, including deletions. That is, for some embodiments, for RPO, the only permission to control the owner/local domain (e.g., the first domain 302) is through the provision of an ELM access packet that can be revoked in the local domain to obtain authorization for the access packet and the corresponding remote principal. However, in this case, the RPO and its links will be cleaned up, deleted, or deleted by the ELM214 service. Further, ELM214 is configured to clear/delete RPOs and associated links, access packets, permissions, access policies, etc. after completing a task.

In summary, the RPO includes an entity mapping, where PRO in the data resource owner domain maps to a group in the user/remote principal domain and allows tokens to be issued to the user/remote principal while verifying membership in the group to which the RPO points. RPO permissions allow a user/principal to issue claims to a token according to a "link" defined for the RPO. In an embodiment of the RPO, there is no specific user/remote master footprint in the domain of the data resource owner that corresponds to the user/remote principal identity.

As described above with respect to fig. 1-3, embodiments herein provide secure resource authorization using an external identity of a remote subject object. The system 100A of fig. 1A, the system 100B of fig. 1B, the system 200 of fig. 2, and the system 300 of fig. 3 may be configured to perform these functions and operations. It is further contemplated that the above-described systems and components may be configured in any manner, in whole or in part, and that any portion of a given system may be combined in any manner, in whole or in part.

Fig. 4 will now be described in the context described above. FIG. 4 shows a flow diagram 400 for secure resource authorization of an external identity using a remote principal object, according to an example embodiment. In an embodiment, system 100A in fig. 1A, system 100B in fig. 1B, system 200 in fig. 2, and system 300 in fig. 3 operate according to a flow diagram 400. Further structural and operational examples will be apparent to those skilled in the relevant art(s) based on the following description. Although the components of flowchart 400 are shown separately for ease of illustration and description, such representation is non-limiting and the components are considered to be grouped, combined, etc. in any combination or structure. Flow diagram 400 is described below with respect to system 200 of fig. 2 and system 300 of fig. 3.

In flow diagram 400, various portions of system 200 as described above are represented as performing functions and operations for secure resource authorization on external identities using remote principal objects through catalog a468 of system 200 and/or catalog 306 of system 300 representing tenant a226, and through catalog 218 of system 200 (hereinafter "catalog B/P466") of tenant B/partner 228 and/or catalog 316 of system 300.

The flowchart 400 begins with step 402 in which a user device 470 associated with tenant a226 is authenticated to tenant 226. Authentication is performed using user credentials associated with the domain of tenant 227, and in embodiments authentication is performed via the tenant portal of portal 216. In an embodiment, step 402 is optional, wherein a user of user device 470 is authenticated via a different tenant portal (e.g., the portal of tenant B/P228) or via a system portal (i.e., a backup portal) of portal 216 in connection with task creation in step 404, e.g., for support tasks related to identity issues in directory A468, and requests tenant B/P228 as a support service. The back-up portal is configured to authorize the user of user device 470 the limited space in tenant B/P228 domain for creating tasks, e.g., in step 404, a support task is created based on the user domain credentials from tenant B/P228. That is, the tenant B/P228 or the IdP of the system 200 is configured to identify the user of the user device 470 for purposes of generating a task request via the portal 216. A reply is provided indicating the creation of the task in step 406.

In step 408, tenant B/P228 provides notification to access controller 212 to create the task, and according to an embodiment, access controller 212 will generate a task group and ELM group that defines group membership and defines the permissions required for data resources associated with the task to be accessed by the group member. For example, in an embodiment, a set of access groups for task execution is predefined in tenant B/P228 as a permission template, which has a specific version. These permission templates can be stored in a template directory of tenant B/P228, e.g., a designated portion of memory 206. When a task is created as described above, access controller 212 creates a group, e.g., group 318 in system 300, in directory B/P466 (of tenant B/P228) that corresponds to the task and defines a set of users or members that have access to the task in step 410. After the group is created, in step 412, the access controller 212 creates an ELM group grouping in directory B/P466 that governs the group member assignments. This group grouping includes custom policies assigned to it for governing approval of the authorization. The custom policy allows evaluation of rules for approving membership of a group, e.g., member is task owner, member is case partner, member is technical advisor in a specified area, etc.

In step 414, access controller 212 obtains the stored permission template from tenant B/P228 and checks in directory A468 of tenant A226 if there is a most recent access group (according to the defined permission template) corresponding to the task. If the access packet does not exist in directory a468 of tenant a226, the access packet is created therein and refreshed if the access packet is earlier than the current or most recent rights template version. The access packet includes specific rights to be assigned to a remote principal (i.e., group member) for accessing data resources associated with the task, which in embodiments may take various forms, such as, but not limited to, direct application scope assignment, built-in role assignment, and the like. Access grouping does not allow for custom role assignments, for example, because such assignments may vary from tenant to tenant, and there is no guarantee that the assigned permissions are constant in the task creation tenant domain. In step 416, the access controller 212 creates and assigns an access policy for the access packet (e.g., the right to access the data resource) stored in the directory a468 in step 414. The access policy represents a set of constraints on the rights/rights grant, such as expiring within a specified time (minutes, hours, days, etc.), requiring manual approval, approving when the incoming principal belongs to a certain group, and/or the like.

As described herein, the rights and policies governing access to a data object are immutable in all domains of the data object. All domains are only allowed to accept or deny access rights/policies defined and provided by the remote domain.

In step 418, a task is opened via tenant B/P device 472 and/or a user of tenant B/P228 with domain-specific credential authentication via an application or service of tenant B/P228. In step 420, tenant B/P228 returns the task details to tenant B/P device 472. In embodiments, the task details include, but are not limited to, the task type, the requesting member of tenant A226, the ID of tenant A226 or associated domain, other task-specific information, and/or the like. Based on the task details, the user of tenant B/P device 472 requests access to tenant A226's data resources from its own domain (tenant B/P228) via ELM214 in step 422. In embodiments, instances or portions of ELM214 are assigned to tenant B/P128 to implement such functions/operations. Thus, in step 424, ELM214 receives a request from tenant B/P228 for the user of tenant B/P device 472 to be granted membership to a group associated with the task, i.e., as the remote principal of the corresponding data resource, as created in step 410 above. ELM214 receives the domain credentials of the user/remote principal of tenant B/P228 and provides the credentials and user/remote principal ID to group controller 210 in step 426, group controller 210 being configured to determine whether the principal is allowed to be a member of the group, or indeed a member of the group, and whether it is allowed to access data resources while performing the task. The group controller 210 is configured to verify whether group membership exists or is allowed and return the verification to the ELM 214.ELM 213 then adds the user/remote principal to the group and notifies tenant B/P228 in step 428. Group member authentication allows the flowchart 400 to proceed to step 430, while an indication that the user/remote principal is not authorized as a group membership will prevent access to data resources in tenant A226.

It should be noted that when the group is created in step 410, the user/remote principal may have been granted group membership. In these embodiments, step 424 represents verification of the user/remote subject's group membership, and step 428 represents notification of confirmation of the user/remote subject's group membership.

It should also be noted that the functions and operations described above as being performed by access controller 212 may be performed by an instance of access controller 212 designated for tenant a226 or instantiated in tenant a 266, and in embodiments where access controller 121 includes a portion of ELM214, the functions and operations described above with respect to flowchart 400 of access controller 212 may be performed by an ELM214 instance designated or instantiated for tenant B/P228. It should also be noted that the following functions and operations performed by ELM 217 may be performed by ELM-214 instances designated or instantiated for tenant a 226.

In step 430, a request for data resource access approval is provided from tenant B/P228 to ELM214 on behalf of the user/remote principal, e.g., via approval of the data access packet and policy with permissions created in

steps

414 and 416. In an embodiment, then, in step 432, ELM214 provides a request for access group/permission approval to lockbox 222 associated with tenant a 226. The lockbox 222 is a secure application by which the user of tenant a226 is notified of the request via the UI at tenant a device 473 and can accept or reject the request in step 434. In embodiments, the notification identifies a task, a right, an access policy, and/or a group. However, in some embodiments, the notification does not identify a particular remote principal, i.e., an individual member of the group, thereby protecting its identity. In step 436, the results of the request of step 434 are returned from lockbox 222 to ELM 214. If a request for access grouping/permission approval is not granted, access to the data resource for performing the task will be denied. If approval is granted, access to the data resource will be allowed according to the permissions and access policy. In embodiments, particular implementations are also contemplated herein in which access management is not as strictly managed as described by flowchart 400 and ELM 214. For example, a data resource owner of a first domain may provide access to data resources in the first domain without performing an approval operation when adding or deleting members in a group of a second domain. In this case, access rights are granted to the group by the data resource owner, and membership of the group can be managed entirely in the second domain without any additional approval. In the context of flowchart 400, approval of group access to the data resource may be performed in a manner similar to that described in

steps

430 and 432, or may be performed early in the process, such as through pre-approval of group access, for example, in a task creation process as described above, and/or the like. In other words, for embodiments herein, management of data resource access is considered to be any other tolerance/combination of strict, relaxed, and/or implementation-specific, as would be appreciated by one of ordinary skill in the relevant art having the benefit of this disclosure, and is not limited by the described or illustrated embodiments.

In step 438, and after returning approval in step 436, ELM214 creates an RPO in directory a468 of tenant a226, as described herein, e.g., as shown in fig. 3. The created RPO is generated based on the permissions and access policies created in

steps

414 and 416 and approved in step 434. In an embodiment, ELM214 causes an RPO to be created within directory A468. In step 440, tenant B/P228 receives the results of the data access approval request and in step 442 provides a corresponding notification to the user/remote principal at tenant B/P device 472. Thus, tenant is notified that the user/remote principal on B/P device 472 has been granted access to the data resource associated with the task, and the user/remote principal can continue to access the data resource.

In step 444, the user/remote principal of tenant B/P device 472 opens the UI portal (e.g., one of portals 216) of tenant a226, for example, through a domain name or website associated with tenant a 266. The tenant portal prompts for an access token from STS 232 at step 446, either by recognizing that the user/remote principal has external credentials, or by a standard login procedure. In an embodiment, if tenant a226 trusts, the STS 232 instance associated with tenant B/P228 may be designated here for token issuance, and the remote principal may authenticate based on its own domain credentials in order to initially access tenant a 266, but not yet access tenant a 226's secure data resources. Then, in step 448, tenant B/P device 472 provides an access token request to STS 232. In an embodiment, an STS-232 instance associated with tenant A226 may be designated for receiving the request in step 448. At step 450, STS 232-instructs the tenant portal to provide a logon challenge to tenant B/P device 472 in response to the request for an access token at step 448. Next, in step 452, the outside-domain credentials of the user/remote principal (i.e., tenant B/P228) are provided for the login challenge of tenant B/P device 472 accessing STS 232 through the portal to access tenant A226. It is contemplated herein that the secure resource authorization aspect of using the external identity of the remote subject object is also implemented with other access methods/models, in accordance with embodiments. For example, a scenario can be envisaged in which: the remote agent is a member of a group that accesses data resources of a given domain through the RPO, as described herein, and is also a guest user of the given domain. In other words, it should be understood that utilizing RPO does not exclude other access methods/models that are also being implemented. Further non-limiting details regarding examples of this scenario are described below with respect to fig. 5.

STS 232 performs a lookup in directory a468 of tenant A226, as shown at step 454. As described above, in embodiments, access methods/model types other than those described by RPO may be performed, such as, but not limited to, guest access, and the like, as shown below in FIG. 5. The lookup shown in step 454 illustratively illustrates a scenario using RPOs, including identifying one or more RPOs in directory a468 that point to a domain ID of the user/remote principal association, e.g., the RPO created in step 438, with the result of the lookup being returned to STS 232. If no RPO is found that meets these requirements, then the authentication fails and no token is issued. In an embodiment, one or more RPOs directed to tenant B/P228 of a user/remote subject association are stored in directory a468. When multiple RPOs are found to have the necessary conditions, additional matching conditions will be used to select the RPO, for example. If it is determined that the user/remote principal is a member of a group in tenant B/P228 domain, then an RPO of type "group" is verified. If no RPO is selected using the matching condition, authentication fails and no token is issued.

If at least one RPO is selected, STS 232 obtains the entitlements specified in the RPO(s) stored in directory a468, which are directed to tenant B/P228, and designates the user/remote principal as a group member, in step 456. For example, for each RPO selected, STS 232 queries all links between the RPO and the data resource requesting the token. In an embodiment, each RPO and data resource combination has a link with all scopes to be included in the token for that data resource. According to an embodiment, the entitlements are based on the permissions and access policies associated with the RPO(s), as described above with respect to RPO308 of fig. 3. For example, the service/application ID and the claim(s) include rights associated with the RPO. At step 458, the rights are returned to STS 232.

In step 460, STS 232 generates an access token for the portal of tenant a226 and provides the access token to tenant B/P device 472 for the user/remote principal to satisfy the login challenge for the portal described in step 452 or provide a claim to the remote principal to access the secured data resources of tenant a 226. In an embodiment, the access token includes the entitlements returned in step 458, where STS 232 combines all scopes found in the link between the selected RPO(s) and the data resource to enumerate the entitlements and specify a redirection for the browser that tenant B/P device 472 uses to interface with the portal. In step 462, the browser at tenant B/P device 472 provides the portal with redirection information with token and rights/permissions. A portal of portal(s) 216 may be configured to authenticate a user/remote principal according to a token for authorization/permission, or may be configured to provide access to a secure data resource sought via redirection. In step 464, the portal provides access to the data resources based on the rights/permissions and completes the redirection of the browser at tenant B/P device 472 for data resource access while performing the task.

In different embodiments, an application or service may act as a remote agent, rather than a user remote agent, as described herein. In such embodiments, the application/service remote principal uses an interface such as an API, rather than the UI of the user remote principal.

Thus, the user/remote principal at tenant B/P device 472 is enabled to access the secure data resources of tenant A226 using its domain credentials of tenant B/P228. It should also be noted that in an embodiment, token exchange is used for authentication of the user/remote principal, rather than credential authentication as described in flowchart 400 above.

In an embodiment, STS 232 in FIGS. 2 and 3 is configured to perform additional functions and/or operations for token issuance to a user/remote principal as described above. For example, fig. 5 shows a flowchart 500 of an embodiment of flowchart 400 of fig. 4 for secure resource authorization of an external identity using a remote principal object, according to an example embodiment. Further structural and operational examples will be apparent to persons skilled in the relevant art(s) based on the following description. With respect to the system 200 of fig. 2 and the system 300 of fig. 3, and the flowchart 400 of fig. 4, the flowchart 500 is described as follows.

In an embodiment, flowchart 500 begins after step 452 of flowchart 400. For example, in response to receiving outside-domain credentials in step 452, STS 232 is configured to perform a user/remote principal lookup in the first domain and the second domain in step 502 of flowchart 500. With respect to flowchart 400, STS 232 is configured to look up the identity of the user/remote principal in the external domain (e.g., directory B/P466 of tenant B/P228) and the domain of the data resource owner (e.g., directory A468 of tenant A226).

If, at step 504, STS 232 discovers that the identity of the user/remote principal is present in both domains, then, at step 506, token issuance follows existing logic to authenticate the user/remote entity according to the guest model or other similar model without authentication through the RPO. The flowchart 500 ends. If the identity of the user/remote principal is not found in both domains according to step 504, the flow diagram 500 will continue to step 508 where a selected set of conditional access policies in tenant B/P228 domain are evaluated by STS 232. In an embodiment, the conditional access policy corresponds to the task created in flowchart 400. In step 510, it is determined whether the user/remote agent satisfies a condition. If the user/remote principal fails to satisfy the condition in step 510, then authentication fails and no token is issued according to step 512, and the flowchart 500 ends; otherwise, the authentication process proceeds to step 454 of flowchart 400.

In embodiments, authentication using RPO may be preferred over using other models and/or mechanisms. In the context of flowchart 500, according to these embodiments,

steps

508 and 510 are performed before

steps

502 and 504, where a remote agent's non-satisfaction of the condition in step 510 results in step 502 being performed. Moreover, although not shown for simplicity and ease of illustration, other models and/or mechanisms for authentication may be determined and/or used at different points in flowchart 500.

Turning now to fig. 6, an example token 600 for secure resource authorization of an external identity using a remote principal object is illustrated, according to an example embodiment. In an embodiment, token 600 corresponds to the token generated by STS 232 in step 460 of flowchart 400. Token 600 is illustrative and exemplary and should be considered non-limiting. For token 600, an example data resource that a user/remote principal (e.g., tenant B/P228 (as a partner)) requests access to is a directory, such as directory a468 of tenant A226 (as a customer) in FIG. 4.

In embodiments, token 600 issued by STS 232 is required to not reveal the true identity or identification information of the user/remote principal from the domain of the user/remote principal, e.g., a member of group 318 of second domain304 in FIG. 3 and/or the user/remote principal of tenant B/P238 as shown and described in flowchart 400 of FIG. 4. Thus, in embodiments, attributes such as, but not limited to, the following are not populated: "family _ name", "given _ name", "origin", "unique _ name", "upn", "deviceid", and the like. In some embodiments, the declaration and multi-factor authentication (MFA) "auth. For example, "amr", "controls", "sign _ state", and the like. However, in some embodiments, one or more portions of the identification information may be included in the token based on an agreement between the owner and the visitor of the data resource. Further, in an embodiment, a property that specifies that the remote principal is specified in the token 600, such as "rpo" is included in the token 600 that points to the rpo at which the token 600 was created. This is used to associate token 600 with RPO(s) and, through it, with the ELM packet that created the RPO. In some embodiments, this example "rpo" claim is optional and is only provided for services/applications that subscribe to the claim. The "rpo" statement contains the rpo object ID in the customer tenant. In some embodiments, when the workload requires additional information in the token for various purposes, such as granular and compliance audits, the data resource owner and partner/remote principal may mutually agree to additional information available in the token, such as partner user "oid," partner user "upn," and the like.

In the token embodiment, the issuer and domain IDs are data resource owner domains, idP corresponds to the host domain, "altsecid" is not specified, and RPO ID is specified. Further, embodiments provide a "wids" declaration for the token generated in association with the RPO. In an embodiment, a well-known Globally Unique Identifier (GUID) is used for the "wids" declaration. For example, if the issued token is for a remote principal, then the "wids" claim may contain a known RPO GUID (e.g., 0000000-900d-f00 d-0000-000000000000) representing the remote principal. It should be noted that this GUID is exemplary in nature for descriptive purposes, and the actual GUID selected at implementation may differ according to embodiments. The "wids" statement may also contain the directory role assigned to the RPO. In this case, the workload is suggested to use this range to determine any built-in directory roles assigned to the RPO. In addition, the workload may perform a mapping of its own in-directory roles to the set of permissions that the workload understands.

The scope of the token in the issued token 600 is based on the set of associative links between the RPO and the data resource of the request token 600. As described above, the link between the RPO and the data resource is created by ELM214 (shown in FIGS. 2 and 4) according to permissions and access policies that control access to the secured data resource, for example, in an access packet definition. According to an embodiment, the scope of the task (e.g., task topic) determines the data resource access requirements, thereby defining the content of the access packet. In an embodiment, the access packet definition for a given task scope is predefined, e.g., by the permission template, in the domain of the user/remote principal, and cannot be changed in the domain of the data resource owner of the embodiment, and similarly, the link created for the RPO cannot be edited in any way other than by the access packet. Through this process, the claims granted to the user/remote principal by the RPO are immutable to the domain of the data resource owner.

In the context of workload tasks, the workload may also authorize requests using the scope described herein. In embodiments, existing group membership or custom role membership checks cannot be used for authorization because these assignments cannot be used for RPOs stored in a directory of a data resource owner domain. It is contemplated herein that built-in role membership checks may still be performed, but, in the described embodiments, using service/application scope via RPO is more robust and extensible for authorization managed within a domain's directory.

In an embodiment, the STS 232 telemetry processing pipeline that generates token 600 contains RPO modeling/requirements as described herein and is configured to issue log logs or audit reports in the user/remote body domain and data resource owner domain. As described above, for token generation in flow chart 400, embodiments provide a log/audit report that is provided to the data resource owner domain to exclude any user/remote subject-specific information, while a log/audit report sent to the user/remote party domain allows for the inclusion of actual user/remote subject information. However, in other embodiments, portions of the primary specific/identifying information may be included in the log/audit report based on agreements between the data resource owner and the visitor.

Access to secure data resources (e.g., directory data) by remote agents is a sensitive operation. Since at least two different organizations participate in setting access controls, one organization obtains the ability to read the data of the other organization, embodiments herein provide login/authentication and all task activities, which are important data to audit, tracked to prevent abuse and further reduce the risk of performing tasks and operations on data resources using the described embodiments.

Further, if a problem occurs during the execution of a task, the owner of the data resource executing the task may determine specific information about the performance of the task in order to track and/or resolve the problem via log/audit reports without maintaining a list of group members in the remote domain that have access to the data resource. That is, in some cases, the data resource owner may not want to include remote domain users in their directory, which may be many in embodiments because maintaining a list of remote domain users requires additional storage and processing usage, additional administration/overhead, and remote domain user access may only require a limited period of time (e.g., performing tasks related to the data resource). In addition, the group membership list used to access data resources for performing tasks may contain more members than are actually going to participate in task execution. For example, a group may include ten members that are granted access to a data resource, but only one member may complete a given task associated with the data resource. Over time, the domain of the data resource owner may maintain a large number of remote domain users, many of which never have access to the data resource during task execution, given that different tasks may also have different corresponding groups and different membership. However, the described RPO embodiments allow temporary access rights associated with the RPO to have little persistent impact on the resource owner's domain, since the list of remote domain users need not be persisted.

With respect to login/authentication activities, when a user/remote principal logs in to a data resource owner domain from its own domain, the owner should be aware that a login occurred and issue a token to the data resource in its domain. In an embodiment, the particular identity of the authenticated remote principal and its geographic location are private to the domain of the remote principal and therefore not shared with the data resource owner. Service providers should know that one of their users is logged on to a customer tenant. However, the domain of the remote principal is provided with complete details of the login/authentication of the task and access to the data resources, including who, when, from where, and/or the like.

With respect to activity auditing, in an embodiment, each activity (including reading) performed by a token issued to a remote principal is tracked and made available to the domain of the owner of the data resource. An audit of write activity available to the domain of the data resource owner includes the RPO identifier, followed by the token identifier, rather than the actual user/remote subject identification.

The system and devices are configured in various ways to perform secure resource authorization for external identities using remote subject objects-herein, as shown. 7, 8 and 9 will now be described.

For example, fig. 7 shows a flow diagram 700 for secure resource authorization of an external identity using a remote principal object, according to an example embodiment. In an embodiment, system 100A in fig. 1A, system 100B in fig. 1B, system 200 in fig. 2, and system 300 in fig. 3 may operate according to flowchart 700. Further structural and operational examples will be apparent to persons skilled in the relevant art(s) based on the following description. Flowchart 700 may be an embodiment of flowchart 400 of fig. 4. Flowchart 700 is described below with respect to system 200 of fig. 2 and system 300 of fig. 3.

Fig. 8 illustrates a group 800 as a data structure for secure resource authorization for external identities using remote principal objects, according to an example embodiment. Group 800 is an example of an embodiment of group 318 in system 300 of fig. 3. The grouping 800 is organized as an exemplary data structure that is generated and stored in a memory, such as the memory 206 of the system 200 in an embodiment, and includes a directory as described herein.

Referring back to FIG. 7, flowchart 700 begins with step 702. At and in association with the second domain, a data structure specifying the group is generated in step 702 based on access requirements for secured data resources in a first domain of the domain master, the first domain being different from the second domain. For example, the access controller 212 of the system 200 in FIG. 2 is configured to generate a data structure that specifies a group of tenants B/P228, as shown in step 410 of the flowchart 400 in FIG. 4. In an embodiment, the data structure/group is generated in response to or after receiving an indication or request to create a task associated with the secure data resource.

Turning now to fig. 8, a group 800 includes a data structure 802. According to embodiments, the data structure 802 is organized in any manner as a group representing members, such as users/remote subjects seeking access to data resources while performing tasks. As non-limiting examples, the group-directed data structure may include a list, a set, a field, a table, and/or the like. As shown, data structure 802 includes a set or list of group information 804 and a set or list of group members 806. Referring to the flow diagram 400 of FIG. 4, the group 800 as a data structure 802 is stored in a directory B/P466 for tenant B/P228.

Group information 804 includes one or more of: a group ID identifying the group, a group domain ID identifying a domain associated with the group, a task ID identifying a task associated with the data resource, and a data resource ID identifying the data resource itself. In embodiments, more or fewer information items may be included than the listed information items shown for group information 804.

Group member 806 includes a first group member having an identifier of "member 1" and a second group member having an identifier of "member 2", although in embodiments, more or fewer member entries than those listed for group member 806 may be included in addition to the empty set of members. Each entry of the group member 806 may include an identifier as a member name, an alias, and/or any other type of identifier. As shown, group member 806 is a collection or list of members, e.g., a user/remote principal of one domain seeking access to data resources of another domain when performing tasks. Additional information associated with the items of group member 806 is also contemplated herein, such as, but not limited to, credential information in embodiments, member roles, and/or the like. As described above, according to embodiments, the group members include applications and/or services.

Referring again to FIG. 7, in step 704, a rights template generated at the second domain is obtained, the rights template defining a set of rights including at least one right to the secured data resource by a member of the group. For example, access controller 212 is configured to retrieve, e.g., in memory 206 of system 200, a permission template generated and/or stored at tenant B/P228 as described herein. The permission template defines permissions granted by group members for secure data resources associated with performing tasks. In an embodiment, the access packet includes rights to the right, as described herein.

In step 706, an access policy for the secured data resource is generated, the access policy being associated with the set of permissions. For example, access controller 212 is configured to generate an access policy for the secured data resource that defines which users/remote principals are allowed to access the secured data resource as needed to perform a given task through group membership checks of the users/remote principals. In some embodiments, the access policy is generated based on the rights template obtained in step 704 above. In an embodiment, the access policy allows automatic approval of a request to access the secure data resource if such a request is made by a user/remote principal (e.g., tenant B/P228) from a domain belonging to a specified group corresponding to the task. The described embodiments allow such evaluation to be performed on the first requester without requiring a subsequent request to be evaluated at a later time.

In step 708, the set of permissions and the access policy are provided to a domain master of the first domain, the set of permissions and the access policy being immutable from the first domain. For example, in the context of flowchart 400, access controller 212 is configured to provide a set of permissions and an access policy to directory a468 of tenant a226 for storage therein, wherein the access policy is associated with the permissions. In an embodiment, the permissions comprise access packets as described herein, which are provided to the first domain. As previously described, the access groups/permissions and access policies, while stored in the domain of the secure data resource owner, are immutable in these domains.

In step 710, an access permission approval request for the secured data resource is provided to the first domain on behalf of the remote principal (as a member of the group), such that based at least on an approval indication of the access permission approval request from the first domain, a remote principal object is generated in a directory of the first domain at the domain master, the remote principal object linking the group to at least one right for the secured data resource as enumerated by the set of permissions and specified by the access policy. For example, a secure data resource owner or delegate (e.g., an authorized member of the domain of tenant A226) grants access rights to the secure data resource on behalf of the user/remote principal of tenant B/P228 based on the rights and access policies provided from ELM214 in step 708 (e.g., via lockbox 222 of system 200). When ELM214 receives an indication of approval, ELM214 is configured to cause an RPO to be created/generated in directory a468. As described herein, such as with RPO308 of system 300 in fig. 3, the RPO includes a link to a group that is entitled to secure data resource(s) based on access grouping/permissions and/or access policies provided by ELM 214. The RPO is stored in directory a468 to prevent access attempts from users/remote agents of the group of tenants B/P228.

In step 712, the remote subject object, the set of permissions, and/or the access policy is caused to be deleted at the domain master of the first domain based on at least one of receiving an access permission revocation from the first domain, completing a task associated with the remote subject object, or a time expiration date of the remote subject object. For example, in an embodiment, ELM214 of system 200 is configured to delete RPOs, associated access groups/permissions, and/or associated access policies from, or cause deletion of, a directory in the domain of the secure data resource owner. ELM214 is configured to perform such deletion/cleaning/removal based on various conditions, such as, but not limited to, denial or revocation of access rights from the domain of the secure data resource owner, completion of tasks corresponding to creating RPOs, and/or expiration of RPOs and/or their rights, which are defined as associated access policies.

In fig. 9, a flow diagram 900 for secure resource authorization for external identities using remote principal objects is shown, according to an example embodiment. In an embodiment, system 100A in fig. 1A, system 100B in fig. 1B, system 200 in fig. 2, and system 300 in fig. 3 may operate according to flowchart 900. Further structural and operational examples will be apparent to persons skilled in the relevant art(s) based on the following description. Flowchart 900 may be an embodiment of flowchart 700 in fig. 7. Flowchart 900 is described below with respect to system 200 of fig. 2 and system 300 of fig. 3.

Flowchart 900 begins with step 902. In step 902, after providing the access permission approval request to the first domain on behalf of the remote principal, a subsequent access permission approval request is received from the remote principal or another member of the group. For example, after step 710 of flowchart 700, where a first access permission approval request is provided to a first domain and approved, such that an RPO and its link are generated in a directory of the first domain, a later or subsequent access permission approval request is received from the same remote principal or another member/remote principal of a group associated with the RPO. In an embodiment, step 902 is a later re-execution of step 430 of flowchart 400 in FIG. 4 by the same or another remote agent of the group. When the first remote principal's request is validated and approved, the RPO and its "link" will be created in the directory of the data resource owner's domain, so in embodiments where the RPO lifecycle is still valid, subsequent access requests are considered "no-op", or, if the RPO is cleaned up due to the lifecycle expiring, will result in a re-creation of the RPO.

In step 904, at least one of: approval is maintained in the directory or the remote subject object is maintained in the directory. For example, the access policy generated by ELM214 of system 200 governs the lifecycle of the provided permissions/access packets and the associated RPO in the directory in the domain of the data resource owner. The ELM is configured to monitor and/or be informed about the lifecycle validity of the permission/access packets and their associated RPOs in the data resource owner directory. Because the access policy created by the ELM strictly governs the lifecycle, the continued presence of RPOs in the directory is proof of the lifecycle, and thus the RPOs remain valid. Similarly, revoking granted access to a data resource from its owner's domain causes ELM214 to clean up the RPOs and associated access packets/permissions and access policies. Thus, the determination in step 904 is completed without revocation and with the RPO remaining valid in the directory according to the access policy.

In step 906, the remote principal or another member of the group is notified of a valid approval for a subsequent access permission approval request. For example, as described herein, the access policy created for the permission/access packet used to generate the RPO allows for automatic approval of requests for access to a data resource and evaluation of the first access request received, with subsequent requests treated as "no operation. Thus, in an embodiment, ELM214 is configured to notify the remote principal or another member of the group of the valid approval, i.e., the automatic approval for data resource access, and step 906 is a subsequent re-execution of step 442 of flowchart 400 in FIG. 4 without returning to the previous step until step 430 must be performed. That is, because the RPO for data resource access for the remote agent and the group of other remote agents already exists and remains valid in the directory of the data resource owner domain, access to the data resource is obtained via step 444 and subsequent steps of flowchart 400.

In fig. 10, a flow diagram 1000 for secure resource authorization of an external identity using a remote principal object is shown, according to an example embodiment. In an embodiment, system 100A in fig. 1A, system 100B in fig. 1B, system 200 in fig. 2, and system 300 in fig. 3 may operate in accordance with flowchart 1000. Further structural and operational examples will be apparent to persons skilled in the relevant art(s) based on the following description. Flowchart 1000 may be an embodiment of flowchart 400 of fig. 4 and/or flowchart 500 of fig. 5. Flowchart 1000 is described below with respect to system 200 of fig. 2 and system 300 of fig. 3.

Flowchart 1000 begins with step 1002. In step 1002, a request to access a first domain of a domain master, the first domain being different from a second domain, is received from an interface associated with a remote principal, the request including an identifier of the remote principal and a second domain credential. For example, ELM214 receives a request from a remote subject via tenant B/P228 for access to secure data resources of tenant a226 to perform a task, as similarly described with respect to

steps

422 and 430 of flowchart 400 in figure 4. In an embodiment, the first domain and the second domain are different, and each domain requires a specific credential for accessing it-i.e. the credential accessing the first domain does not provide access to a data resource securely stored in the second domain. The remote principal of tenant B/P228 has corresponding credentials, and these credentials (including identifiers) are provided to ELM214 in the request of step 1002 for group membership verification against RPO.

In step 1004, a remote principal object is caused to be generated in a directory of the first domain at the domain master, the remote principal being linked to the rights based on the set of permissions. For example, ELM214 is configured to generate or cause generation of RPO in directory a468 of tenant a226 after receiving the request in step 1002, as similarly described for step 422 and step 430 of flowchart 400 in fig. 4. The generated RPO is created based on the permissions in the access packet provided from ELM214 to directory a468.

In step 1006, it is determined that a remote subject object generated and stored at a directory of the domain master and inaccessible from the second domain exists and is valid in the directory. For example, the RPO generated at directory a468 in step 1004 has a lifecycle associated with it, and thus, after its creation, a determination of its presence and validity is performed by STS 232 of system 200 in fig. 2 and 4. STS 232 is also configured to determine whether the RPO is of the "group" type in order to authenticate the remote principal for the specified group.

In step 1008, it is verified that the remote principal is identified as being associated with a group of the second domain having at least one right to the secure data resource as enumerated in the set of permissions, and at least one associated access policy defined by the second domain and represented in the remote principal object. For example, the RPO generated at directory a468 in step 1004 includes a list or set of group members authorized to access data resources associated with the task, and STS 232 of system 200 in fig. 2 and 4 is configured to determine whether the remote principal is a member of the group (as determined in step 454 similar to flowchart 400). In an embodiment, the identity of the remote principal is based on provisioned credentials that are verified against the group linked in the RPO at directory a468. The identity of the remote principal in an embodiment is based on provisioned credentials that are verified against the RPO-linked group in directory a 46.

In step 1010, an access token for the remote principal is generated, the access token including at least one entitlement. For example, STS 232 is configured to generate an access token for a remote principal. The access token includes the right(s) derived from the right to generate the RPO. In an embodiment, the token also specifies a redirection of the UI used by the remote principal. Step 1010 may be an embodiment of steps 458 and 460 of flowchart 400 in fig. 4.

In step 1012, the access token is provided to the remote agent such that an interface is redirected that provides the remote agent access to the secured data resource. For example, STS 232 is configured to provide the access token generated in step 1010 to the device of the remote principal. When the access token includes the redirection, providing the access token to the remote principal causes a UI redirection on the remote principal's device, thereby allowing the remote principal to access the secure data resources associated with the task. Step 1012 may be an embodiment of step 460 of flowchart 400 in fig. 4.

As described herein, the UI described in flowchart 1000 for the remote principal may be an API in an implementation where the remote principal is an application or service, according to an embodiment.

In fig. 11, a flow diagram 1100 for secure resource authorization for external identities using remote principal objects is shown, according to an example embodiment. In an embodiment, system 100A in fig. 1A, system 100B in fig. 1B, system 200 in fig. 2, and system 300 in fig. 3 may operate according to flowchart 1100. Further structural and operational examples will be apparent to persons skilled in the relevant art(s) based on the following description. Flowchart 1100 may be an embodiment of flowchart 1000 in fig. 10. Flowchart 1100 is described below with respect to system 200 of fig. 2 and system 300 of fig. 3.

Flowchart 1100 begins with step 1102. In step 1102, generation of a remote subject object is performed to include determining a time validity period associated therewith. Step 1102 is an embodiment of step 1004 of flowchart 1000 in fig. 10. For example, as described herein, RPO, permissions, and group membership include lifecycle limitations, which in embodiments are strictly governed by the access policy of the permissions generated by the ELM214 of the system 200 in fig. 2. In step 1102, ELM214 determines the RPO lifecycle and its permissions to be time-valid based on the created access policy. Thus, when it is determined that the lifecycle has expired, flow diagram 1000 will not proceed from step 1006 to step 1008, at least because the RPO in the data resource owner's directory is no longer valid.

In step 1104, after the time validity period expires, at least one of the following is performed at the domain master: the remote subject object is deleted from the directory or the set of permissions and at least one associated access policy are deleted from the directory. For example, ELM214 is configured to delete the RPO and/or delete the set of permissions and at least one associated access policy from the directory based on expiration of the lifecycle. Further, in an embodiment, ELM214 is further configured to delete a remote agent from the group associated with the task and RPO. It is also contemplated herein that the described lifecycle expires upon completion of the task.

3. Example Mobile and computing device embodiments

The embodiments described herein may be implemented in hardware, or in hardware in combination with software and/or firmware. For example, the embodiments described herein may be implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer-readable storage medium. Alternatively, the embodiments described herein may be implemented as hardware logic/circuitry.

As described herein, the embodiments include, but are not limited to, the system 100A in fig. 1A, the system 100B in fig. 1B, the system 200 in fig. 2, the system 300 in fig. 3, and the group 800 in fig. 8, and any components and/or subcomponents therein, and any operations and portions of the flowcharts/flow diagrams described herein, and/or further examples described herein, may be implemented in hardware, or may be implemented in any combination of software and/or firmware, including computer program code configured to be executed in one or more processors and stored in a computer-readable storage medium, or as hardware logic/circuitry, e.g., implemented together in a system on a chip (SoC), a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), a trusted platform module (ASIC), or the like. The SoC may include an integrated circuit chip that includes one or more processors (e.g., microcontrollers, microprocessors, digital Signal Processors (DSPs), etc.), memory, one or more communication interfaces and/or other circuits and/or embedded firmware to perform its functions.

The embodiments described herein may be implemented in one or more computing devices similar to the mobile systems and/or computing devices in fixed or mobile computer embodiments, including one or more features of the mobile systems and/or computing devices described herein, as well as alternative features. The description of computing devices provided herein is for illustrative purposes only and is not intended to be limiting. As will be appreciated by one of skill in the relevant art, embodiments may be implemented in other types of computer systems.

FIG. 12 is a block diagram of an exemplary mobile system 1200 that includes a mobile device 1202 in which embodiments described herein may be implemented. For example, mobile device 1202 may be used to implement any of the systems, clients, or devices in the preceding sections or components/subcomponents thereof. As shown in fig. 12, mobile device 1202 includes a variety of optional hardware and software components. Any component in mobile device 1202 can communicate with any other component, but not all connections are shown for ease of illustration. The mobile device 1202 may be any of a variety of computing devices (e.g., a cell phone, a smart phone, a handheld computer, a Personal Digital Assistant (PDA), etc.) and may allow wireless two-way communication with one or more mobile communication networks 1204 (e.g., a cellular or satellite network) or a local or wide area network.

Mobile device 1202 may include a controller or processor 1210 (e.g., signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing tasks such as signal coding, data processing, input/output processing, power control, and/or other functions. An operating system 1212 can control the allocation and usage of components of mobile device 1202, and provide support for one or more application programs 1214 (also called "applications" or "applications"). Applications 1214 may include common mobile computing applications (e.g., email applications, calendars, contact managers, web browsers, messaging applications) and any other computing application, such as word processing applications, mapping applications, media player applications).

Mobile device 1202 can include memory 1220. The memory 1220 can include non-removable memory 1222 and/or removable memory 1224. The non-removable memory 1222 may include RAM, ROM, flash memory, a hard disk, or other well-known storage devices or technologies. The removable memory 1224 can include flash memory or a Subscriber Identity Module (SIM) card, as is well known in GSM communication systems, or other well-known memory devices or technologies, such as a "smart card. The memory 1220 may be used for storing data and/or code for running the operating system 1212 and the application programs 1214. Example data may include web pages, text, images, sound files, video data, or other data transmitted over one or more wired or wireless networks and/or received from one or more network servers or other devices. The memory 1220 may be used to store a subscriber identifier, such as an International Mobile Subscriber Identity (IMSI), and a device identifier, such as an International Mobile Equipment Identifier (IMEI). Such identifiers may be transmitted to a network server to identify the user and the device.

A number of programs may be stored in the memory 1220. These programs include an operating system 1212, one or more application programs 1214, and other program modules and program data. Examples of such applications or program modules may include, for example, computer program logic (e.g., computer program code or instructions) and any components and/or subcomponents thereof, for implementing one or more of the system 100A of fig. 1A, the system 100B of fig. 1B, the system 200 of fig. 2, the system 300 of fig. 3 and the group 800 of fig. 8, and the flowcharts/flowcharts described herein, including portions thereof, and/or further examples described herein.

Mobile device 1202 may include mobile TPM 1292. Mobile TPM 1262 may be a mobile device equivalent embodiment of a TPM as will be appreciated by those skilled in the art having the benefit of the present invention. For example, mobile TPM 1292 may be configured to perform one or more functions or operations of a TPM for various embodiments herein.

The mobile device 1202 may support one or more input devices 1230, such as a touch screen 1232, a microphone 1234, a camera 1236, a physical keyboard 1238, and/or a trackball 1240 and one or more output devices 1250, such as a speaker 1252 and a display 1254. Other possible output devices (not shown) may include piezoelectric or other haptic output devices. Some devices may provide multiple input/output functions. For example, touchscreen 1232 and display 1254 may be combined in a single input/output device. Input device 1230 may include a Natural User Interface (NUI).

One or more wireless modems 1260 may be coupled to antennas (not shown) and may support bidirectional communication between the processor 1210 and external devices, as understood in the art. The modem 1260 is shown generally and can include a cellular modem 1266 for communicating with the mobile communication network 1204 and/or other radio-based modems (e.g., bluetooth 1264 and/or Wi-Fi 1262). The at least one wireless modem 1260 is typically configured to communicate with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the mobile device and a Public Switched Telephone Network (PSTN).

The mobile device 1202 can also include at least one input/output port 1280, a power supply 1282, a satellite navigation system receiver 1284, such as a Global Positioning System (GPS) receiver, an accelerometer 1286, and/or a physical connector 1290, which can be a USB port, an IEEE1394 (FireWire) port, and/or an RS-232 port. The illustrated components of mobile device 1202 are not required or all-inclusive, and any components may be deleted and other components may be added, as will be appreciated by those skilled in the art.

In an embodiment, the mobile device 1202 is configured to implement any of the above-described features of the flow diagrams herein. Computer program logic for performing any of the operations, steps, and/or functions described herein may be stored in memory 1220 and executed by processor 1210.

FIG. 13 depicts an exemplary implementation of a computing device 1300 in which embodiments may be implemented. For example, embodiments described herein may be implemented in one or more computing devices or systems similar to computing device 1300, as well as multiple instances of computing device 1300, including one or more features and/or alternative features of computing device 1400, in fixed or mobile computer embodiments. The description of computing device 1300 provided herein is for purposes of illustration only and is not intended to be limiting. Embodiments may be implemented in other types of computer systems, servers, and/or clusters, etc., as known to those of skill in the relevant art.

As shown in fig. 13, computing device 1300 includes one or more processors (referred to as processor circuit 1302), a system memory 1304, and a bus 1306 that couples various system components including the system memory 1304 to the processor circuit 1302. Processor circuit 1302 is an electrical and/or optical circuit implemented in one or more physical hardware circuit device elements and/or integrated circuit devices (semiconductor material chips or dies) as a Central Processing Unit (CPU), microcontroller, microprocessor, and/or other physical hardware processor circuit. The processor circuit 1302 may execute program code stored in a computer readable medium, such as program code for the operating system 1330, application programs 1332, other programs 1334, and the like. Bus 1306 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using a variety of bus architectures. The system memory 1304 includes Read Only Memory (ROM) 1308 and Random Access Memory (RAM) 1310. A basic input/output system 1312 (BIOS) is stored in ROM 1308.

Computing device 1300 also has one or more of the following drives: a hard disk drive 1314 for reading from and writing to a hard disk, a magnetic disk drive 1316 for reading from or writing to a removable magnetic disk 1318, and an optical disk drive 1320 for reading from or reading from a removable optical disk 1322 (e.g., a CD ROM, DVD ROM, or other optical media). The hard disk drive 1314, magnetic disk drive 1316 and optical disk drive 1320 can be connected to the bus 1306 by a hard disk drive interface 1324, a magnetic disk drive interface 1326 and an optical drive interface 1328, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computer. Although a hard disk, a removable magnetic disk and a removable optical disk are described, other types of hardware-based computer-readable storage media can be used to store data, such as flash memory cards, digital video disks, RAMs, ROMs and other hardware storage media.

Many program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include an operating system 1330, one or more application programs 1332, other programs 1334, and program data 1336. Application programs 1331 or other programs 1333 may include, for example, computer program logic (e.g., computer program code or instructions) for implementing embodiments described herein, such as, but not limited to, system 100A in fig. 1A, system 100B in fig. 1B, system 200 in fig. 2, system 300 in fig. 3, and group 800 in fig. 8, and any components and/or subcomponents therein, as well as flow diagrams/flow diagrams described herein, including portions thereof, and/or further examples described herein.

A user may enter commands and information into the computing device 1300 through input devices such as a keyboard 1338 and pointing device 1340. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, touch screen and/or pad, voice recognition system to receive voice inputs, gesture recognition system to receive gesture inputs, and so forth. These and other input devices are often connected to the processor circuit 1302 through a serial port interface 1342 that is coupled to bus 1306, but may be connected by other interfaces, such as a parallel port, game port, or a Universal Serial Bus (USB).

A display 1344 is also connected to the bus 1306 via an interface, such as a video adapter 1346. The display 1344 may be external to the computing device 1300 or incorporated into the computing device 1300. Display 1344 may both display information and serve as a user interface for receiving user commands and/or other information (e.g., via touch, finger gestures, virtual keyboard, etc.). In addition to the display 1344, the computing device 1300 may include other peripheral output devices (not shown), such as speakers and printers.

Computing device 1300 is connected to a network 1348 (e.g., the internet) through an adapter or network interface 1350, a modem 1352, or other means for establishing communications over the network. The modem 1352, which may be internal or external, may be connected to the bus 1306 via the serial port interface 1342, as shown in fig. 13, or other interface types (including parallel interfaces) may be used to connect to the bus 130.

TPM 1354 may be connected to bus 1306 and may be one embodiment of any TPM as would be appreciated by one of ordinary skill in the relevant art(s) having the benefit of the present invention. For example, TPM 1354 may be configured to perform one or more functions or operations of a TPM for various embodiments herein.

As used herein, the terms "computer program medium," "computer-readable storage medium," and "computer-readable storage device" and the like are used to refer to physical hardware media. Examples of such physical hardware media include a hard disk associated with the hard disk drive 1314, a removable magnetic disk 1318, a removable optical disk 1322, other physical hardware media such as RAM, ROM, flash memory cards, digital video disks, zip disks, MEM, nanotechnology-based storage devices, and other types of physical/tangible hardware storage media (including the memory 1320 of fig. 13). Such computer-readable media and/or storage media are distinct from and do not overlap with communication media and propagated signals (excluding communication media and transmission signals). Communication media embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wireless media such as acoustic, RF, infrared and other wireless media, and wired media. Embodiments are also directed to communication media separate and non-overlapping with the embodiments directed to computer-readable storage media.

As mentioned above, computer programs and modules (including application programs 1332 and other programs 1334) may be stored on the hard disk, magnetic disk, optical disk, ROM, RAM, or other hardware storage media. Such computer programs may also be received via network interface 1350, serial interface 1342, or any other interface type. Such computer programs, when executed or loaded by an application, enable computing device 1300 to implement features of embodiments discussed herein. Accordingly, such computer programs represent controllers of the computing device 1300.

Embodiments are also directed to computer program products comprising computer code or instructions stored on any computer readable medium or computer readable storage medium. Such computer program products include hard drives, optical drives, storage packages, portable memory sticks, memory cards, and other types of physical storage hardware.

4. Other examples and advantages

As described above, systems and devices embodying techniques described herein may be configured and enabled in various ways to perform respective functions for secure resource authorization of an external identity using a remote subject object. In embodiments, one or more steps or operations of any flow diagrams and/or flow diagrams described herein may not be performed. Additionally, steps or operations in addition to or in place of any of the flowcharts and/or steps or operations in the flowcharts described herein may also be performed. Further, in examples, one or more operations of any flow diagrams and/or flow diagrams described herein may be performed out of order, in alternate order, or partially (or completely) concurrently with each other or with other operations.

As described herein, systems, devices, components, etc. of embodiments configured to perform functions and/or operations are also considered to perform such functions and/or operations.

As described above, secure resource authorization for external identities using remote subject objects improves remote access to secured data resources by leveraging permissions, access policies, and objects in a directory of the domain of the data resource owner, which are defined by the external domain and are also immutable in the domain of the data resource owner — the data resource owner only allows granting or denying access based on the defined permissions and access policies. That is, embodiments herein use strictly regulated, provider-defined access conditions for the remote principal and allow protection of the owner's data resources while protecting the remote principal's identity information, which was previously unavailable to software services and applications, let alone cloud-based platforms where the client tenant allows other tenants and/or partners to access securely stored data resources via RPO.

Furthermore, the security of the computing system and platform is improved while still allowing secure data resources to be accessed by external/remote principals. That is, the described embodiments provide secure data resource access for computing systems and platforms in a manner that enables applications/services running thereon to be maintained in a more secure manner, yet still provide data resource access when tasks need to be performed. Furthermore, embodiments provided herein that utilize RPOs do not require the persistence of entries in a directory for various bodies of external entities, nor do they require persistent storage of RPOs. The ELM function provides cleanup of RPO and access privileges and group membership based on the lifecycle and task completion defined in the access policy. This reduces storage requirements and management of directories in the computing system.

Embodiments herein may also extend beyond cloud platform/tenant implementations and to existing authentication mechanisms. For example, a Cloud Service Provider (CSP) scenario may be built entirely using RPO and access packets, as described herein. In such embodiments, access packets are generated to define policies that can provide longer auto-approval policies, e.g., in years rather than days, and the user/remote principal can obtain shorter or real-time authorization (e.g., in hours or days). Thus, embodiments may extend to CSP mechanisms while providing more conservative and secure data resource access than persistent access in current models. Further, the RPO may be configured as a "wids" declaration, enabling applications/services to understand the tokens in the current model for easy migration to the RPO model described herein. Embodiments herein are extensible and are applicable to support different types of existing experiences/tools across different types of existing workloads.

The described embodiments differ from existing authentication models in other respects, except for the differences noted in other sections herein. As just one example, the essence of the existing guest access model is to provide for designated guest users to be persistently stored in a directory of a data resource owner domain, rather than the RPO lifecycle described, which provides a group/team for completing a task and has limited time validity. Another example is that some existing models have a strong dependency on contracts between two known groups. The RPO embodiment provides higher granularity in access control.

The RPO may also be configured to support IdP for cloud-based platforms and/or identity providers (IdP) outside the domain associated with data resource ownership and/or requested access, thereby enabling Management Service Providers (MSP) and CSPs operating across cloud platforms to simplify management of access to data resources in the owner domain without duplicating their identity and increasing security risks. In other words, the described embodiments provide equal applicability to first party entities as well as third party entities.

Furthermore, although the described embodiments extend to this embodiment, existing authentication models, such as guest access and other models, are not disrupted. That is, RPO embodiments herein may be used to supplement or replace these existing models, which may still be used to service specific scenarios in the same platform/system.

The additional examples and embodiments described in this section may be applicable to the examples disclosed in any other section or subsection of the disclosure.

Embodiments in the present description provide systems, devices, and methods for secure resource authorization of external identities using remote principal objects. For example, a system is described herein. According to an embodiment, the system is enabled and configured for authorizing a remote principal of a second domain to access secured data resources in a first domain. The system includes a processing system including one or more processors and at least one memory storing program code executed by the processing system to perform a method. The method includes receiving, from an interface associated with a remote principal, a request to access a first domain of a domain master, the first domain being different from a second domain, the request including an identifier of the remote principal and second domain credentials, and determining that the remote principal is associated with a remote principal object generated by the domain master and stored in a directory of the domain master, the remote principal object being inaccessible from the second domain. The method also includes verifying that the remote principal is identified as being associated with a group of the second domain, the group having at least one right to the secure data resource as enumerated in the set of permissions and at least one associated access policy defined by the second domain and represented in the remote principal object, and generating an access token for the remote principal, the access token including the at least one right. The method also includes providing the access token to the remote principal to cause redirection of an interface that provides access by the remote principal to the secured data resource.

In an embodiment of the system, the method comprises, prior to said determining, causing generation of a remote principal object in a first domain at the domain master, the remote principal object linking the remote principal to the rights based on the set of permissions.

In an embodiment of the system, generating the remote subject object is performed based on accepting within the first domain an access permission approval request for the secured data resource initiated and provided on behalf of the second domain.

In an embodiment of the system, generating the remote subject object includes determining a time validity period associated therewith, and the method includes performing, at the domain master and after expiration of the time validity period, at least one of: the remote subject object is deleted from the directory or the set of permissions and at least one associated access policy are deleted from the directory.

In an embodiment of the system, the method comprises generating an audit report after said providing the access token, the audit report comprising at least one of: one or more entries for operations performed by the remote subject on the secure data resource that do not include a personal identifier of the remote subject, or indicia of a set of permissions associated with the remote subject object.

In an embodiment, the system includes a cloud-based services platform including a security token service configured to generate an access token, and the domain master includes a first tenant of the cloud-based services platform and the second domain includes a second tenant of the cloud-based services platform.

In an embodiment of the system, the method comprises, after said receiving, verifying that an entry for the identity of the remote principal does not exist in the directory of the first domain and exists in the directory of the second domain, and performing said determining in response to said verifying.

A method is also described herein. According to an embodiment, the method is for authorizing a remote principal of a second domain to access secure data resources in a first domain. The method includes receiving, from an interface associated with a remote principal, a request to access a first domain of a domain master, the first domain being different from a second domain, the request including an identifier of the remote principal and second domain credentials, and determining that a remote principal object generated and stored in a directory of the domain master and inaccessible from the second domain is present and valid in the directory. The method also includes verifying that the remote principal is identified as being associated with a group of the second domain, the group having at least one right to the secured data resource as enumerated in the set of permissions and at least one associated access policy defined by the second domain and represented in the remote principal object, generating an access token for the remote principal, the access token including the at least one right, and providing the access token to the remote principal to cause redirection of a user interface, the interface providing access to the secured data resource by the remote principal.

In an embodiment, the method includes, prior to the determining, causing generation of a remote principal object in the first domain at the domain master, the remote principal object linking the remote principal to the authorization based on the set of permissions.

In an embodiment of the method, generating the remote subject object is performed based on an acceptance within the first domain of an access permission approval request for a secured data resource initiated and provided on behalf of the second domain.

In an embodiment of the method, generating the remote subject object includes determining a time validity period associated therewith, and the method includes performing, at the domain master and upon expiration of the time validity period, at least one of: the remote subject object is deleted from the directory or the set of permissions and at least one associated access policy are deleted from the directory.

In an embodiment, the method comprises generating an audit report after said providing the access token, including at least one of: one or more entries for operations performed by the remote subject on the secured data resource, or indicia of a set of permissions associated with the remote subject object.

In an embodiment of the method, generating the access token is performed at the cloud-based service platform by its security token service, and the domain master comprises a first tenant of the cloud-based service platform and the second domain comprises a second tenant of the cloud-based service platform.

In an embodiment, the method includes identifying one or more remote subject objects in a directory of the first domain that are associated with the second domain, and determining that at least one of the one or more remote subject objects has a group attribute, the remote subject object being included in at least one of the one or more remote subject objects, and determining that the remote subject is associated with the remote subject object includes determining that the remote subject is identified as a member of the group as represented in the remote subject object.

Also described herein is at least one computer-readable storage medium storing program instructions that, when executed by one or more processing devices, perform a method. According to an embodiment, the method is for authorizing a remote principal of a second domain to access secure data resources of a first domain. The method includes receiving, from an interface associated with a remote principal, a request to access a first domain of a domain master, the first domain being different from a second domain, the request including an identifier of the remote principal and second domain credentials, and determining that the remote principal is associated with a remote principal object generated by the domain master and stored in a directory of the domain master, and that the remote principal object is not accessible from the second domain. The method further includes verifying that the remote principal is identified as being associated with a group of the second domain, the group having at least one right to the secured data resource as enumerated in the set of permissions, and at least one associated access policy defined by the second domain and represented in the remote principal object, generating an access token for the remote principal, the access token including the at least one right, and providing the access token to the remote principal to cause redirection of an interface, the interface providing access to the secured data resource by the remote principal.

In an embodiment of the at least one computer readable storage medium, the method includes, prior to the determining, causing a remote principal object to be generated in the first domain at the domain master, the remote principal object linking the remote principal to the right based on the set of permissions.

In an embodiment of the at least one computer-readable storage medium, generating the remote subject object is performed based on acceptance within the first domain of an access permission approval request for a secured data resource initiated and provided on behalf of the second domain.

In an embodiment of the at least one computer readable storage medium, generating the remote subject object includes determining a time validity period associated therewith, and the method includes performing, at the domain master and after expiration of the time validity period, at least one of: the remote subject object is deleted from the directory or the set of permissions and at least one associated access policy are deleted from the directory.

In an embodiment of the at least one computer readable storage medium, determining that the remote subject is associated with the remote subject object comprises: determining that the remote principal is also associated with another remote principal object, and generating an access token for the remote principal that includes at least one entitlement includes: the access token for the remote subject is generated to further include one or more entitlements to another secured data resource associated with another remote subject object.

In an embodiment of the at least one computer-readable storage medium, the access token includes an identifier of the remote subject object and does not include a personal identifier of the remote subject.

Another system is also described herein. According to an embodiment, the system is enabled and configured for authorizing a remote principal of a second domain to access secure data resources in a first domain. The system includes a processing system including one or more processors and at least one memory storing program code that is executed by the processing system to perform a method. The method includes generating, at and in association with a second domain, a data structure specifying the group, the data structure being based on access requirements for a secured data resource in a first domain of a domain master, the first domain being different from the second domain, and obtaining a permission template generated at the second domain, the permission template defining a set of permissions, the set of permissions including at least one right to the secured data resource by a member of the group. The method also includes generating an access policy for the secured data resource associated with the set of permissions, and providing the set of permissions and the access policy to a domain master of the first domain, the set of permissions and the access policy being immutable from the first domain. The method further includes providing, as a member of the group, an access permission approval request for the secured data resource to the first domain on behalf of the remote principal, the access permission approval request for the secured data resource resulting in generation of a remote principal object in a directory of the first domain at a domain master of the remote principal object, the remote principal object linking the group to at least one right of the secured data resource as enumerated in the set of permissions and specified by the access policy, based at least on an indication of approval of the access permission approval request from the first domain.

In an embodiment of the system, the method includes, after said providing the access permission approval request to the first domain on behalf of the remote principal, receiving a subsequent access permission approval request from the remote principal or another member of the group, determining at least one of an approval to remain valid in the directory or a remote principal object to remain valid, and notifying the remote principal or another member of the group of a valid approval for the subsequent access permission approval request.

In an embodiment of the system, the method includes receiving a request from a remote principal to add to the group, verifying credentials of the remote principal for a group access policy that is group-specific and stored at the second domain, and adding the remote principal to the group by storing remote principal information in a data structure.

In an embodiment of the system, the method includes receiving an indication of approval of the access rights approval request, and providing a notification of the approval to a remote principal in the second domain.

In an embodiment of the system, the access policy specifies a time validity period for the remote subject object, and the method comprises causing deletion of the remote subject object, the set of permissions, and the access policy at the domain master of the first domain based on at least one of: receiving an access right revocation or expiration of a time validity period from the first domain.

In an embodiment of the system, the method comprises, prior to said generating the data structure, receiving a task request from the first domain, wherein an access requirement for the secured data resource is associated with the task request and a task of the task request comprises an operation required for the secured data resource, and causing deletion of the set of permissions and the access policy at the domain master of the first domain based on a completion indication of the task.

In an embodiment of the system, the method comprises, prior to said generating the data structure, receiving a task request from the first domain, wherein an access requirement for the secured data resource is associated with the task request, the indication of acceptance being included in the task request, and the task of the task request including an operation required for the secured data resource.

Another method is also described herein. According to an embodiment, the method is for authorizing a remote principal of a second domain to access secure data resources in a first domain. The method includes generating, at and in association with a second domain, a data structure specifying the group, the data structure being based on access requirements for a secure data resource in a first domain of a domain master, the first domain being different from the second domain, and retrieving a permission template generated at the second domain, the permission template defining a set of permissions, the set of permissions including at least one right to the secure data resource by a member of the group. The method also includes generating an access policy for the secure data resource associated with the set of permissions, and providing the set of permissions and the access policy to a domain master of the first domain, the set of permissions and the access policy being immutable from the first domain. The method also includes providing, as a member of the group, an access rights approval request for the secured data resource to the first domain on behalf of the remote principal, the access rights approval request for the secured data resource resulting in generating, based at least on the indication of approval of the access rights approval request from the first domain, a remote principal object in a directory of the first domain at a domain host of the remote principal object, the remote principal object linking the group to at least one right of the secured data resource as enumerated in the set of rights and specified by the access policy.

In an embodiment, the method includes receiving a subsequent access permission approval request from the remote principal or another member of the group after said providing the access permission approval request to the first domain on behalf of the remote principal, determining at least one of an approval to remain valid in the directory or a remote principal object to remain valid, and notifying the remote principal or another member of the group of a valid approval for the subsequent access permission approval request.

In an embodiment, the method includes receiving a request from a remote principal to add to the group, verifying credentials of the remote principal for a group access policy that is group-specific and stored at the second domain, and adding the remote principal to the group by storing remote principal information in a data structure.

In an embodiment, the method includes receiving an indication of approval of the access rights approval request, and providing a notification of the approval to a remote principal in the second domain.

In an embodiment of the method, the access policy specifies a time validity period for the remote subject object, and the method comprises causing deletion of the set of permissions and the access policy at the domain master of the first domain based on at least one of: an access right revocation is received from the first domain or a time validity expires.

In an embodiment, the method comprises, prior to said generating the data structure, receiving a task request from the first domain, wherein an access requirement for the secured data resource is associated with the task request and a task of the task request comprises an operation required for the secured data resource, and causing a set of permissions and an access policy to be deleted at the domain master of the first domain based on a completion indication of the task.

In an embodiment, the method comprises, prior to said generating the data structure, receiving a task request from the first domain, wherein an access requirement for the secured data resource is associated with the task request, the indication of acceptance is included in the task request, and the task of the task request comprises an operation required for the secured data resource.

Also described herein is at least one additional computer-readable storage medium storing program instructions that, when executed by one or more processing devices, perform a method. According to an embodiment, the method is for authorizing a remote principal of a second domain to access secure data resources of a first domain. The method includes generating, at and in association with a second domain, a data structure specifying the group, the data structure being based on access requirements for a secure data resource in a first domain of a domain master, the first domain being different from the second domain, and obtaining a permission template generated at the second domain, the permission template defining a set of permissions, the set of permissions including at least one right to the secure data resource by a member of the group. The method also includes generating an access policy for the secured data resource associated with the set of permissions, and providing the set of permissions and the access policy to a domain master of the first domain, the set of permissions and the access policy being immutable from the first domain. The method also includes providing, as a member of the group, an access rights approval request for the secured data resource to the first domain on behalf of the remote principal, the access rights approval request for the secured data resource resulting in generating, based at least on the indication of approval of the access rights approval request from the first domain, a remote principal object in a directory of the first domain at a domain host of the remote principal object, the remote principal object linking the group to at least one right of the secured data resource as enumerated in the set of rights and specified by the access policy.

In an embodiment of the at least one computer-readable storage medium, the method includes receiving a subsequent access permission approval request from the remote principal or another member of the group after the providing of the access permission approval request to the first domain on behalf of the remote principal, determining at least one of an approval to remain valid in the directory or a remote principal object to remain valid, and notifying the remote principal or another member of the group of a valid approval for the subsequent access permission approval request.

In an embodiment of the at least one computer-readable storage medium, the method includes receiving a request from a remote principal to add to the group, verifying credentials of the remote principal based on a group access policy that is specific to the group and stored at the second domain, and adding the remote principal to the group by storing remote principal information in a data structure.

In an embodiment of the at least one computer-readable storage medium, the access policy specifies a time validity period for the remote subject object, the method includes causing deletion of the set of permissions and the access policy at a domain master of the first domain based on at least one of: receiving an access right revocation or expiration of a time validity period from the first domain.

In an embodiment of at least one computer readable storage medium, the method includes, prior to said generating the data structure, receiving a task request from the first domain, wherein an access requirement for the secured data resource is associated with the task request, and a task of the task request includes an operation required by the secured data resource, and causing deletion of the set of permissions and the access policy at the domain master of the first domain based on a completion indication of the task.

In an embodiment of the at least one computer readable storage medium, the method includes, prior to said generating the data structure, receiving a task request from the first domain, wherein an access requirement for the secured data resource is associated with the task request, the indication of acceptance is included in the task request, and a task of the task request includes an operation required for the secured data resource.

5. Conclusion

While various embodiments of the disclosed subject matter have been described above, it should be understood that they have been presented by way of example only, and not limitation. It will be understood by those skilled in the relevant art that various changes in form and details may be made therein without departing from the spirit and scope of the embodiments as defined in the appended claims. Thus, the breadth and scope of the disclosed subject matter should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

1. A system for authorizing a remote principal of a second domain to access secure data resources of a first domain, the system comprising:

a processing system comprising one or more processors; and

at least one memory storing program code to be executed by the processing system to perform a method comprising:

receiving, from an interface associated with a remote principal, a request to access a first domain of a domain master, the first domain being different from the second domain, the request including an identifier of the remote principal and second domain credentials;

determining that a remote subject object generated and stored at a directory of the domain master and inaccessible from the second domain exists and is valid in the directory;

verifying that the remote principal is identified as being associated with a group of the second domain having at least one right to the secure data resource as enumerated in a set of permissions and at least one associated access policy defined by the second domain and represented in the remote principal object;

generating an access token for the remote principal, the access token including the at least one entitlement; and

providing the access token to the remote subject to cause redirection of the interface that provides the remote subject access to the secured data resource.

2. The system of claim 1, wherein the method comprises:

prior to the determining, causing generation of the remote principal object in the directory of the first domain at the domain master, the remote principal object linking the remote principal to the rights based on the set of permissions.

3. The system of claim 2, wherein the generating the remote subject object is performed based on an acceptance within the first domain of an access permission approval request for the secured data resource initiated and provided on behalf of the second domain.

4. The system of claim 2, wherein the generating the remote subject object comprises determining a time validity period associated therewith; and is

Wherein the method comprises, at the domain master and after expiration of the time validity period, performing at least one of:

deleting the remote subject object from the directory; or

Deleting the set of permissions and the at least one associated access policy from the directory.

5. The system of claim 1, wherein the method comprises:

after the providing the access token, generating an audit report, the audit report including at least one of:

one or more entries for operations performed by the remote subject on the secured data resource that do not include a personal identifier of the remote subject, or

Indicia of the set of permissions associated with the remote subject object.

6. The system of claim 1, comprising:

a cloud-based services platform comprising a security token service configured to generate the access token; and is provided with

Wherein the domain master comprises a first tenant of the cloud-based services platform and the second domain comprises a second tenant of the cloud-based services platform.

7. The system of claim 1, wherein the method comprises:

after said receiving, verifying that an entry for said identity of said remote principal does not exist in said directory in said first domain and exists in a directory in said second domain; and

performing the determination in response to the verification.

8. A method for authorizing a remote principal of a second domain to access secure data resources of a first domain, the method comprising:

receiving, from an interface associated with the remote principal, a request to access a first domain of a domain master, the first domain being different from the second domain, the request including an identifier of the remote principal and second domain credentials;

verifying that the remote principal is identified as being associated with a group of the second domain having at least one right to the secured data resource as enumerated in a set of permissions and at least one associated access policy defined by the second domain and represented in the remote principal object;

generating an access token for the remote, the access token including the at least one entitlement; and

9. The method of claim 8, wherein the method comprises:

10. The method of claim 9, wherein the generating the remote subject object is performed based on an acceptance within the first domain of an access permission approval request for the secured data resource initiated and provided on behalf of the second domain.

11. The method of claim 9, wherein the generating the remote subject object comprises determining a time validity period associated therewith; and is

deleting the remote subject object from the directory; or alternatively

12. The method of claim 8, wherein the method comprises:

one or more entries for operations performed by the remote principal on the secured data resource, or

Indicia of the set of permissions associated with the remote subject object.

13. The method of claim 8, wherein the generating the access token is performed by a security token service thereof at a cloud-based service platform; and is

14. The method of claim 8, wherein the method comprises:

identifying one or more remote subject objects in the directory of the first domain that are associated with the second domain; and

determining that at least one of the one or more remote subject objects has a group attribute; and is

Wherein the remote subject object is included in the at least one of the one or more remote subject objects, and

wherein the determining that the remote subject is associated with the remote subject object comprises determining that the remote subject is identified as a member of the group as represented in the remote subject object.

15. At least one computer readable storage medium storing program instructions which, when executed by one or more processing devices, perform the method for authorizing a remote principal of a second domain to access secured data resources of a first domain according to any one of claims 8 to 14.