Temporary Cloud Provider Credentials via a Secure Discovery Framework

Abstract

Cloud provider accounts can be integrated into software-as-a-service platforms. Configuration options can be provided to support various levels of granularity, such that different cloud provider accounts can be provided to different tenants, workgroups, users, applications, etc. From a user's perspective, the fact that data is stored in a cloud provider account can be transparent in that the same features and authentication processes can be supported across different cloud provider types. In fact, limited, temporary, derived credentials can be generated from underlying credentials to provide fine-grained control of access to cloud provider account resources while avoiding operational overhead.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 087,155, filed October 2, 2020, and U.S. Provisional Patent Application No. 63 / 045,736, filed June 29, 2020, both of which are incorporated herein by reference in their entireties.

[0002] FIELD OF THE INVENTION The technical field generally relates to supporting secure access to cloud provider resources in multi-tenant software-as-a-service (SAAS) scenarios. [Background technology]

[0003] Research on genomic data can involve complex analysis by various parties with different expertise collaborating over time. Research typically begins with genomic data, which may come from a variety of sources. A wide variety of techniques can then be used to analyze the data. Today's research projects can involve parties spread across the globe sharing and / or collaborating on data analysis. While progress has been made in the field and international standards for sharing genomic data have been developed, significant challenges to sharing genomic data remain. Summary of the Invention

[0004] This Summary is provided in a simplified form to introduce various concepts 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.

[0005] In one embodiment, a method includes, in a computing system supporting multiple tenants accessing genomic computing services in a software-as-a-service platform that orchestrates access to genomic digital data resources through policy-based access control, discovering a cloud provider account for an identity accessing the software-as-a-service platform, sending a request to a credential management service for a restricted, temporary, derived credential that is valid for the cloud provider account, receiving the restricted, temporary, derived credential that is valid for the cloud provider account, and providing the restricted, temporary, derived credential for use by the identity.

[0006] In another embodiment, a multi-tenant cloud-based system comprises one or more processors; memory coupled to the one or more processors; a mapping between identities accessing a software-as-a-service platform and cloud provider accounts; a policy store including policy-based access control definitions; and genomic digital data resources linked to role identifiers and stored at a given cloud provider account external to the software-as-a-service, wherein the memory includes computer-executable instructions that cause the one or more processors to perform operations, the operations including discovering a cloud provider account for an identity accessing the software-as-a-service platform based on the mapping; sending a request to a credential management service for a limited, temporary, derived credential that is valid for the cloud provider account; receiving the limited, temporary, derived credential that is valid for the cloud provider account; and providing the limited, temporary, derived credential for use by the identity to access the genomic digital data resources.

[0007] In another embodiment, one or more computer-readable media include computer-executable instructions that can cause a computing system supporting multiple tenants accessing genomic computing services in a software-as-a-service platform that orchestrates access to genomic digital data resources through policy-based access control to: discover a cloud provider account for an identity accessing the software-as-a-service; send a request to a credential management service for a restricted, temporary, derived credential that is valid for the cloud provider account; receive the restricted, temporary, derived credential that is valid for the cloud provider account; and provide the restricted, temporary, derived credential for use by the identity to access genomic digital data resources in accordance with the policy-based access control; wherein the software-as-a-service platform supports multiple different cloud provider account types per tenant; and wherein the software-as-a-service platform supports multiple different cloud provider accounts per tenant. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a block diagram of an exemplary system implementing policy-based genomic digital data sharing. [Figure 2] 1 is a flowchart of an exemplary method for implementing policy-based genomic digital data sharing. [Figure 3] FIG. 1 is a block diagram of an exemplary system including a platform that implements policy-based genomic digital data sharing via signed access tokens. [Figure 4] 1 is a flowchart of an exemplary method for implementing policy-based genomic digital data sharing via signed access tokens. [Figure 5]FIG. 1 is a block diagram of an example system for generating a signed access token based on an access request and a policy document. [Figure 6] 1 is a flowchart of an example method for generating a signed access token based on an access request and a policy document. [Figure 7] A visualization of supported scenarios. [Figure 8] FIG. 2 is a block diagram of an example policy document. [Figure 9] FIG. 1 is a block diagram of an example signed access token. [Figure 10] FIG. 1 is a block diagram of an example system for generating an access token based on attributes of an access request and conditions of a policy document. [Figure 11] 1 is a flowchart of an exemplary method for generating an access token based on attributes of an access request and conditions of a policy document. [Figure 12] FIG. 1 is a block diagram of a system for publishing genomic content for policy-based sharing. [Figure 13] 1 is a flowchart of an exemplary method for publishing genomic content for policy-based sharing. [Figure 14] 1 is a flowchart of an exemplary method for accessing publicly shared genomic content. [Figure 15] 1 is a flowchart of an exemplary method for registering an external service provider. [Figure 16] 1 is a flowchart of an exemplary method for integrating external service providers into a policy-based sharing platform. [Figure 17] FIG. 1 is a block diagram of an example system for verifying signed access tokens. [Figure 18] FIG. 1 is a block diagram illustrating the integration of smart contracts into a policy-based sharing platform. [Figure 19] 1 is a flowchart of an exemplary method for implementing smart contracts in a policy-based sharing platform. [Figure 20] FIG. 1 is a flow diagram of an exemplary disclosure use case. [Figure 21] FIG. 10 is a flow diagram of an example external service provider use case involving registration. [Figure 22] FIG. 1 is a flow diagram of an example external service provider use case involving integration. [Figure 23] FIG. 1 is a block diagram of an exemplary computing system that implements temporary restricted derived credentials. [Figure 24] 1 is a flowchart of an exemplary overall method for providing temporary, restricted derived credentials. [Figure 25] 1 is a flowchart of an example method for managing cloud provider accounts to provide temporary, restricted derived credentials. [Figure 26] FIG. 1 is a sequence diagram of an example implementation of a method for managing cloud provider accounts to provide temporary, restricted derived credentials. [Figure 27] 1 is a flowchart of an example method for providing a restricted temporary derived credential. [Figure 28] FIG. 1 is a sequence diagram of an example implementation of a method for providing restricted temporary derived credentials. [Figure 29] FIG. 2 is a block diagram of an example cloud provider mapping. [Figure 30] 10 is a screenshot of an exemplary user interface for providing a restricted temporary derived credential. [Figure 31] FIG. 2 is a block diagram of an example credential object for the underlying credential. [Figure 32] FIG. 2 is a block diagram of an exemplary identity hierarchy. [Figure 33] FIG. 1 is a block diagram of an exemplary computing system in which the described embodiments may be implemented. [Figure 34]FIG. 1 is a block diagram of an exemplary cloud computing environment that can be used in conjunction with the techniques described herein. DETAILED DESCRIPTION OF THE INVENTION

[0009] Example 1 - Overview The ever-growing availability of genomic data presents new opportunities for research and analysis. Today's sequencing platforms can generate a wide variety of sequence outputs, including whole-genome sequencing (WGS). Various organizations, such as the Global Alliance for Genomics & Health, have developed standards for sharing genomic data. However, in practice, today's genomic information ecosystem can sometimes appear fractured. Data can be separated or siloed due to various considerations, including technical, security, legal, and financial reasons. Even when data is publicly available, it may not be fully integrated to be immediately useful.

[0010] One major hurdle is sharing information between parties. A completely open platform that allows every participant to share all of every other participant's data is neither realistic nor desirable. However, a policy-based approach to sharing genomic digital data between software-as-a-service tenants can enable parties to share data in a controlled way that fosters collaboration between parties. Public data can be included, and external service providers can participate. Access control can be automated and more easily controlled, without the need for lengthy and complex manual security operations.

[0011] As a result, cloud-based platforms can act as virtual spaces where actors from diverse backgrounds and institutions can collaborate and share data, knowledge, tools, workflows, and applications to converge on innovative insights and arrive at new solutions.

[0012] Additionally, the techniques described herein can support cloud provider accounts in a manner that is easily maintained and transparent to users. As described herein, multiple cloud provider types can be supported for a single tenant on a single platform. Cross-tenant scenarios can also be supported. Bounded, temporary, derived credentials can be provided to access the appropriate cloud provider account.

[0013] Freed from technological limitations, data can move where it is needed, potentially resulting in a more collaborative ecosystem. As the technology applies to genomic digital data generally, it can be applied across numerous use cases involving the storage, retrieval, and analysis of genomic digital data.

[0014] Example 2 - Exemplary System Implementing Policy-Based Genomic Digital Data Sharing 1 is a block diagram of an exemplary system 100 that implements policy-based genomic digital data sharing. In an example, multiple tenants 110A-N with associated user identifiers 120 access an application hosting platform instance 135 running on a data center 130. The platform instance 135 includes a platform authentication service 140, multiple hosted applications 150A-N, an operations service 158, a policy store 160 (e.g., having policy documents described herein), and an authentication token 170. As described herein, some scenarios may include trust documents (not shown) that may affect policy-based access to genomic digital data.

[0015] Applications 150A-N as part of their processing may access one or more genomic data services 190A-N, which typically provide genomic digital data.

[0016] In practice, systems illustrated herein, such as system 100, may vary in complexity with additional functionality, more complex components, etc. For example, multiple data centers 130 may be implemented, and such data centers may implement multiple application hosting platform instances 135. Additional components may be included to implement security, redundancy, load balancing, report design, etc.

[0017] The described computing systems may be networked via wired or wireless network connections, including the Internet, or the systems may be connected via intranet connections (e.g., in corporate, government, etc. environments).

[0018] System 100 and any of the other systems described herein may be implemented in conjunction with any of the hardware components described herein, such as the computing systems (e.g., processing units, memories, etc.) described below. In any of the examples herein, genomic digital data, policy documents, authentication tokens, etc. may be stored on one or more computer-readable storage media or devices. The techniques described herein may be general to operating system or hardware details and may be applied in any of a variety of environments to take advantage of the features described.

[0019] Example 3 - Exemplary Method for Implementing Policy-Based Genomic Digital Data Sharing FIG. 2 is a flowchart of an exemplary method 200 that implements policy-based genomic digital data sharing and may be performed, for example, by the system of FIG. 1 (eg, application hosting platform instance 135).

[0020] At 210, a new tenant 210 is onboarded. As a result, the tenant is assigned a tenant identifier and is given the ability to share genomic digital data via the tenant identifier. In practice, such onboarding can occur any time before a request to publish data for sharing is received and need not be considered part of the publication / access scenario.

[0021] At 220, the platform receives a request from a tenant to publish genomic digital data within the system, the request including a policy document that controls sharing. In a software-as-a-service platform that orchestrates access to genomic digital data resources through policy-based access control, in a computing system with multiple tenants seeking access to genomic digital data resources provided by one or more genomic data services, a policy-based access control definition (e.g., a policy document) of a first one of the tenants for a given genomic digital data resource can be received. The definition can be received from the first one of the tenants or another party (e.g., in an external service provider scenario).

[0022] A request to access the shared genomic digital data is received from another tenant at 240. A request to access the given genomic digital data resource is received from a second one of the tenants seeking access to the given genomic digital data resource.

[0023] At 250, a request to access the shared genomic digital data is granted based on (e.g., in accordance with) a policy document configured by the owning tenant (e.g., the tenant that shared the data). Access is granted based on a policy-based access control definition. As described herein, a token may be provided in the request for access. The token may be generated based on an associated policy and then used to control access to the data (e.g., using a role identifier described herein). Access to a given genomic digital data resource may be controlled by a role identifier linked to a policy-based access control definition.

[0024] In practice, a single party (e.g., operating the platform) can perform all of the actions shown; however, it is also possible for one party to perform only some actions (e.g., onboarding) and another to perform others (e.g., granting). Division of tasks can also be along domain lines (e.g., one party performs functions related to publishing and another performs functions related to granting access).

[0025] The illustrated actions can be interpreted from alternative perspectives while implementing the technology, for example, "receiving a request" can also be interpreted as "sending a request" from the tenant's perspective.

[0026] Method 200 and any of the other methods described herein may be implemented by computer-executable instructions stored on one or more computer-readable media (e.g., storage devices or other tangible media) or stored on one or more computer-readable storage devices (e.g., causing a computing system to perform the instructions). Such methods may be implemented in software, firmware, hardware, or a combination thereof. Such methods may be at least partially implemented by a computing system (e.g., one or more computing devices).

[0027] When implemented on a computer-readable medium, the techniques may include computer-executable instructions that can cause a computing system to perform each of the method steps.

[0028] Example 4 - Exemplary Genomic Digital Data In any of the examples herein, genomic digital data may be subject to policy-based sharing. Such data may take the form of sequenced DNA, RNA, etc. (For example, the output of a sequencer takes the form of a digital representation of strands of DNA, typically consisting of the four nucleotides adenine (A), cytosine (C), guanine (G), and thymine (T). Nucleotides can be represented digitally in a variety of ways and encodings, but typically have equivalent string representations of A's, C's, G's, and T's, which are used for convenience of explanation. While a DNA example is given, RNA sequencing can be used as well. Similarly, the term "genomic" encompasses information from genomes, exomes, and transcriptomes.

[0029] In practice, sequence information is accompanied by other useful information for research, including substantive data such as the source of the DNA (e.g., subject demographics, subject pathology, etc.). Disease and phenotype information can be included and / or associated with the genomic digital data. Sequencing metadata can also be included (e.g., the machine / instrument and technique used to sequence the DNA, the sequenced data, sequencing yield, quality metrics, a pointer to the sequencing run record, etc.). Other metadata, such as the name of the originating party, legal restrictions, etc., can also be included.

[0030] To facilitate sharing, data may be provided in a common format that allows analytics and workflows to be used across tenants, which may be proprietary or open to facilitate the open exchange of information in sharing scenarios.

[0031] Policy-based sharing can be extended to other genomic data, such as executable workflow definitions related to genomic digital data. Thus, tenants can access both executable workflows for processing genomic digital data as well as the underlying data itself through the policy-based sharing techniques described herein. A shared executable workflow definition can originate from one source (e.g., a tenant), while the underlying data originates from the same or a different source (e.g., the same or a different tenant). Such executable workflows can be associated with established protocols for reliability, consistency of results, etc. Thus, for a particular research project, a given executable workflow can be shared among participants. Custom executable workflows can be developed by tenants and shared similarly.

[0032] Executable workflows can be executed (e.g., interpreted) by an engine or service that interfaces with sequencing equipment, thereby greatly simplifying, automating, and increasing the reliability and reproducibility of the sequencing process. Error recovery and other features can be incorporated into such executable workflows. Workflows can be aimed at various sequencing and related analytical tasks, such as demultiplexing, mapping and aligning, position sorting, duplicate marking, variant calling, etc. Specialized workflows devoted to tumor-only or tumor-normal modes can be designed to detect somatic variants in tumor samples. Many other scenarios are possible.

[0033] Due to the long computation times and large amounts of data, such workflows can provide speed, flexibility, and cost-effectiveness, allowing laboratories of various sizes and disciplines to better leverage their genomic data. The sharing techniques described herein can better leverage such data across tenants.

[0034] For convenience, the shared genomic digital data may be referred to as a "resource" or a "protected resource," indicating that the data is a resource to which access is controlled via the policies described herein.

[0035] Genomic digital data may be provided by a genomic data service, which may enforce access controls and cooperate with the platform to recognize and validate access tokens, as described herein.

[0036] Example 5 - Exemplary Software Tenant Any of the embodiments herein may support a variety of software tenants, which may conveniently be referred to as "tenants." Such tenants typically take the form of enterprise tenants, such as businesses, government entities, research institutions or groups, educational institutions or groups, user organizations, etc. By utilizing the techniques described herein, such tenants can significantly benefit from policy-based sharing.

[0037] Any given user of the platform can be assigned to a tenant. In a multi-tenant cloud system, users can share computing resources but have a personalized and customizable user experience and individual stored data. In practice, a tenant tends to represent a single legal entity that has a single agreement with the platform provider. Thus, a user identifier is typically associated with a single tenant, and services are provided to the user based on the agreement between the cloud provider and the tenant.

[0038] Tenants may share computing resources operated by the cloud service provider, but the distinguishing factor between tenants is that different tenants may have different subscriptions, different storage limits, and levels of access to the platform's genomic digital data and services. Various other customizations can be made. Tenants are not necessarily application owners, as the application owner may be the cloud provider or a third party. However, some tenants may develop their own applications.

[0039] In cloud-based scenarios, the framework is provided transparently to users to leverage redundancy of functionality and processes between tenants. However, boundaries between tenants may be enforced to prevent one tenant from accessing another tenant's data. Each tenant's data may be isolated and remain invisible to other tenants. Such arrangements are typically a fundamental characteristic of multi-tenant systems. However, while such isolation is typically desirable, for some data, there are significant advantages to enabling policy-based sharing between tenants as described herein.

[0040] Thus, the described platform can have characteristics of a traditional cloud-based multi-tenant system, but can also enable controlled sharing between and among tenants, including the proxy tenants described herein.

[0041] Example 6 - Exemplary Proxy Tenant In any of the embodiments herein, a proxy tenant can be implemented. The proxy tenant can be registered as a tenant and can have a tenant identifier, but the tenant identifier is not used in the capacity of normal tenant functionality, regardless of whether the entity being represented is an actual tenant of the platform. For example, in a public sharing scenario, because the data is public, a proxy tenant can be set up for public data, regardless of whether the source (e.g., owner) of the data is actually involved (e.g., a website, government agency, foundation, etc.). The proxy tenant has a tenant identifier, and the digital genome digital data can be published under the tenant identifier. In this way, public sharing scenarios can be supported by the platform. In practice, the data-owning proxy tenant may also have an actual tenant identifier. In that way, an organization may have multiple tenant identifiers, one used in the capacity as a source of public genome digital data, another used in the capacity as a research institution using normal tenant functionality, etc.

[0042] Similarly, in an external service provider scenario, a proxy tenant can be set up for the external service provider. The external service provider can be assigned a tenant identifier that can be used to access and upload data to the platform for sharing under the tenant identifier. In this way, the external service provider can be supported by the system. Again, the external service provider can also have an actual tenant identifier that is used when the external service provider acts in the capacity of a regular tenant.

[0043] Finally, a platform operator or other similar party may act in the capacity of a tenant or tenant agent to provide any of the tenant-based features described herein. Such an arrangement may be useful in cases where a tenant is unwilling, unavailable, or unable to engage with the platform.

[0044] Thus, in any of the embodiments herein, a tenant may be a proxy tenant, and the tenant identifier of such a tenant may be processed in accordance with the techniques described herein to achieve policy-based sharing.

[0045] Example 7 - Exemplary Roll In any of the examples herein, roles can be used to control access to shareable genomic digital data. As described herein, roles can be uniquely identified by a role identifier. Such a role identifier can be created when a tenant wants to expose a resource for sharing and can be linked to a policy document for a given resource.

[0046] Example 8 - Exemplary Role Bindings To achieve the techniques described herein, late binding of roles to users can be implemented. In a late binding scenario, a user identifier (or a tenant identifier of a user identifier) ​​can be bound to a role identifier at runtime (e.g., when access to a resource is requested, when a list of available resources is requested, etc.) instead of upfront. In this way, role assignments can be dynamic in that if policies change, role assignments can also change automatically. Thus, roles can change over time without explicitly specifying a particular user. A user's membership in a tenant or workgroup can change role assignments if policies reference such attributes. As described herein, binding can occur on demand and can be based on the user identifier or tenant identifier of the request.

[0047] Similarly, policy-based sharing means that any change to the policy can result in a change to the share (e.g., role assignment). Policies that further depend on other factors (e.g., agreement status, agreement level, subscription status, subscription level, etc.) can cause changes to role assignments if such factors change. For example, if a tenant obtains a new subscription level, users from the tenant can be automatically granted additional access because the next time a user of the tenant requests access, roles can be assigned at runtime.

[0048] Thus, the late binding of roles and the dynamic nature of role assignment can support a wide variety of flexible and automated scenarios that avoid the prior assignment of individual roles to specific users, thus significantly reducing the resources required to operate the system while providing such rich functionality.

[0049] Additional roles may be provided at the application level (e.g., enforced by the application). Such roles may have early or late binding. For example, an application role identifier may specify lab manager, supervisor, assistant, etc. The application role identifier itself may be used in condition statements that control access to policy-based roles. In such cases, in response to determining that an access request has an attribute indicating a role identifier that satisfies the condition specified in the policy document, the role is included in the appropriate permissions (e.g., as specified for the role) in the signed access token.

[0050] Example 9 - Exemplary Authorization In any of the embodiments herein, permission to share a resource can be specified by specifying a service type, a resource type, and a permission type (e.g., "GSS FILES.UPDATE", "GSS.LIBRARYPOOLS.READ", etc.).

[0051] Permission types may include manage, archive, create, delete, destroy, download, hide, lock, read, update, write, administer, run, grant, etc. Resource types may include subscription, file, sequencing run, library pool, library prep kit, analysis version, task version, task, run, workflow, etc.

[0052] Service types can include genomic data services, workflow execution services, and the like.

[0053] Example 10 - Exemplary Platform In any of the examples herein, an infrastructure that provides policy-based sharing may be referred to as a "platform." Such a platform may be integrated into a multi-tenant cloud-based platform that provides access to multiple applications by tenants. As described herein, such a platform may become a virtual place where tenants can collaborate via the sharing functionality described herein.

[0054] The platform can be implemented as a software-as-a-service (SaaS) platform that orchestrates access to genomic digital data resources via the policy-based access control techniques described herein.

[0055] Various portions of functionality may be referred to as being inside or outside the platform, although either arrangement may be implemented. For example, some functionality may be delegated to other service providers or brought into the platform as desired. In some cases, functionality may be described as being in an authentication services platform that may be separate from or integrated into the overall multi-tenant cloud-based platform.

[0056] Example 11 - Exemplary System with Platform Implementing Policy-Based Sharing FIG. 3 is a block diagram of an exemplary system 300 including a platform 350 that implements policy-based genomic digital data sharing via signed access tokens 372.

[0057] Although the application is not shown, in reality the actual sharing functionality can be invoked by an application running on behalf of the tenant and requesting access to the genomic digital data 397 via the platform 350 and supporting software.

[0058] In this example, the owning tenant 310A controls access to the genomic digital data 397. Such control is achieved by configuring a policy document 360 (e.g., via an administration user interface). Configuration may include creating a custom role identifier 374 for inclusion in the policy document 360. Such configuration may be included as part of a publishing process if the tenant 310A wishes to publish the data 397 for sharing. Although not shown, publishing may also include the generation of a signed grant token as described herein.

[0059] Subsequently, if tenant 310B wishes to access data 397, it can do so by sending request 320 to platform 350. Policy document 360 controls the generation of signed access token 372 (which may also include, for example, role identifier 374), as described herein.

[0060] Tenant 310B can then send access token 372 with role identifier 374 to the genomic digital data service, which provides access to genomic digital data 397 based on token 372.

[0061] Example 12 - Exemplary Method for Implementing Policy-Based Sharing FIG. 4 is a flowchart of an exemplary method 400 that implements policy-based genomic digital data sharing via signed access tokens and may be implemented, for example, by the system shown in FIG. 3 (e.g., by platform 350).

[0062] In any of the embodiments herein, in response to receiving an access request, a role identifier specified in a policy-based access control definition (e.g., a policy document) can be provided for the access request. The role identifier can then be included in a signed access token.

[0063] In this example, at 410, a policy configuration with a role identifier is received from a controlling (eg, owner or agent) tenant.

[0064] At 420, a request to access data controlled by the policy configuration is received from another tenant. As described herein, such a request may include a request for a token.

[0065] At 430, the request is granted based on a configured policy (e.g., a policy document configured by the controlling tenant). For example, based on the policy, a signed access token (e.g., having a role identifier) ​​can be provided at 440. At 450, the access request can be granted based on the signed access token (e.g., based on the presence of an appropriate scope for the role identifier).

[0066] Example 13 - Exemplary Tenant-in-Own In any of the examples herein, the term "owning tenant" can be used to express that policy-based sharing is essentially tenant-to-tenant based sharing. An owning tenant can grant access to genomic digital data to which the owning tenant already has access. By publishing data and configuring policy documents, other tenants can access the owning tenant's data.

[0067] In practice, the owning tenant may delegate a share of the operation to another tenant, who may then become a tenant for common purposes. Thus, the owning tenant may also be referred to as the "primary tenant."

[0068] Example 14 - Exemplary Access Request In any of the examples herein, the access request can take a variety of forms. For example, the access request can specify the genomic digital data desired to be shared (e.g., using an identifier). Alternatively, a general request can be submitted, providing a list of available resources and associated identifiers for selection. The access request can then be completed by providing the identifier of the specific resource desired.

[0069] In practice, the access request may be provided via communication between the application and a platform that provides policy-based shared services.

[0070] A signed access token can be received in response to the request, and the token is used to actually control access to the protected resource.

[0071] In a session-based system, an access request can be sent when a session begins (e.g., a user authenticates), and an access token can be generated based on the user identity. Applications created from the session can then access resources indicated by the roles in the access token.

[0072] Example 15 - Exemplary Invitation In any of the embodiments herein, an invitation process can be used to invite tenants for sharing. For example, a newly onboarded tenant can receive a particular invitation by default. Other tenants can receive an invitation when signing up for a particular application or service. For example, an application subscription model can provide access to the application (e.g., any shared associated public data as described herein) upon subscribing to the application. Other tenants can receive an invitation as part of being added to a policy document.

[0073] In practice, invitations may be controlled by a policy document or other resource that indicates when sharing is initiated.

[0074] The invitation process may include legal compliance, identity verification, key exchange, trust delegation, and the like.

[0075] Example 16 - Exemplary System for Generating Signed Access Tokens FIG. 5 is a block diagram of an example system 500 that generates a signed access token 572 based on an access request 520 and a policy document 560 .

[0076] In this example, a user identifier 505 for a given tenant is accessing an application 510 that requests access to the underlying genomic digital data 597 .

[0077] The access request 520 may include multiple attributes, and in an embodiment includes a user identification set 530 that includes a workgroup identifier 535 , a tenant identifier 537 , and an application identifier 540 .

[0078] A platform authentication service token generator (e.g., authentication service 140 of FIG. 1 or platform 350 of FIG. 3) receives access request 520 as input and generates signed access token 572 based on policy document 560. In this example, user identification set 530 and application identifier 540 support access, so token 572 includes role identifier 574 and tenant identifier 576 of the issue's tenant (e.g., the associated user is the user).

[0079] When provided with a signed access token 572, the genomic data service 590 can validate the token and provide access based on the presence of a role identifier 574, which can also be used in the access control list 595 of the genomic data service 590 to provide access to the underlying data 597.

[0080] Further security can be provided via grant tokens as described herein.

[0081] Example 17 - Exemplary Method for Generating a Signed Access Token FIG. 6 is a flowchart of an example method 600 for generating a signed access token, which may be implemented, for example, by the system shown in FIG. 5 (eg, by token generator 550).

[0082] An access request is received from a user identity set at 610. In practice, an application used by a user having a user identity set may actually send a request on behalf of the user's user identity.

[0083] At 620, a role identifier is included in the signed access token based on one or more attributes of the policy document associated with the protected resource and the access request. For example, in a scenario where all tenants using a particular application are granted access, the role identifier can be included in response to determining that the access request comes from an instance of the application. If all tenants that have the application are granted such access, the user's identity may not play a role in the decision. However, in an inter-tenant sharing scenario, tenant identity may be the controlling factor (e.g., the tenant identifier of the requesting tenant must match the conditions specified in the policy document). The workgroup identifier of the request may or may not be the controlling factor, depending on the conditions specified in the policy document.

[0084] At 640, the signed access token with the role identifier is sent to the genomic data service.

[0085] Access to the genomic digital data can then be granted based on the role identifier.

[0086] Example 18 - Exemplary Applications 5, an application 510 can send an access request on behalf of a user identifier 505. In any of the examples herein, the request may be described as coming from a tenant or user identifier, but in reality, the application can act on behalf of such a tenant or user identifier. An application instance can be associated with an authenticated user identifier and / or tenant identifier used for security purposes (e.g., authenticating the request, determining the tenant identifier, determining the workgroup identifier, etc.).

[0087] Such applications can take a variety of forms and can be used to acquire, manage, and analyze genomic digital data as described herein.

[0088] Example 19 - Exemplary Supported Scenarios FIG. 7 is a visualization 700 of supported scenarios 710 that can be implemented via the techniques described herein.

[0089] Public access sharing 720 can be implemented as described herein by publishing genomic digital data that is, or is desired to be, public under a tenant identifier used to construct a policy document describing that data is available (e.g., to all users, all users of a given application, or some other criteria).

[0090] An example of public access sharing can be implemented with respect to an application. Thus, for example, tenants subscribing to a particular application can be granted access to a collection of public data in a format compatible with the application. In such a case, a policy document may be provided to all tenants (e.g., "tid: * :) can specify that requests from an application (e.g., "Application:Olympia") are granted access to the shared public data.

[0091] Inter-tenant sharing 730 can be implemented as described herein by publishing genomic digital data under a tenant identifier that configures a policy document that specifies the conditions governing sharing (e.g., other tenants can access the data). An invitation process can be involved, but other tenants do not need to configure role identifiers, as the controlling tenant can do so.

[0092] Workgroup-based sharing 740 can be implemented as described herein by publishing genomic digital data under a tenant identifier that configures a policy document that specifies the conditions governing sharing (e.g., one or more workgroups can access the data). An invitation process can be involved, but members of the workgroup do not need to configure role identifiers, as the controlling tenant can do so. Workgroups can be intra-tenant or inter-tenant (e.g., spanning multiple tenants).

[0093] Sharing 750 with external service providers can also be implemented as described herein, even if they are not operating in the capacity of the appropriate tenant, by creating a special tenant identifier for the external service provider. In this way, the external service provider can access genomic digital data on the platform, perform analyses thereon, and publish the results back to the platform for access by the tenant (e.g., that requested the external service provider perform the analysis).

[0094] Other scenarios are possible because policy documents can contain a rich set of conditions that allow sharing. Runtime policy document evaluation can be used, avoiding extensive reconfiguration of individual user roles by tenant operators.

[0095] Example 20 - Exemplary Workgroup In any of the embodiments herein, any number of users may be assigned to be members of a workgroup identified by a workgroup identifier within the platform. Such users may be in the same tenant or may span across tenants. Workgroup membership may be controlled by an administrator or by a programmatic process.

[0096] Example 21 - Exemplary Token Signature In any of the embodiments herein, the access token or grant token may be digitally signed by the controlling tenant for authentication purposes. In practice, a public-private key encryption approach may be used, where the token is signed with the tenant's private key and authenticated with the tenant's public key.

[0097] In practice, the platform operator's or agent's keys can be used in place of tenant keys to simplify operations: any keys that can be trusted and verified by the platform can be used to achieve the trust relationship that is enforced to prevent unauthorized sharing between tenants.

[0098] Example 22 - Exemplary Policy Document In any of the examples herein, policy documents can be used to control sharing. Such policy documents can therefore function as policy-based access control definitions. As described herein, policy-based access control definitions can be evaluated at the time an access request is received.

[0099] 8 is a block diagram of an example policy document 860 that can be used in any of the embodiments herein. In practice, policy document 860 is configured (e.g., created, read, updated, or deleted) by the tenant that controls the resource (e.g., genomic digital data) with which policy document 860 is associated in the platform. For example, an administration user interface can be provided for access by the tenant's operator user, or configuration can be programmable, if desired.

[0100] As described herein, policy document 860 can filter access requests based on application identifier or name, identity (e.g., tenant identifier, workgroup identifier, etc.), etc. Although not shown, policy document 860 can be linked (e.g., mapped) to role identifiers (e.g., controlled by constituent tenants), and thus policy document 860 achieves overall access control by acting as a gatekeeper to role identifiers, which may ultimately be used to authorize access to protected shareable resources.

[0101] Various formats can be used to achieve filtering. In this example, policy document 860 can include metadata 861 (e.g., date, version, etc.) and one or more statements 862. A statement can take the form of an effect, tenant identification parameters 863, and zero or more conditions 864. An effect can specify that the effect takes effect if any of identity parameters 863 and conditions 864 are met. Such an effect can be that sharing is permitted (e.g., "allowed"), or that a particular type of sharing is permitted (e.g., read-only, read-write, etc.), or that permissions as described herein are granted. However, the type of sharing can alternatively be achieved by creating different role identifiers with different levels of access.

[0102] In practice, identity 863 is listed separately to emphasize that tenant identification parameters are typically specified as part of policy document 860 and effectively function as conditions. For example, a specific tenant, a list of tenants, or a wildcard can be listed as a tenant identity parameter. If a request comes from a tenant identifier that satisfies the tenant identifier parameter, the parameter is considered satisfied, and if any condition 864 is also satisfied, the statement is executed.

[0103] As described herein, a given condition 864 can include filter parameters such as an application identifier, a workgroup identifier, an application role identifier, etc. Requests with attributes that satisfy the condition cause the statement to be executed (e.g., allow access). Thus, access to the underlying role can be filtered based on such attributes.

[0104] If the policy document is satisfied, the linked role identifier is included in the generated access token as described herein.

[0105] Additional functionality or configurations can be incorporated into policy document 860 as desired to extend sharing functionality. For example, policy document 860 can incorporate or reference trusted external resources, such as smart contracts as described herein.

[0106] Example 23 - Exemplary Signed Access Token In any of the embodiments herein, a shared access token can be generated based on a policy document and an incoming access request (e.g., via a role identifier) ​​that controls access to resources linked to the policy document.

[0107] 9 is a block diagram of an example signed access token 972 that may be used in any of the embodiments herein. In practice, the actual token 972 may take a different form, having more or fewer fields therein.

[0108] The subject 974 may be a system user identifier.

[0109] The issuer 976 may indicate which instance of the platform authentication system issued the token, or the issuer may be the controlling tenant.

[0110] Tenant identifier 978 may indicate the tenant identifier of the user (eg, the user associated with the application requesting the resource).

[0111] Membership can be encoded in the access token 972 based on the user's roles and permissions and if they meet policy criteria. During access token generation, a user identifier that meets the policy criteria automatically gets the associated role identifier as membership according to the policy set at the time of access grant. 980 can contain a list of members the user has access to. Membership can be indicated by role identifier 982 and / or workgroup identifier 984. A permission index (or "for all") can be used to indicate the role identifier. * "). For example, a user can have membership in both a role and a workgroup.

[0112] The access control list 990 can include a tenant identifier and a user identifier along with the granted permissions for the associated resource. The access control list in the token 972 can be included for efficiency purposes (e.g., so that a separate access control list does not have to be checked), or it can act as a double check on an access control list already in place (e.g., an access control list already shipped to the genomic data service as part of the grant token).

[0113] The grant type 992 may indicate the grant type or authentication flow for how the user obtained the token 972 .

[0114] The audience 994 can determine which cloud provider services a user is trying to access.

[0115] The service 996 may indicate the application or service that the user used to generate the token 972 .

[0116] The scope 998 may include a list of granted permissions (e.g., an identifier indicating the type of access allowed by specifying the service type, resource type, and permission type (e.g., "GDS.FILES.UPDATE", "GSS.LIBRARYPOOLS.READ", etc.)).

[0117] In practice, the signed access token 972 may be implemented as a JSON Web Token or other format that supports storage of relevant fields, may be signed with the signer's private key, and allows authentication via the signer's public key.

[0118] Example 24 - Exemplary Access Token Generation System FIG. 10 is a block diagram of an example system 1000 that generates an access token 1072 based on attributes of an access request 1020 and conditions of a policy document 1060 .

[0119] In this example, the access request 1020 may include a set of one or more attribute name 1040A-N and attribute value 1042A-N pairs. For example, the attributes may indicate the tenant of the user identifier requesting access, the workgroup, the application associated with the request, etc.

[0120] The policy document 1060 may include a role identifier 1074, which may not be explicitly stored in the document 1060, but may instead be linked (e.g., in a mapping between the role identifier and the policy document). The policy document 1060 may include multiple conditions 1064A-N, each including a pair of a filter attribute 1064A and a filter parameter 1066A. The filter attribute 1064A may specify an attribute by name or identifier, and the filter parameter 1066A may specify a parameter that indicates which attribute values ​​are eligible for assignment of the role identifier 1074. In practice, the parameter 1066A may take the form of a single value, a list, a wildcard, etc.

[0121] The access token generator 1050 can match policy parameters with attributes (e.g., of a received request). External conditions can also be included (e.g., conditions that are not part of the access request 1020).

[0122] If the access request 1020 qualifies for role assignment as indicated by the conditions 1064A-N, the role identifier 1074 may be included in the access token 1072 along with the tenant identifier (eg, the requesting user).

[0123] The token 1072 may be signed using a private key (e.g., of the controlling tenant or cloud service provider). Such signing may be achieved using conventional or other public-private key encryption methods and may be a function separate from the token generator 1050. If signed, the token 1072 may be authenticated using the signer's public key.

[0124] Example 25 - Exemplary Access Token Generation Method FIG. 11 is a flowchart of an example method 1100 for generating an access token based on attributes of an access request and conditions of a policy document, which may be implemented, for example, by the system 1000 of FIG. 10 (e.g., the access token generator 1050 described herein or other access token generation system).

[0125] At 1110, a request to access the shared genomic digital data is received, the request including one or more attributes. Such attributes may take the form of attribute name and attribute value pairs, although the attribute names may be implied (e.g., based on their position in the request, etc.).

[0126] At 1120, a policy document for the shared genomic digital data is accessed, the policy having one or more conditions.

[0127] At 1140, an access token is generated based on one or more attributes of the request and one or more conditions of the policy. For example, a role identifier can be included if the attributes indicate that it satisfies the conditions of the request policy. External attributes can also be included to influence the generation of the token (e.g., whether the requester's tenant has an increased subscription level).

[0128] As described herein, the resulting token may be signed.

[0129] Example 26 - Exemplary Genomic Digital Data Publication System 12 is a block diagram of a system 1200 that exposes underlying data (e.g., genomic digital data) 1297 for policy-based sharing. In practice, system 1200 may be incorporated into any of the policy-based sharing examples herein and invoked to configure (e.g., set up) the sharing.

[0130] In this example, the controlling tenant 1210 has access to a workgroup administration console 1220 to provide access to the shared underlying data 1297 provided by the genomic data service 1290 .

[0131] An access control list 1292 can be created to enforce restrictions on data 1297. The access control list 1292 can include entries indicating a controlling tenant identifier 1234, a role identifier 1236 created for a given policy-based sharing scenario, and granted permissions 1278 (e.g., indicating resource type, access type, etc.).

[0132] Tenant 1210 generates policy document 1260, role identifier 1236, and underlying data 1297 contained in policy store 1255 and linked (e.g., mapped) to tenant identifier 1210's tenant identifier.

[0133] In this example, the policy document 1260 specifies the version and all tenants (e.g., "TID: * "). A signed grant token 1230 is created that includes one or more access control lists dictated by the publishing scenario. In this way, the access control lists can be shipped to a genome data service 1290, which stores the access control lists for future reference (e.g., grants permissions based on requests associated with role id 1236). In this example, the tenant identifier 1234 of the controlling tenant and the role identifier 1236 created for the policy-based sharing scenario are included.

[0134] The illustrated scenario may also be referred to as "publishing" data (e.g., data 1297) because tenant 1210 has made the data available to those who are eligible (e.g., by those requests that meet the conditions in policy 1260).

[0135] Example 27 - Exemplary Genomic Digital Data Publishing Method 13 is a flowchart of an example method 1300 of publishing genomic content for policy-based sharing, which may be implemented, for example, by the system 1200 of FIG. 12 (e.g., the workgroup steering counsel 1220 or other portion of the platform that supports policy-based sharing as described herein). As described herein, the method 1300 may be driven by a tenant (e.g., a workgroup operator) granting access.

[0136] A custom role identifier (e.g., with a policy document linked to the role identifier) ​​is created at 1320. Such a role identifier may be unique within the platform and is assigned in response to a publication request.

[0137] A signed grant token is created with the list of access control lists at 1340. The grant token can be associated (e.g., linked) to a resource identifier that identifies the genome content, as described herein.

[0138] At 1360, the content is published to the genomic data service using the grant token. For example, the data can be uploaded to the genomic data service if it does not already exist. The grant token can be validated to control access to protected resources.

[0139] Example 28 - Exemplary Genomic Digital Data Access Method 14 is a flowchart of an exemplary method 1400 for accessing published shared genomic content, which may be implemented, for example, by any of the systems supporting policy-based sharing described herein. Such methods are typically driven by an enterprise user identifier accessing the resource.

[0140] At 1420, an access request is received (eg, by the platform from an access user identifier for a given access tenant).

[0141] At 1440, a signed access token is generated as described herein (eg, based on a policy).

[0142] At 1460, a genomic digital data resource is accessed with the signed access token. For example, a request can be sent to a genomic data service, which responds with data.

[0143] Example 29 - Exemplary External Service Provider Registration Method 15 is a flowchart of an example method 1500 for registering an external service provider, which may be implemented, for example, by any of the systems supporting policy-based sharing described herein. Such a method 1500 is typically driven by an administrative user identifier or process. As described herein, various external service provider scenarios may be supported.

[0144] At 1520, a registration of an external service provider with the platform is received (e.g., by the platform). Such registration may include a scope and grant of access and may be performed by an administrative user.

[0145] At 1540, a registration of the external service provider as a proxy tenant is received. The tenant identifier can be used for the proxy tenant even if the external service provider may not act in the capacity of a tenant or participate as a full tenant of the platform.

[0146] At 1560, policy-based access control is created (e.g., enabling inter-tenant sharing via roles created under the external service provider's proxy tenant). Policies can be associated with roles. In effect, the data is considered owned by the external service provider (via the proxy tenant identifier), and the data is shared with the access tenant via policy-based sharing as described herein.

[0147] A more detailed use case is provided in Figure 21 below.

[0148] Example 30 - Exemplary External Service Provider Integration Method 16 is a flowchart of an example method 1600 for integrating external service providers into a policy-based sharing platform, which may be implemented, for example, by any of the systems supporting policy-based sharing described herein. Such a method 1600 is typically driven by an access user identifier (e.g., from another tenant) or process.

[0149] At 1620, a workflow is initiated to communicate with an external service provider. Such a workflow may be kicked off to perform a task associated with the external service provider. For example, a tenant may wish to send a physical biosample and receive digital genomic data resulting from an analysis of the biosample, or the tenant may wish to have generated genomic digital data, such as sequencing results, and have the results interpreted by the external service provider.

[0150] A grant token is generated for the external service provider (e.g., for a particular sharing scenario) at 1640. In practice, the workflow execution service that executes the workflow may request the generation of a grant token.

[0151] At 1660, the external service provider is called with the grant token, which is verified (eg, using the administration public key).

[0152] At 1660, results (e.g., biosample analysis, data analysis, etc.) are received from the external service provider and accepted into the genomic data service (e.g., may be accessed by a user of the tenant that initiated the workflow that includes the external service provider). For example, the external service provider uploads the results to the genomic data service using a signed access token provided by or on behalf of the requesting tenant.

[0153] A more detailed use case and sample policy is provided in Figure 22 below.

[0154] Example 31 - Exemplary External Service Provider In any of the examples herein, the external service provider may be a service provider that provides genomic data services to tenants of the system. Thus, the tenant from which the policy-based access control definition is received may be a proxy tenant representing the external service provider for which policy-based sharing is implemented. Because the external service provider operates outside the system (e.g., not as a tenant of the system), a proxy tenant identifier may be configured for use by the external service provider, and the external service provider may register with the platform associated with the proxy tenant identifier. As described herein, the external service provider may utilize the policy-based inter-tenant sharing techniques described herein.

[0155] Such service providers can perform useful services such as analyzing physical biosamples, uploading the analysis results (e.g., digital genomic data), and analyzing the genomic data (e.g., using mathematical processes, machine learning, etc.).

[0156] From the user's perspective, external service providers may appear as third-party applications, and their services are available to the user. In this way, a rich ecosystem of research can be provided in which third-party applications can be interfaced to the platform, so that the platform is not limited only to applications provided by the platform orchestrator or other tenants.

[0157] Example 32 - Exemplary Token Verification 17 is a block diagram of an example system 1700 for verifying (e.g., authenticating) a signed access token that may be implemented to achieve token authentication in any of the embodiments herein. In this example, a signed access token 1772 (having a role identifier 1774 and a tenant identifier 1776) is signed with the private key of a control tenant 1710. In practice, the private key of the control tenant may be managed by a tenant or operator (e.g., a platform orchestrator) of a cloud service provider.

[0158] Authenticator 1780 can accept the public keys of control tenant 1710 and signed token 1772 and output authentication result 1790 (e.g., whether token 1772 was indeed signed by the private key of control tenant 1710). Authenticator 1780 can take the form of conventional public-private key encryption algorithms (e.g., including hashing, etc.) to achieve validation of token 1772.

[0159] After verification, further processing can be performed to determine whether permissions are available for a given resource (e.g., based on membership in a role identifier, workgroup identifier, etc.) In response to determining that a member satisfies a specified condition (e.g., satisfies an access control list), the associated permissions (e.g., in the access control list) are granted to the requester associated with the token.

[0160] Although a signed access token 1772 is shown, the system 1700 may also be used for signed grant tokens as described herein.

[0161] Example 33 - Exemplary Genomic Data Implementation In any of the examples herein, the genomic data can be in the form of a genome file type. Such file types can be associated with different genomic data, distinguishing between data obtained during genome sequencing (e.g., raw data from a sequencing instrument, assembled genome, etc.), data for assistance during assembly (e.g., a reference genome), and data representing the results of comparative genomic analysis. Comparative genomic analysis can include comparisons between genomes (e.g., file types representing single nucleotide polymorphisms, insertions, deletions, structural variants, and copy number variations within a genome compared to a reference genome).

[0162] An example of such a file type is the VCF (SNP) file type. VCF stands for "Variant Call Format." It is a standardized text file format for representing variant calls for SNPs, INDELs, SVs, and CNVs. SNPs (Single Nucleotide Polymorphisms) are the most common type of genetic variation in people's genomes. Each SNP represents a difference in a single DNA building block (e.g., a nucleotide). In practice, this is the widely used VCF.

[0163] Another example of a file type is the VCF (INDEL) file type. INDEL is a molecular biology term for an insertion or deletion in DNA. The number of INDELs in the human genome is second only to the number of SNPs. INDELs can play an important role in genetics.

[0164] Another example is the VCF(SV) file type. SV (or Structural Variant) is a large DNA sequence that is inserted, inverted, deleted, or duplicated within a genome.

[0165] Another example is the VCF (CNV) file type. CNV (or Copy Number Variation) is when the number of copies of a particular gene changes from one individual to the next. Some cancers are thought to be associated with elevated copy numbers of certain genes.

[0166] Another example is the BAM file type. A Binary Alignment Map (BAM) can be the comprehensive raw data of a genome sequence. It can contain a losslessly compressed binary representation of the sequencing alignment map. BAM files tend to be around 90-100 gigabytes in size. They can be generated by aligning FASQ files to a reference genome. A BAM file (.bam) is the binary version of a SAM file. A SAM file (.sam) is a tab-delimited text file containing sequence alignment data.

[0167] Another example is the FASTQ file type, which contains billions of entries and is approximately 90-100 gigabytes in size, making it too large to open in a regular text editor. FASTQ files may be the final raw data.

[0168] Another example is a quality control metric file type (e.g., report). Before running any alignment or assembly, it is possible to check the quality of the underlying data. Quality can be checked from within the sequencing program. Quality control analysis can test a number of different metrics and produce a concatenated report. The report can include a simple classification (e.g., red, yellow, green) to indicate whether the result is poor, intermediate, or good.

[0169] Example 34 - Exemplary Special Permissions In any of the examples herein, special permissions in a genomic context can be implemented. For example, permission granularity can be extended to file types in policy statements. Thus, a policy can specify that different tenants, workgroups, users, or application roles can have different permissions for different genomic file types or different genomic file type categories (e.g., raw sequencing data, assembled genomes, reference genomes, comparative genomic analysis, etc.).

[0170] Special so-called "background" permissions can allow use of resources (e.g., file types) by applications or other infrastructure without granting read access (e.g., because they cannot be read directly). For example, granting background permissions to a reference genome allows the reference genome to be used to assemble raw data, determine single nucleotide polymorphisms, or perform other comparative genomics analyses without granting read access to the reference genome itself.

[0171] Additionally, special permissions can be specified for executable workflows. For example, a "high-level run-only" permission can allow high-level visibility of a workflow (e.g., steps, step progression, error messages, etc.) without revealing workflow details (e.g., the underlying interpreted code) or allowing workflow modification. Thus, workflows can be shared between tenants without revealing every small technical detail within them.

[0172] Example 35 - Exemplary Application Implementation In any of the examples herein, the application may be dedicated to facilitating genomics use cases, such as clinical genomics. For example, a cloud-based in vitro diagnostic solution for oncology may incorporate applications that support sample intake, wet-lab protocols (e.g., extraction, library preparation, indexing / pooling), sequencing, multiplexing, sequencing quality control, and then secondary analysis, ultimately resulting in a report. Secondary analysis may include comparative genomic analysis, such as detecting single-base variants.

[0173] Such applications can harmonize various services and unify the management of genomic data to enable efficient and accurate collection and analysis of genomic data. For example, a genomics laboratory service, a workflow service, an event notification service, a task service, and a genomics data store can work together under the orchestration of applications operating in the shared environment described herein.

[0174] Thus, different actors acting as tenants or external service providers can collaborate to share information using the policy-based genomic data sharing techniques described herein.

[0175] Example 36 - Exemplary Smart Contract Integration 18 is a block diagram illustrating the integration of smart contracts 1865 into a policy-based sharing platform that can be implemented to extend policy document functionality in any of the embodiments herein. A policy can point to a contract, such that anyone who fulfills the contract has access to the data via the policy. Conversely, a violation or failure to fulfill the contract means that a party does not have access to the data via the policy. A party can be designated as a tenant, workgroup, etc.

[0176] In this example, platform authentication service token generator 1850 consults policy 1860 to determine how to generate a signed access token 1872 with a role identifier 1874 and a tenant identifier 1876. As described herein, generation 1850 may also examine one or more attributes of the received request (e.g., tenant identifier, application identifier, etc.).

[0177] As shown, policy document 1860 can include or reference smart contract 1865. Smart contract 1865 can itself reference blockchain service 1897, which memorizes agreements of one or more tenants 1810A-N. Such agreements can be between tenants, between tenants and cloud service providers, between tenants and third parties, or some combination thereof. Such blockchain services can use blockchain technology, such as a consensus-based, immutable record of agreements (e.g., agreement existence, agreement level, service level, etc.), and can be built on blockchain infrastructure from any of a variety of providers or technologies (e.g., Ethereum-based functionality, etc.).

[0178] Trust relationships, such as between the platform and services, between tenants, etc., can be established through trust documents that can facilitate automated evolution of policy documents 1860 based on agreements expressed by services 1897.

[0179] In this way, any tenant that satisfies the terms of the contract has access to the data specified in the associated policy. Automated contract administration is then provided to facilitate immediate access to the data specified by the contract once the contract term (e.g., payment, subscription, or other term) has been satisfied.

[0180] Grant tokens can be generated based on the completion of a contract, and access tokens can be generated when access is requested in light of an associated policy.

[0181] As a further feature, access to data can be logged for subsequent auditing capabilities. Such logs can indicate the date and time of access, the identifier of the requesting party, the identifier of the granting party, and the policy that allowed the access, and can themselves be annotated for compliance or legal reasons (e.g., "Agreement between Party X and Party Y dated December 15, 2017"), etc.

[0182] Example 37 - Exemplary Trust Document In any of the examples herein, the policy-based sharing platform can document trust relationships between tenants as trust documents. For example, the trust document can store a consent agreement for one tenant that reflects that trust has been established with another tenant (e.g., by storing the originating tenant, the destination tenant, the consent agreement date, and consent metadata).

[0183] Such trust documents can be enforced as a prerequisite for sharing data with tenants, e.g., in such a scenario, policies are only valid if supported by a trust document.

[0184] Example 38 - Exemplary Smart Contract Method FIG. 19 is a flowchart of an example method 1900 of implementing smart contracts within a policy-based sharing platform that may be implemented to extend policy document functionality in any of the examples herein.

[0185] At 1920, the tenancy agreement is reflected in a blockchain service (e.g., provided pursuant to Ethereum or other blockchain infrastructure).

[0186] At 1940, a request to access data controlled by one or more agreements is received. For example, a policy that references an agreement can be substituted for the data.

[0187] At 1960, a request to access the data is granted based on the policy with reference to the blockchain service.

[0188] At a later point in time, the blockchain service can be updated to reflect changes in the tenant agreement, such that requests may no longer be granted, may be newly granted, etc. In other words, changes to the agreement may result in changes in whether access is granted based on policies that reference the agreement.

[0189] Example 39 - Exemplary Public Use Case Figure 20 is a flow diagram of an example public use case 2000 that can be implemented in any of the examples herein. While this example shows "public_access," such use can cover both public and inter-tenant sharing, and can parallel the description of the methods in Figures 13 and 14.

[0190] The initial stage of publishing resources with access control lists can be driven by an administrative user identifier or process. The control tenant 2010 can interact with the identity and access management console 2050, the platform 2052, and the genomic data service 2054 to accomplish the publication of public content 2060.

[0191] Subsequent stages of searching for resources can be driven by a user identifier from another tenant 2020. The access token can include membership (e.g., a role identifier indicating the membership). Receiving access can take the form of receiving a list of resources from which a selection can be made for actual access.

[0192] Example 40 - Exemplary Grant Token In any of the embodiments herein, a grant token can associate a role identifier with a resource (e.g., a resource identifier), which serves as a policy identity that includes policies or rules for data access to the associated resource.

[0193] For example, the resource identifier may be included in the grant token associated with a table that maps the grant token to the resource identifier or is otherwise linked to the grant token.

[0194] Example 41 - Exemplary External Service Provider Use Case Figures 21 and 22 are flow diagrams of example external service provider use case methods 2100, 2200 that can be implemented in any of the examples herein. Such use cases can be paralleled with the method descriptions of Figures 15 and 16. Initially, the external service provider is registered (e.g., as a proxy tenant) and the external service provider is integrated into the system (e.g., policy-based sharing is used to enable the external service provider's access to the system, whether for read access, write access, or both).

[0195] In an external service provider scenario, a single policy can achieve sharing as described herein. Such a policy can be defined during the external service provider's registration with the platform. Such a policy can include information such as with which tenants the external service provider can share data. For example, in a scenario in which an external service provider uploads data, the policy can both allow the external service provider to upload data and allow the access tenant to access the data uploaded by the external service provider.

[0196] Data generated by external service providers can go to a dedicated tenant (e.g., "tenant_ESP"), and the platform operator can define the dedicated tenant's policy for sharing data with tenants who want to use external service provider sharing. When an access tenant generates an access token, the token is encoded with memberships based on their access rights, and the role identifier specified in the policy is dynamically entered as one of the memberships if the tenant meets the policy criteria.

[0197] Sharing scenarios can be used to support workflows involving external service providers. Typical workflows that can be initiated include an external service provider uploading genomic results from an analysis (e.g., of a physical biosample), an external service provider downloading genomic data and uploading the results of the analysis (e.g., download genomic data, externally analyze genomic data, upload analysis results), etc. For example, a tenant may want to use an external service provider to generate a variant report based on the output from a sequencing process (e.g., a sample file containing base calls and quality information for filtered reads, such as a FASTQ file). The tenant can run a workflow with the external service provider to upload the sample file to the external service provider. After uploading, the external service provider can run their processes and generate a variant file that the tenant then accesses.

[0198] The platform does not need to be aware of the internal workings of the external service provider. An input file can be submitted, the external service provider will generate an output file, and the output file will be shared with the original policy (e.g., rid:<>) under which the file was originally uploaded. In this example, the external service provider can both read and write to the resource (e.g., file storage).

[0199] The initial stage of registering an external service provider with the platform is shown in FIG. 21 and can be driven by a workgroup operator identifier or process. An operator user identifier 2110 can interact with the platform 2152 and the external service provider 2156. Workflow execution services 2153 and genomic data services 2154 can come into play at a later time (e.g., integration, access, or both). The operator user identifier 2110 can be for the operator of the platform, although if necessary, a tenant operator identifier can be given such authority (e.g., to register and integrate external service providers).

[0200] Subsequently, after registration, the integration of the external service provider 2156 can be provided as part of a workflow that includes the services of the external service provider 2156. In effect, the data is owned by the proxy tenant of the external service provider 2156 and can be shared with other tenants.

[0201] In this example, the platform operator user identifier 2110 registers the external service provider 2156 (eg, the scope and grant of the external service provider 2156) with the platform 2152.

[0202] The operator user identifier 2110 then registers the external service provider 2156 with the dedicated tenant (e.g., a proxy tenant such as "Tenant_ESP" for the external service provider 2156). In a data write scenario, the external service provider processes data that can be streamed to the dedicated tenant even if the external service provider is not a full tenant of the system.

[0203] The platform operator user identifier 2110 can then create policy-based access controls that enable inter-tenant data sharing. For example, a proxy tenant can share data with one or more designated tenants.

[0204] An example policy that allows an external service provider ("Tenant_ESP") to share its data with Tenant1 is as follows: rid:<tenantESP_tenant1_GUID> (Example: Data owned by Tenant_ESP but shared with tenant1 with restricted permissions: GDS.FILES.READ) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ” “Identity”:{tid:tenant1} ] }

[0205] The policy is associated with the role identifier "tenantESP_tenant1_GUID".

[0206] An example policy that allows an external service provider (tenant_ESP) to share data with Tenant1_Clinical_Workgroup is as follows: rid:<tenantESP_tenant1_GUID> (Example: Data owned by Tenant_ESP but shared with tenant1 with restricted permissions: GDS.FILES.READ) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ” “Identity”:{wid:tenant1_clinical_workgroup1} ] }

[0207] The policy is associated with the role identifier "tenantESP_tenant1_GUID".

[0208] After registration is complete, integration can be implemented as shown in FIG. 22 , involving the same party and a user identifier 2220 from an access tenant (e.g., Tenant1) that wishes to utilize services provided by an external service provider 2256. In example method 2200, the user identifier 2220 from the access tenant initiates a workflow execution task (e.g., communicating with external service provider 2256) using workflow execution service 2253. For example, the task can be titled "Perform Interpretation." In this example, external service provider 2256 provides results to the access tenant, and providing the results includes uploading the results to genomic data service 2254, where the access tenant can access them.

[0209] The workflow execution service 2253 sends a request to generate a grant token for the external service provider 2256 using the proxy tenant identifier (e.g., "Tenant_ESP"). The token includes an access control list for each policy. The platform 2252 responds with a grant token, which can take the following general form: issuer=platform audience=esp access control list=[rid:<>] tenant id=tenant1 membership={}

[0210] The workflow can then call the external service provider 2256 with the grant token, which can be verified by the external service provider 2256 (the token's intended audience) using the public key of the platform orchestrator or other entity authorized to perform the registration.

[0211] The external service provider 2256 can then send a request to the platform 2252 to generate an access token for the genomic data service 2254 and copy the access control list from the access control list request in the grant token. The platform 2252 responds with an access token, which can take the following general form: issuer=platform audience=gds access control list=[rid:<>] membership={”rid”:<>} tenant id=tenant_ESP

[0212] The external service provider 2256 can then use the access token to upload the results to the genome data service 2254, which can be validated by the genome data service 2254 (the token's intended audience).

[0213] The uploaded data is then available to other tenants if the user id has the appropriate membership enabled via policy by the operator user of the other tenant (e.g., rid:<tenantESP_tenant1_GUID> ), user id2220 of the access tenant (tenant1), or any other user of the access tenant.

[0214] An example policy that allows all users in the access tenant (tenant1) to view processed data from external service providers is as follows: rid:<tenant1_ESP_data_read_access_GUID> { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ” “Identity”:{uid: *} ] }

[0215] The policy is associated with the role identifier "tenant1_ESP_data_read_access_GUID".

[0216] Thus, access to data uploaded by external service providers is achieved by using the inter-tenant policy-based sharing techniques described herein, where the external service provider is assigned a proxy tenant identifier.

[0217] Thus, the creator of a policy with permission rights to resources can allow access to any internal or external tenant for a list of identities and resources.

[0218] Example 42 - Exemplary Policy Version Field In any of the examples herein, the version field of the policy can be used to facilitate audit tracking and to roll back the policy to a previous version.

[0219] Example 43 - Exemplary Policy In any of the examples herein, policies can be used to control sharing. Different policies can be used to achieve different sharing objectives. In the following examples, the platform orchestrator "Illumina" maintains a platform that supports a variety of policy-based sharing scenarios.

[0220] A policy can be associated with a role identifier that ultimately controls access to a shared resource. A policy can include one or more identities (e.g., user identifier, application identifier, workgroup identifier, group identifier), scopes (e.g., permissions), and role identifiers (e.g., one policy can nest another). A policy (rid) can be associated with a resource or an identity to enable access to the resource.

[0221] For example, the following policy can achieve application-enabled content, allowing users using a particular application ("Olympia") to access the content: rid:<illumina_app_enabled_data> (Owned by Illumina) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:”GDS.FILES.READ,GDS.FOLDERS.READ,GDS.FOLDERS.WRITE” “Identity”:{tid: *} "Condition":{ “filter”:{“appid”:“olympia”}, “filetypes”:[“sam”,“vcf”,“bam”] } ] }

[0222] A policy achieves application-enabled content by including a filter that specifies the application identifier for the application in question. Another filter restricts access to certain file types specified in a file type filter (e.g., sam, vcf, bam). As shown, the policy is associated with the role identifier "illumina_app_enabled_data."

[0223] In another example, a policy may allow public content to be shared with anonymous users using a particular application. rid:<illumina_public_data> (Owned by Illumina) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ” “Identity”:{tid: *} "Condition":{ “filter”:{“appid”:“olympia”} } ] }

[0224] The policy achieves read-only sharing with any user by specifying a read-only scope and including a wildcard in the tenant identifier. In this example, access is restricted to users using the application ("olympia") specified in the policy's application identifier filter. However, removing the application filter in the policy allows read-only access by any user. As shown, the policy is associated with the role identifier "illumina_public_data."

[0225] In another example, private content is shared with labs (workgroups) lab001 and lab002. rid:<illumina_private_shared_data> (Owned by Illumina) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ” “Identity”:{wid:lab001,wid:lab002} ] }

[0226] The policy specifies a read-only scope and includes an explicit list of one or more workgroups to achieve read-only sharing with any user in the two workgroups. As shown, the policy is associated with the role identifier "illumina_private_shared_data."

[0227] In another example, Tenant User 1 shares data with Tenant 2 user with user identifier "2." rid:<tenant1_private_shared_data> (Owned by Tenant1 user-uid:1) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ” “Identity”:{uid:2} ] }

[0228] In this example, the policy specifies a read-only scope and achieves read-only sharing with a specific user identifier by specifying the user identifier in the identity field. As shown, the policy is associated with the role identifier "tenant1_private_shared_data."

[0229] In another example, a workgroup for tenant1 shares data with users for tenant2 who have limited permissions (i.e., only read files and write files). rid:<tenant1_workgroup1_private_shared_data> (Owned by the workgroup owner of Tenant1) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ,GDS.FILES.WRITE” “Identity”:{uid:2} ] }

[0230] In this example, the policy is associated with the role identifier "tenant1_workgroup1_private_shared_data".

[0231] In yet another example, a workgroup for tenant1 shares data with another workgroup for tenant2. rid:<tenant1_workgroup1_private_shared_data> (Owned by the workgroup owner of Tenant1) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ,GDS.FILES.WRITE” “Identity”:{uid:2,wid:lab002} ] }

[0232] In this example, the policy is associated with the role identifier "tenant1_workgroup1_private_shared_data," which is reused from the previous example. Thus, more than one policy can be associated with a role identifier, allowing for stacked policies that can be used to effectively extend access (e.g., policies can be reused across role identifiers to grant similar users access to different resources).

[0233] As shown, different policies can support different sharing scenarios.

[0234] Example 44 - Exemplary Security Context In any of the embodiments herein, a role identifier (eg, role ID, rid, etc.) may alternatively be implemented as a security context identifier (eg, context ID, cid, etc.).

[0235] Example 45 - Exemplary Coordinating Parties In any of the embodiments herein, parties may collaborate on the platform by sharing genomic digital data. As described herein, such parties may be workgroups, tenants, or both. Collaborating workgroups may be intra-tenant workgroups (e.g., one tenant) or inter-tenant workgroups (e.g., one or more workgroups of a tenant collaborate with one or more workgroups of another tenant). Parties may include patients, laboratories, clinical laboratories (e.g., Quest Diagnostics, LabCorp, etc.), contract laboratories, medical clinicians, hospitals, universities, experts, counselors (e.g., genetic counselors), companies, genomic service companies (e.g., 23AndMe, Ancestry, etc.), institutions (e.g., the U.S. Centers for Disease Control and Prevention, the U.S. Food and Drug Administration, the European Medicines Agency, the China Food and Drug Administration, the World Health Organization, etc.), etc.

[0236] Example 46 - Example Use Case The technology described herein can be used in any of a wide variety of scenarios implemented in genomic information processing environments and platforms. For example, the technology can support primary, secondary, and tertiary analysis workflows within or across collaborating parties. In addition to intra-analysis collaboration, cross-analysis collaboration can also be supported, whereby a feedback loop of tertiary analysis results can be provided back to the party performing the secondary analysis for recalculation of the secondary analysis based on the tertiary analysis results. The technology described herein can also be used to enforce research-use-only restrictions or to restrict use for diagnostic purposes beyond approved clinical uses. Furthermore, the technology can be implemented to ensure compliance with privacy and / or health data residency requirements (e.g., the U.S. Health Insurance Portability and Accountability Act, the European General Data Protection Regulation, the California Consumer Privacy Act, etc.).

[0237] Collaboration and sharing can be facilitated by policy-based access control of genomic digital data in any of the various workflows that support the above as described herein. For example, tenants can collaborate on workflows, and workflow results can be passed from one tenant to another.

[0238] Example 47 - Exemplary Use Cases: Primary, Secondary, and Tertiary Analysis Sequencing generates large amounts of genomic digital data, and the analytical process associated with such data can be complex. Various analytical tools can be used to reveal meaningful information in the data in a timely manner. The technology described herein can enable collaboration between analytical tools and associated workflows during use, and can provide the results of one workflow from one user to another. One way to describe the genomic digital data analysis process is to divide it into three main stages: primary, secondary, and tertiary data analysis. Some actions can be performed automatically by the sequencing device, while other actions occur after sequencing is complete.

[0239] Primary data analysis may include analysis performed during cycles of sequencing chemistry and imaging that provides base calls and associated quality scores representing the primary structure of nucleotide chains. In one example, the output of primary data analysis is a BCL base call file that indicates base calls for clusters of nucleotide chains. In practice, such analysis may be performed automatically on a sequencing system. The results of the primary analysis may take the form of genomic digital data embodied in a file and uploaded to the cloud for further processing during secondary analysis. Collaboration and sharing may be facilitated by policy-based access control of genomic digital data as described herein. For example, one tenant may perform the primary analysis and provide access to the results to one or more tenants for secondary analysis.

[0240] Secondary analysis can take the results of the primary analysis, which represent base calls of unaligned nucleotide fragments, and analyze and align the base calls of the nucleotide fragments of a sample to provide a determination of the complete sequence or sequence coverage (e.g., gene), from which genetic variants can be determined. For example, the output of the secondary analysis can be in the form of a FASTQ file containing sequence information and quality scores. Such analysis typically involves aligning and assembling nucleotide fragments. Given the complete sequence or sequence coverage, variants can be determined. Sequence alignment, variant calling, data visualization, RNA sequencing experiments, gene fusion detection, total RNA expression profiling, and determination of methylated bases can also be performed. Collaboration and sharing of genomic data during secondary analysis can be facilitated by policy-based access control of genomic digital data as described herein. For example, one tenant can perform the secondary analysis and provide access to the results to one or more tenants for tertiary analysis.

[0241] Tertiary data analysis can involve using any of a wide variety of biological data mining and interpretation tools on sequencing data to convert the data into knowledge. For example, variant interpretation and diagnosis can be performed on the results of secondary analysis. Collaboration and sharing of genomic data during tertiary analysis can be facilitated by policy-based access control of genomic digital data as described herein. For example, tertiary data analysis can include a recommendation regarding whether genomic data indicate that a patient will respond to a particular medical therapy (e.g., medication, radiation, etc.).

[0242] Example 48 - Exemplary Use Case: Intra-Analysis Collaboration In any of the embodiments herein, the policy-based access control techniques can be used for intra-analysis collaboration, where multiple parties (e.g., tenants, workgroups, or both) collaborate to perform intra-phase analysis.

[0243] Example 49 - Exemplary Use Case: Cross-Analysis Collaboration In any of the embodiments herein, the policy-based access control techniques can be used for intra-analysis collaboration, where one or more parties (e.g., tenants, workgroups, or both) perform an analysis, which is then provided to one or more other parties to perform subsequent analyses at different phases.

[0244] In such cases, a feedback loop of the tertiary analysis results may be provided back to the party that performed the secondary analysis for review against a re-run of the secondary analysis, and the secondary analysis results may then be updated so that the tertiary analysis can be reviewed or re-run (e.g., by the same or one or more other parties).

[0245] Example 50 - Exemplary Use Case: Government Agency Approval Equipment and Testing In any of the embodiments herein, policy-based access control techniques can be used to implement diagnostic processing across tenants for agency-approved diagnostic devices and / or tests, such as FDA-approved devices and / or tests, in scenarios where multiple tenants are involved and share data as part of the test.

[0246] Example 51 - Exemplary Use Case: Research Processing The access controls described herein can enforce research use-only processing. For example, research use-only processing can be performed by tenants or workgroups within tenants collaborating across institutional and geographic boundaries in genomic digital data sharing scenarios while preserving the security of the data. For example, access to individual patient identifiers can be restricted so that processing of the data cannot be correlated to a specific individual.

[0247] Example 52 - Illustrative Use Case: Privacy and Data Residency Additionally, access controls can be implemented to ensure compliance with privacy and / or health data residency (e.g., geographic location) requirements. For example, in a research scenario, individual health data that directly identifies information can be blocked or restricted, and aggregated health datasets with identity information can be published or pushed to third-party providers or other tenants for analysis.

[0248] In diagnostic scenarios, individual health data may be allowed to directly identify information.

[0249] For example, access tokens can be used to ensure that other parties (third-party analytics providers) no longer have access to shared data when the token expires or is revoked. Revocation can be performed due to the conclusion of a process or by patient command.

[0250] For example, an access token can be used to verify that data resides in a particular geographic location or region.

[0251] Example 53 - Exemplary Benefits Policy-based sharing techniques can provide many advantages. For example, the ease with which sharing can be achieved in a policy-based sharing environment can encourage inter-tenant sharing in general. Due to the late-binding nature of role identifiers, there is no need to store a comprehensive mapping of users or tenants to roles. Instead, roles can be bound at runtime. Thus, the overall storage requirements for security data are reduced.

[0252] Similarly, the flexibility of policy-based role assignment allows for the incorporation of new standards without the need to redesign the platform or complicate operations for tenants.

[0253] Runtime role binding also provides more accurate role assignment: for example, changes in tenant status or service levels can be reflected immediately rather than after a period of time when pre-mapped roles are reassigned.

[0254] Another advantage is that executable workflows can be shared along with the underlying data on which such workflows are executed. Thus, tenants can share underlying data, execute shared workflows on such underlying data, and receive analytical results. Workflows can even invoke external service providers, leading to comprehensive collaboration scenarios that would not be possible without such technology.

[0255] The trust relationship can be enforced via signed tokens, as described herein. Thus, the security of the underlying data can be ensured, and cross-tenant sharing can be enabled while preserving the security of the underlying data. Auditing of access can also be achieved, and the audit log can be used for testing, security, or compliance purposes.

[0256] Software testing can also be more easily accomplished by easily setting up test tenants and sharing data with the test tenants, providing proof of concept and quality assurance testing for sharing scenarios that can then be extended outside of the test scenarios to real tenants.

[0257] Example 54 - Temporary Cloud Provider Credentials via an Exemplary Secure Discovery Framework 23 is an example system 2300 that provides temporary cloud provider credentials via a secure discovery framework that may be implemented in any of the examples herein. In this example, a software-as-a-service (SaaS) platform at one or more data centers 2330 orchestrates access to genomic digital data resources via policy-based access control over a network 2305, as described herein. As shown, system 2300 supports multiple tenants 2310 that access genomic computing services (e.g., via applications 2350). In this example, tenants 2310 are identified by tenant identifiers and can include users identified by user identifiers 2320.

[0258] Although not shown, the system 2300 may include a policy store containing the policy-based access control definitions described herein.

[0259] Platform authentication service 2335 includes cloud provider discovery service 2340 that can access stored mappings between identities accessing the platform and cloud provider accounts at cloud providers 2390A-N. Authorization checker 2345 can enforce the mappings to provide secure access as described herein.

[0260] A credential management service can be used to derive limited, temporary derived credentials from the underlying credentials of a cloud provider account.

[0261] An operation service 2358 is provided that can manage the underlying credentials and apply policies to control access to the restricted, temporary, derived credentials. The operation service 2358 can also manage the identity-to-cloud provider account mappings that are provided to the cloud provider discovery service 2340 and the authorization checker 2345.

[0262] Discovery service 2340 can determine cloud provider details based on the received identity. Received requests for access to cloud providers 2390 can be processed by authorization checker 2345, which can access mappings configured via operation services 2358.

[0263] Although the example shows application 2350A accessing cloud providers 2390A-N on behalf of user identifier 2320, in practice other identities may access cloud providers 2390A-N as described herein.

[0264] Although not explicitly shown, the credential management service 2380 may interact with cloud providers 2390A-N to obtain credentials and provide credential management functionality.

[0265] In effect, a genomic digital data resource can be linked to a role identifier and stored with a given cloud provider account, and a limited, temporary derived credential can be used by an access identity to access the genomic digital data resource.

[0266] Although a single data center 2330 is shown, in practice the platform may be distributed among multiple data centers with computing systems. Additional components may be included to implement security, redundancy, load balancing, report design, etc.

[0267] Example 55 - Illustrative Cloud Provider Example Any of the embodiments herein may support a variety of cloud service providers (or simply "cloud providers"). In practice, a particular cloud provider account is associated with a provider type. The underlying credentials for a particular account may be stored and leveraged to generate limited, temporary derived credentials for use by the identity requesting access. Cloud resources, such as storage devices, may then be integrated into the platform as described herein.

[0268] Cloud providers offer customers accounts that allow them to access resources (e.g., data, services, etc.) provided through the hardware and software infrastructure maintained by the cloud provider. Different cloud providers may offer different arrangements with different technical advantages, configuration options, licensing arrangements, etc. In examples herein, the resources may include genomic digital data resources, such as the genomic digital data described herein.

[0269] The platform described herein can support multiple different cloud providers or provider types (e.g., Amazon Web Services, Microsoft Azure, Bitbucket, GitHub, GitLab, Google Cloud, etc.) per identity (e.g., per tenant). In this way, tenants can utilize their preferred cloud provider accounts while still utilizing genomic computing services provided by the platform.

[0270] Such an arrangement is sometimes referred to as "bring your own account" because the platform gives tenants the freedom to choose any supported external cloud provider. The described technology can support one or more external cloud providers, one or more internal cloud providers (e.g., offered by the same provider that offers the platform), or a mixture of external and internal cloud providers.

[0271] Example 56 - Exemplary Supported Identities In any of the examples herein, any identity can utilize the temporary cloud provider credentials described herein. The identity can be one of several different identity types supported by the software-as-a-service platform. For example, supported identity types can include user, tenant, workgroup, application, project, etc. An identity can have memberships that include other identities. For example, a user can be a member of a particular tenant. An identity can be associated with a geographic region. For example, if an application is hosted, it can be associated with a home geographic region.

[0272] A workgroup identity can span multiple tenants of a software-as-a-service platform to facilitate cross-tenant access to cloud provider accounts.

[0273] An identity is typically indicated by an identifier that is unique within a scope.

[0274] Collaboration between users in different tenants can be achieved by implementing workgroups as described herein. Such cross-tenant workgroups can share access to a single cloud provider account, as described herein.

[0275] Example 57 - Exemplary Underlying Credentials In any of the examples herein, a cloud provider account can be accessed through an underlying credential as described herein. The underlying credential is typically a root credential that allows for the creation of further credentials on demand. As described herein, a credential management service can implement the details of providing limited, temporary, derived credentials by leveraging persisted underlying credentials. The logistics and process vary for different cloud provider types, but can still be transparent to the identity accessing the account, as the details are handled by the credential management service.

[0276] In any of the embodiments herein, the credentials may take the form of a username, password, token, signed digital certificate, etc.

[0277] Example 58 - Exemplary Restricted Temporary Derived Credentials In any of the embodiments herein, limited, temporary derived credentials can be derived from underlying credentials to provide access to a cloud provider account. In effect, such derived credentials provide more limited access than the underlying (e.g., root) credentials. For example, they may provide access to a limited number of resources, limited permissions (e.g., read-only), etc., instead of all possible access rights to the account. Derived credentials can also be temporary (e.g., valid for 24 hours, etc.). Upon expiration, a renewed credential can be obtained.

[0278] Thus, the level of granularity supported by the technology described herein can vary both in terms of rights and in terms of identities. From a rights perspective, different restricted credentials can be provided to control access to resources (e.g., a read-only credential prevents writing by one identity, while a different read-write credential enables writing by another identity). From an identity perspective, different credentials can be provided even if they have the same restrictions. For example, two different derived credentials can be provided to two different identities even if both credentials provide the same level of rights (e.g., read-only). The advantage of such a scenario is that if one identity is compromised, one of the credentials can be revoked while maintaining the other. Also, the underlying credentials remain intact because they do not need to be provided to the access identity.

[0279] The set of rights provided in a derived credential for a particular identity can be controlled by the policy-based access control techniques described herein (e.g., based on identity, identity membership, etc.). Features such as region tags can be supported to restrict access to specific (geographical) regions.

[0280] Another use case is the Internet-of-things (IoT) scenario: different derived credentials can be provided to different IoT devices, thereby limiting the risk to a single device if it is compromised. In this way, access can be provided to various identities while maintaining the confidentiality of the underlying credentials.

[0281] Thus, rights such as read, write, execute, etc. can be controlled and managed as desired.

[0282] In practice, derived credentials can take the form of federated tokens that can be created and recognized by more than one authority (e.g., created by one authority in conjunction with authorization from another trusted authority).

[0283] Example 59 - Exemplary Credential Management Service In any of the examples herein, a credential management service can be used to manage the underlying credentials for a cloud provider account. Such a service can be implemented internally to the software-as-a-service platform (e.g., as a microservice) or externally (e.g., as a Vault service, Centrify service, etc.).

[0284] The credential management service stores the underlying credentials and can then generate restricted, temporary derived credentials as required by an authorization checker (e.g., according to a defined policy), as described herein.

[0285] Example 60 - Exemplary Method for Providing Temporary Cloud Provider Credentials FIG. 24 is a flowchart of an example overall method 2400 for providing temporary, restricted derived credentials.

[0286] At 2410, cloud provider accounts are managed, where managing includes storing underlying credentials for the cloud provider accounts 2420. Such underlying credentials can be used to create further (derived) credentials, as described herein.

[0287] Subsequently, at 2430, the cloud provider may be accessed via limited, temporary, derived credentials derived from the underlying credentials. For example, genomic digital data may be read from and stored in the cloud provider account. In some cases, the cloud provider account may be provided by the cloud provider to the tenant of which the user identity is a member, but may support other identities. In this manner, services may leverage the stored underlying credentials to integrate the cloud provider account into a platform that implements the described technology.

[0288] As a result, the platform can work seamlessly across cloud provider types, transparent to the user, while maintaining network security.

[0289] Example 61 - Method for Managing Cloud Provider Accounts of an Exemplary Platform 25 is a flowchart of an example method 2500 for managing cloud provider accounts to provide temporary, restricted derived credentials. In an embodiment, at 2520, an operational user identity accesses a credential manager to manage cloud provider accounts within the platform.

[0290] At 2540, the credential manager receives the underlying credentials for the cloud provider account. Other details of the cloud provider account can be received as described herein.

[0291] At 2550, the underlying credential is persisted in a credential management service. Persistence may include storing account details and storing mappings between accounts and identities, as described herein. Credential management policies may be stored and associated with the credential and used to implement such policies as rotation, lease periods, etc.

[0292] Example 62 - Exemplary Platform Cloud Provider Account Management Details 26 is a sequence diagram of an example implementation of a method 2600 for managing cloud provider accounts to provide temporary, limited, derived credentials. In this example, a tenant operator identity accesses an administration console (IAM) 2650 to configure and manage cloud provider credentials. At a basic level, credentials for a specific cloud provider account can be provided to the administration console 2650.

[0293] An administrator may originate from a level other than a tenant. For example, a workgroup administrator may have access to the administrator console 2650. Administrators may be identified by a group in the hierarchy (e.g., platform.tenant.credmgmt, platform.workgroup.credmgmt, etc.), and members of the group are authorized to manage the underlying credentials. As described herein, any number of cloud provider types may be supported, and details including type may be collected as part of management.

[0294] The administration console 2650 can make secure application programming interface (API) calls to the platform authentication service 2660 and store the underlying credentials with the credential management service 2670, subject to authorization checks 2665. The API call can include information indicating the cloud provider type (e.g., " / Credentials?type= <aws>"), which can be used later for cloud provider discovery.

[0295] The credentials can then be persisted to a credential management service 2670 along with credential management policies as described herein.

[0296] Example 63 - Exemplary Credential Management Policy In any of the embodiments herein, credential management policies may be stored with the underlying credential to configure how the credential is derived from the underlying credential. Such policies may include rotation (e.g., to reduce credential lifetime), lease periods (e.g., the time a temporary credential is valid for), etc.

[0297] For example, a derived credential can be set to automatically expire after a limited period of time (eg, after 24 hours).

[0298] Example 64 - Exemplary Method for Providing Restricted Temporary Derived Credentials 27 is a flowchart of an example method 2700 for providing restricted, temporary, derived credentials. Essentially, method 2700 leverages underlying credentials provided via the cloud provider account management described above to generate restricted, temporary, derived credentials for use by an identity accessing a cloud provider. Method 2700 can be implemented in a computing system supporting multiple tenants accessing genomic computing services in a software-as-a-service platform that orchestrates access to genomic digital data resources via policy-based access control.

[0299] Method 2700 may be performed in response to a specific access request or may be preset prior to access.

[0300] At some point, a request is received on behalf of an identity to grant access to resources in a cloud provider account. For example, an identity may seek access to resources at a cloud provider controlled by a cloud provider account mapped to the identity. In effect, the identity may initiate a task or application that involves access to cloud provider resources, and access may be sought on behalf of the identity, or access may be sought using the identity of the task or application.

[0301] In this example, at 2740, cloud provider details (e.g., account) are discovered based on the identity accessing the software-as-a-service platform. For example, the account identifier, cloud provider identifier, cloud provider type, cloud provider access information, etc., can be discovered via a microservice or secure API provided as part of the platform authentication service. As described herein, the software-as-a-service platform supports restricted, temporary, derived credentials for multiple cloud provider types. In a resource-based approach, the resource identifier (e.g., in coordination with the identity) can be used to determine which cloud service details to use.

[0302] A request for a restricted, temporary, derived credential may be received. As described herein, such a credential may be derived via underlying credentials of a cloud service account and may provide access to resources of the cloud service account. Such access may be restricted according to a role-based policy set during configuration. For example, the requesting identity may be associated with a role having limited permissions. A single cloud service account may be indicated based on the requesting identity (e.g., via a mapping from identity to cloud service account), although a resource-based approach may be used instead of or in addition to an identity-based approach. For example, a resource identifier may be included as part of the request, and a mapping of resource identifiers to cloud service accounts may be maintained. Thus, the discovery framework may determine which cloud service details should be used based on the resource identifier specified in the request.

[0303] At 2750, a request for restricted, temporary, derived credentials valid for the cloud provider account is sent (e.g., delegated) to a credential management service. The request may include an authorized access level (e.g., may be limited to rights granted by policies configured to enforce policy-based access control). Thus, policy-based access control may function as a flexible infrastructure that can control access within an environment that supports restricted, temporary, derived credentials as described herein while maintaining restrictions specified by policies that may be evaluated (e.g., at runtime).

[0304] In response, at 2760, a limited, temporary, derived credential valid for the cloud provider account is received from the credential management service based on the credential management policies set during configuration. Such a credential is valid for the cloud provider account and provides the configured permission level of access. Options such as rotation and lease period can be implemented by the configured credential management service. The credential can be limited to the rights allowed by policies configured to enforce policy-based access control. As described herein, the credential can be derived from an underlying credential previously received for the cloud provider account.

[0305] At 2770, a limited temporary derived credential valid for the cloud provider account is provided for use by the access identity.

[0306] At 2780, resources of the cloud provider account are accessed (e.g., by or in lieu of an access identity) via restricted, temporary, derived credentials. Such access may be restricted in accordance with policy-based access control as described herein. As described herein, credentials are typically provided temporarily and eventually expire. Renewed credentials can be obtained by reauthentication.

[0307] As described herein, the software-as-a-service platform can support multiple different cloud provider accounts per single tenant. Also, the platform can support multiple different cloud provider accounts per single tenant.

[0308] Example 65 - Exemplary Resource Granularity Implementation In any of the embodiments herein, a mapping between resource identifiers and cloud provider accounts can be maintained, which can be provided as part of a request for a restricted, temporary, derived credential. The resource identifier can then be mapped to a cloud provider account, and the restricted, temporary, derived credential for the cloud provider account can be provided in response to the request. In such an implementation, multiple different cloud provider accounts (and / or cloud provider types) can be supported per single tenant, depending on the resource.

[0309] Example 66 - Exemplary Restricted Temporary Derived Credential Provisioning Details 28 is a sequence diagram of an example implementation of a method 2800 for providing restricted, temporary, derived credentials. Method 2800 may be used by any of a variety of services to leverage the cloud credential technology described herein.

[0310] In this example, user identity 2810 is accessing a software-as-a-service platform that includes genomics analysis service 2850 and platform authentication service 2860. In this example, credential management service 2870 is external to the platform, but could alternatively be implemented within the platform.

[0311] As part of invoking the workflow execution service, the user identity 2810 can provide a signed access token 2815 (e.g., a JSON Web Token, etc.) that indicates membership in a workgroup, tenant, proxy tenant (e.g., an external third-party provider), project, etc. In this example, the analytics service (e.g., an Illumina analytics pipeline or other service) receives the token 2815 and proceeds to send a request for cloud service details to the discovery service 2865 of the platform authentication service 2860.

[0312] The discovery service 2865 can respond by providing cloud provider details 2855. Such details 2855 can include cloud provider type, account name, connection details, etc. The details 2855 can be based on the user identity's 2810 membership in tenants, workgroups, etc. For example, the discovery service 2865 can look up a mapping between tenants and cloud provider accounts to determine that a tenant uses a particular cloud provider account. However, as described herein, finer granularity can be provided (e.g., mapping from workgroups or even users to specific cloud provider accounts). Thus, per-tenant, per-workgroup, or per-user cloud provider account configuration can be supported. Different cloud provider accounting types can be supported, and cross-tenant scenarios can be supported (e.g., a workgroup has members from two different tenants, and the workgroup members access the same cloud provider account).

[0313] The service 2850 can then request the credentials from an authorization checker 2868 which verifies whether access is permitted and then delegates the request to a credential management service 2870 according to a role-based policy that indicates what level of access is permitted.

[0314] Credential management service 2870 then generates restricted, temporary, derived credentials 2875 as described herein. In practice, credential management service 2870 may work with cloud provider 2890 to generate restricted, temporary, derived credentials according to policies configured in credential management service 2870. Features such as rotation, leasing, etc. may be supported according to policies configured for credential management service 2870. Such credentials 2875 are then returned to platform authentication service 2860, which relays them to request service 2850.

[0315] The restricted, temporary, derived credentials 2875 allow the service 2850 to access data or other resources at the cloud provider 2890.

[0316] Although the examples show requests by user identity, in practice identities such as tenant, workgroup, project, or application may also be supported as described herein.

[0317] Example 67 - Exemplary Cloud Provider Mapping 29 is a block diagram of an example cloud provider mapping 2900. In this example, an identity is mapped to cloud providers 2990W-Z, which may be different cloud provider types. Although not shown, the mapping may provide further details, such as a specific account on the cloud provider.

[0318] As shown, a particular tenant identity 2910N may be mapped to a particular cloud provider 2990Z. An application identity 2920 may be mapped to a particular cloud provider 2990X.

[0319] The level of granularity can be at the workgroup level, such that different workgroups 2915J, 2915K of the same tenant 2910A are mapped to different cloud providers 2990W, 2990X. Additionally, cross-tenant situations can be supported, such that a cross-tenant workgroup identity 2915K is mapped to a cloud provider 2990W.

[0320] Other identities such as users, projects, or proxy tenants (e.g., external third-party tenants as described herein) may be mapped.

[0321] In practice, mapping 2900 can be implemented as a table that associates identifiers with cloud providers. Precedence can be observed so that a workgroup mapping overrides a default tenant mapping, etc.

[0322] Such mapping can be used during discovery to determine further details about the cloud provider and a given identity requesting access.

[0323] Example 68 - Exemplary User Interface 30 is a screenshot 3000 of an example user interface of a credential management tool that provides restricted, temporary, derived credentials. In this example, window 3050 allows an administrative user to provide cloud provider details for a particular tenant 3015A. As shown, cloud provider type, cloud provider name, access key, and secret key are supported. In practice, different arrangements may be provided and may vary by cloud provider type.

[0324] By convention, default information for a particular tenant is shown, however, different provider information can be provided for each workgroup (e.g., using the add workgroup button 3015B).

[0325] Example 69 - Exemplary Credential Object Figure 31 is a block diagram of an example credential object 3100 for an underlying credential. Such an object 3100 can be used to persist a credential in a platform authentication service. In this example, the credential object 3100 includes a cloud provider type having a value indicating the type of cloud provider for the credential, a credential name 3120 that allows instances of the credential object 3100 to have a unique (e.g., user-friendly) identifier, and an identity cluster 3130. The identity cluster 3130 can include both an identity type and an identity identifier. For example, the identity type can indicate a tenant, workgroup, project, application, user, etc., and the identity identifier can uniquely identify an identity.

[0326] The underlying credential storage 3150 can store underlying credentials such as access keys 3155, private keys 3157, etc. In practice, the storage 3150 can be implemented as a JSON object.

[0327] In a simple implementation, a credential object may be persisted per tenant to serve different cloud provider accounts for different tenants. However, finer granularity may be implemented that allows multiple objects 3100 per tenant (e.g., per workgroup, per user, etc.). As described herein, an application may have its own credential object 3100.

[0328] An exemplary credential object 3100 may take the following form: { "type”:”aws”, "name":"tenant01-aws-provider", "secret":{access_key":"accessKey01","secret_key";"secret"}, "identity":"tid:tenantID"} where: type=Credential type name=user-defined credential name for easy lookup Secret = A JSON object containing the actual credentials identity format=tid:tenantID,wid:workgroupId,uid:userId,aid:appID

[0329] [Table 1]

[0330] Example 70 - Exemplary Use Case: Genomic Analysis Pipeline In any of the examples herein, an exemplary use case is a genomic analysis pipeline application. In practice, a set of run parameters is submitted to the genomic analysis pipeline. The federation layer can use global events understood across platforms. A basic use case is to look at identity information associated with the run parameters. Thus, for example, the identity information of a workgroup associated with the run can be used to find a cloud provider account, generate a limited, temporary derived credential derived from the root credential of the account associated with the workgroup, and return the credential, such as for use by the pipeline orchestrator, to access the cloud provider account associated with the workgroup.

[0331] In practice, an application can launch a genome analysis pipeline by supplying parameters to the pipeline, and such parameters may themselves be input to the application. An exemplary parameter is a resource name. The application then requests credentials to access the resource specified in the input parameters. The resource may be a file located in some geographic location. When the application requests credentials for the resource, the discovery framework can provide restricted, temporary, derived credentials as described herein that can access the resource. Such credentials are provided only if authorization is indicated at the time of the request (e.g., by policy-based access control). Territorial restrictions may be imposed as described herein.

[0332] In any of the examples herein, the request for credentials may include a resource identifier, so that different resources can be mapped to different cloud service accounts and the request can be processed accordingly.

[0333] A basic implementation may map a workgroup to a single cloud service account and a single domain. Multiple domains can add legal and organizational compliance complexity.

[0334] Example 71 - Use Case: Hybrid Data Sources In any of the examples herein, genomic analysis can proceed using digital resources from both cloud provider accounts and local (e.g., on-premise) accounts.

[0335] Hybrid regions can also be supported so that genomic analysis can proceed using digital resources maintained in a different region than where the request originated, or from two different regions. Regional restrictions can be put in place to prevent access to unauthorized or unacceptable regions.

[0336] Example 72 - Exemplary Identity Hierarchy 32 is a block diagram of an example identity hierarchy 3200. At the top of the hierarchy is a platform global operations console identity 3210 that can be associated with a global operator 3215K. The global operations console identity 3210 can perform the widest variety of actions, including creating new identities.

[0337] Tenant identities 3220A-B are associated with tenant operators 3225A-B and can perform the widest variety of actions for a particular tenant, including creating new identities within the tenant (e.g., workgroups, users, etc.).

[0338] The next level is workgroup identities 3230A-N, which are associated with workgroup administrators 3235A-N who can perform actions for a particular workgroup.

[0339] Next are the user identities 3240A-N.

[0340] Separately, there may be a platform identity 3290, which may include customer-facing applications 3292A-B, internal applications 3297, etc. Such identity information may be used by applications when accessing cloud providers (e.g., regardless of the identity launching the application).

[0341] In practice, a particular user may be an administrator at a workgroup, tenant, or global level, and in fact, special protections may be put in place for the global administrator 3215K (or certain of them) so that they do not have direct access to the data of a particular tenant.

[0342] The following hierarchy can be implemented to control access to credential features:

[0343] [Table 2]

[0344] Example 73 - Integration with Exemplary Policies In any of the examples herein, the restricted temporary derived credential features described herein can be integrated with the policy-based access control features described herein. For example, policies can be created to control access to resource identifiers that identify resources stored at a cloud provider.

[0345] From the user's perspective, the fact that resources are stored on a cloud provider can be transparent. The same functionality and authentication processes can be supported. However, if special authentication is required by the cloud provider (e.g., two-factor authentication), it can be supported differently according to the practices of the particular cloud provider.

[0346] Using policy-based access control, policies can be attached to any identity described herein, including applications. Policy-based access control can serve as a base layer on which temporary credential technology operates. For example, a policy can be set for a workgroup specifying that the workgroup can only access data in a specific geographic region. If the workgroup is provided with applications, such applications are restricted by the policy, but the applications themselves may have additional restrictions based on the application's identity. Credential requests are limited to those restrictions specified by the policy. Thus, the policy-based access control infrastructure provides a flexible authorization layer based on customizable policies that can work in concert with the temporary credentials described herein. Any additional logic can be applied via policies (e.g., access only for a certain number of days, from a certain range of IP addresses, etc.).

[0347] Thus, the discovery framework can apply the authorization layer provided by policy-based access control before returning restricted temporary derived credentials.

[0348] However, any of the restricted temporary derived credential features described herein can be implemented independently (e.g., without implementing) the policy-based access control features described herein. Thus, policy-based access control is not an essential feature of the restricted temporary credential technology described herein. For example, an authorization layer that is not policy-driven can work in concert with the discovery framework. Instead of policies as described herein, a simple mapping of whether an identity has access to a realm can be applied.

[0349] Example 74 - Exemplary Benefits The limited ephemeral derived credential feature described herein can provide advantages from a technical standpoint in that it provides fine granularity for tenants who wish to use multiple different cloud provider accounts or cloud provider types, and allows different credentials (e.g., credential instances) to be provided to different identity information for the same cloud provider account without operator intervention, increasing overall network security.

[0350] Cross-tenant workgroups can be supported so that collaboration between groups in different tenants can be achieved regardless of the cloud providers involved.

[0351] From the user's perspective, the fact that data is stored in a cloud provider account can be transparent in that the same features and authentication processes can be supported across different cloud provider types.

[0352] Other benefits include improved management of credentials and integration into policy-based access control environments.

[0353] Example 75 - Exemplary Computing System 33 illustrates an example of a suitable computing system 3300 in which digital aspects of the described innovation can be implemented. The computing system 3300 is not intended to suggest any limitation as to the scope of use or functionality of the present disclosure, as the innovation can be implemented in a variety of computing systems.

[0354] Referring to FIG. 33, a computing system 3300 includes one or more processing units 3310, 3315 and memories 3320, 3325. In FIG. 33, this basic configuration 3330 is included within a dashed line. The one or more processing units execute computer-executable instructions, such as to implement features described in the embodiments herein. The one or more processing units 3310, 3315 may be any combination or configuration of a central processing unit (CPU), a graphics processing unit (GPU), a single-core processor, a multi-core processor, an application-specific integrated circuit (ASIC), a programmable circuit such as a field programmable gate array (FPGA), etc. One or more of the processing units 3310, 3315 may be implemented in software (e.g., ultimately executed on hardware) and / or firmware, in addition to hardware implementation.

[0355] In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. The tangible memory 3320, 3325 can be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two accessible by the processing units 3310, 3315. The memory 3320, 3325 stores software 3380 that implements one or more innovations described herein in the form of computer-executable instructions suitable for execution by the processing units 3310, 3315.

[0356] The functionality may also be implemented, at least in part, by one or more hardware logic components, such as a Field Programmable Gate Array (FPGA), an Application-Specific Standard Product (ASSP), a System-on-a-chip system (SOC), a Complex Programmable Logic Device (CPLD), etc.

[0357] Computing system 3300 may have additional features. For example, computing system 3300 includes storage 3340, one or more input devices 3350, one or more output devices 3360, and one or more communication connections 3370 including input devices, output devices, and communication connections for interacting with a user. An interconnection mechanism (not shown), such as a bus, controller, or network, interconnects the components of computing system 3300. Typically, operating system software (not shown) provides an operating environment for other software executing within computing system 3300 and coordinates the activities of the components of computing system 3300.

[0358] Tangible storage 3340 may be removable or non-removable and include magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other medium that can be used to store information in a non-transitory manner that can be accessed within computing system 3300. Storage 3340 stores instructions for software 3380 that implement one or more of the innovations described herein.

[0359] The input device(s) 3350 may be an input device such as a keyboard, a mouse, a pen or trackball, a voice input device, a scanning device, a touch device (e.g., a touchpad, a display, etc.), or another device that provides input to the computing system 3300. The output device(s) 3360 may be a display, a printer, speakers, a CD writer, or another device that provides output from the computing system 3300.

[0360] The communications connection(s) 3370 enable communication over a communications medium to another computing entity. The communications medium conveys information such as computer-executable instructions, audio or video input or output, or other data in a modulated data signal. A modulated data signal is 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, communications media may use electrical, optical, RF, or other carriers.

[0361] The innovations may be described in the context of computer-executable instructions, such as those contained in program modules, executed in a computing system on a target real or virtual processor (e.g., ultimately executed on one or more hardware processors). Generally, program modules or components include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. The computer-executable instructions of the program modules may be executed in a local or distributed computing system.

[0362] For purposes of presentation, the detailed description uses terms such as "determine" and "use" to describe computer operations in a computing system. These terms are high-level descriptions of computer-performed operations and should not be confused with human-performed acts. The actual computer operations corresponding to these terms will vary depending on the implementation.

[0363] Example 76 - Computer-readable medium Any of the computer-readable media herein may be non-transitory (e.g., volatile memory such as DRAM or SRAM, non-volatile memory such as magnetic storage, optical storage, etc.) and / or tangible. Any of the storage actions described herein can be implemented by storing on one or more computer-readable media (e.g., computer-readable storage media or other tangible media). Anything described as stored (e.g., data created and used during implementation) can be stored on one or more computer-readable media (e.g., computer-readable storage media or other tangible media). Computer-readable media may be limited to implementations that do not consist of signals.

[0364] Any of the methods described herein can be implemented by computer-executable instructions on one or more computer-readable media (e.g., computer-readable storage media or other tangible media) or one or more computer-readable storage devices (e.g., memory, magnetic storage, optical storage, etc.). Such instructions can cause a computing system to perform the method. The techniques described herein can be implemented in a variety of programming languages.

[0365] Example 77 - Exemplary Cloud Computing Environment 34 illustrates an exemplary cloud computing environment 3400 in which the described techniques may be implemented, including, for example, system 100 of FIG. 1 and other systems described herein. Cloud computing environment 3400 includes cloud computing service 3410. Cloud computing service 3410 may include various types of cloud computing resources, such as computer servers, data storage repositories, network resources, etc. Cloud computing service 3410 may be centrally located (e.g., provided by a data center of a business or organization) or distributed (e.g., provided by different data centers and / or various computing resources located in different locations, such as different cities or countries).

[0366] Cloud computing service 3410 is utilized by various types of computing devices (e.g., client computing devices), such as computing devices 3420, 3422, and 3424. For example, the computing devices (e.g., 3420, 3422, and 3424) may be computers (e.g., desktop or laptop computers), mobile devices (e.g., tablet computers or smartphones), or other types of computing devices. For example, the computing devices (e.g., 3420, 3422, and 3424) may utilize cloud computing service 3410 to perform computing operations (e.g., data processing, data storage, etc.).

[0367] In practice, cloud-based, on-premise-based, or hybrid scenarios can be supported.

[0368] Example 78 - Exemplary Implementation Although some acts of the disclosed methods are described in a particular sequential order for convenience of presentation, such methods of description encompass rearrangement unless a particular order is required by specific language set forth herein. For example, acts described as sequential may, in some cases, be rearranged or performed simultaneously.

[0369] Example 79 - Exemplary embodiment of policy-based access control Any of the following embodiments can be implemented.

[0370] Clause 1. A method comprising: A software-as-a-service platform for orchestrating access to genomic digital data resources via policy-based access control, comprising: a computing system having a plurality of tenants seeking access to genomic digital data resources provided by one or more genomic data services; receiving a policy-based access control definition of a first one of the tenants for a given genomic digital data resource; receiving a request for access to the given genomic digital data resource from a second one of the tenants seeking access to the given genomic digital data resource; and and granting access to the given genomic digital data resource based on the policy-based access control definition for a second one of the tenants. Article 2. access to a given genomic digital data resource is controlled by a role identifier linked to a policy-based access control definition; The method is 10. The method of claim 1, further comprising, in response to the access request, providing a role identifier specified in the policy-based access control definition for the access request. Article 3. 3. The method of claim 2, wherein assigning a role identifier includes late binding the role identifier to a user identifier or tenant identifier of the access request. Article 4. generating a signed access token containing the role identifier in response to the access request; 4. The method of any one of clauses 2 or 3, wherein access is granted based on the presence of a role identifier in the signed access token. Article 5. The method of clause 4, wherein access is further granted based on verification of the signed access token. Article 6. publishing a signed grant token that includes the role identifier and the tenant identifier of the role operator of the role identifier; 6. The method of any one of clauses 4 or 5, wherein access is further granted based on whether the tenant identifier of the signed grant token has sufficient rights to grant the specified resource with respect to the role identifier. Clause 7. The method of any one of clauses 1-6, wherein a first one of the tenants includes a proxy tenant representing an external service provider for which policy-based sharing is implemented. Clause 8. The method of any one of clauses 1 to 7, wherein the policy-based access control definition includes a reference to a smart contract. Clause 9. The method of any one of clauses 1 to 8, wherein the policy-based access control definition includes a reference to a service level of a second one of the tenants, and access is granted according to the service level of the second one of the tenants determined at the time of the request. Clause 10. The method of any one of clauses 1 to 9, wherein the policy-based access control definition specifies one or more access control statements including filter attributes and filter parameters. Clause 11. The method of clause 10, wherein the filter parameter specifies a wildcard for the filter attribute. Clause 12. The method of clause 10 or 11, wherein the filter attribute includes an application. Clause 13. The method of any one of clauses 10 or 11, wherein the filter attribute includes an application role identifier. Clause 14. The method of any one of clauses 1 to 13, wherein the policy-based access control definition supports access control statements that specify an access outcome, a tenant identifier, and one or more conditions under which access is granted. Clause 15. The method of any one of clauses 1 to 14, wherein the policy-based access control definition supports public access, private access, and application-based access. Clause 16. The method of any one of clauses 1 to 15, wherein the policy-based access control definition includes parameters that are evaluated at runtime. Article 17. the parameters of the policy-based access control definition include an application identifier parameter; 17. The method of clause 16, wherein granting access includes comparing an application identifier parameter of the policy-based access control definition with an application identifier specified by a second one of the tenants seeking access to the genomic digital data resource. Article 18. The parameters of the policy-based access control definition include a tenant identifier parameter; 18. The method of any one of clauses 16 or 17, wherein granting access includes comparing a tenant identifier parameter of the access control definition with a tenant identifier of a second tenant seeking access to the genomic digital data resource. Clause 19. A multi-tenant cloud-based system, one or more processors; a memory coupled to the one or more processors; a policy store containing policy-based access control definitions received for the first tenant and including role identifiers; a genomic digital data resource linked to the role identifier; The memory includes computer-executable instructions that cause one or more processors to perform operations, the operations including: receiving a request to access the genomic digital data resource from a second tenant seeking access to the genomic digital data resource; and and granting access to the genomic digital data resource for the second tenant according to a policy-based access control definition that is evaluated at the time of the access request. Clause 20. One or more computer-readable media, computer-executable instructions for causing a computing system to receive a publication request for providing access to genomic digital data for a first tenant, wherein access to the genomic digital data is controlled by a role identifier linked to a policy document, the policy document including one or more conditions; computer-executable instructions that cause a computing system to receive a request for access to genomic digital data from a second tenant, the request for access being controlled by a role identifier linked to a policy document, the request including one or more attributes; computer-executable instructions for causing the computing system to access the policy document in response to an access request from the second tenant; A computer-readable medium comprising: computer-executable instructions that cause a computing system to generate an access token based on one or more attributes and one or more conditions, wherein in response to determining that the one or more conditions are satisfied by the one or more attributes, a role identifier is included in the access token, and the access token authorizes access to the genomic digital data via the role identifier. Clause 21. One or more computer-readable media containing computer-executable instructions that, when executed by a computing system, cause the computing system to perform the method of any one of clauses 1-18.

[0371] Example 80 - Exemplary Embodiment Any of the following embodiments can be implemented.

[0372] Clause 1. A computer-implemented method comprising: 1. A computing system supporting multiple tenants accessing genomic computing services in a software-as-a-service platform that orchestrates access to genomic digital data resources through policy-based access control, Discover cloud provider accounts for identities that access software-as-a-service platforms, Sending a request to a credential management service for a limited, temporary, derived credential that is valid for the cloud provider account; Receive limited, temporary, derived credentials that are valid for your cloud provider account, and A computer-implemented method comprising providing a limited, temporary, derived credential for use by an identity. Article 2. 10. The computer-implemented method of claim 1, wherein the software-as-a-service platform supports multiple different cloud provider account types per single tenant. Article 3. 3. The computer-implemented method of any one of clauses 1 to 2, wherein the software-as-a-service platform supports multiple different cloud provider accounts per single tenant. Article 4. receiving policy-based access control configuration information for the plurality of tenants; 4. The computer-implemented method of any one of clauses 1-3, wherein the restricted temporary derived credentials are restricted to rights indicated in policy-based access control configuration information. Article 5. receiving underlying credentials for a cloud provider account; 5. The computer-implemented method of any one of clauses 1-4, wherein the restricted, temporary, derived credential is derived from an underlying credential. Article 6. 6. The computer-implemented method of any one of clauses 1-5, wherein the software-as-a-service platform supports limited, temporary, derived credentials for multiple cloud provider types. Article 7. 10. The computer-implemented method of claim 6, wherein discovering the cloud provider account includes discovering a cloud provider type of the cloud provider account. Article 8. 8. The computer-implemented method of claim 7, wherein the credential management service is external to the software-as-a-service platform. Article 9. 9. The computer-implemented method of any one of clauses 1-8, wherein the identity is one of a plurality of different identity types supported by the software-as-a-service platform. Article 10. 10. The computer-implemented method of claim 9, wherein the identity is of type "application." Article 11. 11. The computer-implemented method of clause 9 or 10, wherein the identity is of type "workgroup". Article 12. 12. The computer-implemented method of clause 11, wherein the workgroup identity spans multiple tenants of the software-as-a-service platform. Article 13. Identity types supported by the Software as a Service platform include: Applications and Tenants and Workgroups and a user. Article 14. A cloud provider account stores genomic digital data resources; Access to genomic digital data resources is controlled by role identifiers linked to policy-based access control definitions; The method is 14. The method of any one of clauses 1 to 13, further comprising, in response to a request for access to the genomic digital data resource, providing a role identifier specified in the policy-based access control definition for the access request. Clause 15. A multi-tenant cloud-based system, one or more processors; a memory coupled to the one or more processors; A mapping between identities accessing the software as a service platform and cloud provider accounts; a policy store containing policy-based access control definitions; a genomic digital data resource linked to a role identifier and stored in a given cloud provider account outside the software-as-a-service platform; The memory includes computer-executable instructions that cause one or more processors to perform operations, the operations including: Based on the mapping, discover the cloud provider account of the identity that accesses the software-as-a-service platform; Sending a request to a credential management service for a limited, temporary, derived credential that is valid for the cloud provider account; Receive limited, temporary, derived credentials that are valid for your cloud provider account, and 1. A system comprising: providing a limited, temporary, derived credential for use by an identity to access genomic digital data resources. Article 16. The software-as-a-service platform supports multiple different cloud provider account types per tenant, 16. The system of clause 15, wherein the software-as-a-service platform supports multiple different cloud provider accounts per tenant. Clause 17. The memory includes computer-executable instructions that cause one or more processors to perform operations, the operations including: 17. The system of clause 15 or 16, comprising granting access to the genomic digital data resource in accordance with policy-based access control definitions that are evaluated at the time of the access request. Article 18. 18. The computer-implemented method of any one of clauses 15-17, wherein the identity is one of a plurality of different identity types supported by the software-as-a-service platform. Article 19. The identity is of type "application". Clause 20. The computer-implemented method according to any one of clauses 15 to 18, The identity is of type "workgroup". Clause 21. The computer-implemented method according to clause 20, 19. The computer-implemented method of any one of clauses 15-18, wherein a workgroup identity spans multiple tenants of a software-as-a-service platform. Clause 22. One or more computer-readable media, 1. A computing system supporting multiple tenants accessing genomic computing services in a software-as-a-service platform that orchestrates access to genomic digital data resources through policy-based access control, comprising: Discover cloud provider accounts for identities that access software-as-a-service platforms, Sending a request to a credential management service for a limited, temporary, derived credential that is valid for the cloud provider account; Receive limited, temporary, derived credentials that are valid for your cloud provider account, and providing a limited, temporary, derived credential for use by an identity to access genomic digital data resources at a cloud provider account in accordance with policy-based access control; The software-as-a-service platform supports multiple different cloud provider account types per tenant, A software-as-a-service platform comprises one or more computer-readable media that support multiple different cloud provider accounts per tenant. Clause 23. One or more computer-readable media, A computer-readable medium comprising computer-executable instructions that cause a computing system to perform the method of any one of clauses 1-14.

[0373] Example 80 - Exemplary Embodiment Techniques from any example can be combined with techniques described in any one or more of the other examples. Given the many possible embodiments to which the principles of the disclosed technology can be applied, it should be recognized that the illustrated embodiments are examples of the disclosed technology and should not be construed as limiting the scope of the disclosed technology. Rather, the scope of the disclosed technology includes what is encompassed by the scope and spirit of the following claims.< / aws>

Claims

1. 1. A computer-implemented method comprising: In a computing system, providing access to genomic computing services in a software-as-a-service platform to multiple access tenants; Orchestrating access to genomic digital data resources through policy-based access control, Discovering a cloud provider account for the identity to access the software-as-a-service platform; Sending a request to a credential management service for a limited, temporary, derived credential valid for the cloud provider account; receiving the restricted temporary derived credential valid for the cloud provider account; and providing the limited temporary derived credential for use by the identity; The restricted temporary derived credential is based on a policy-based access control definition; the restricted temporary derived credential is restricted to the rights permitted in the policy-based access control definition; the restricted temporary derived credential is derived from an underlying credential; the restricted temporary derived credential provides more restricted access than the underlying credential; the restricted, temporary, derived credentials based on the policy-based access control definition are generated based on underlying credentials provided via cloud provider account management; the limited temporary derived credential is valid for a cloud provider account; the restricted, temporary, derived credential provides access to the genomic digital data resource; the software-as-a-service platform is configured to support a particular cloud provider type selected from a plurality of different cloud provider types specified by an operational service; The underlying credentials are persisted in a credential object; the credential object stores the particular cloud provider type selected from the plurality of different cloud provider types for the underlying credential; the particular cloud provider type selected from the plurality of different cloud provider types is provided during cloud provider account discovery; The computer-implemented method further includes storing, with the cloud provider account, a genomic digital data resource; access to said genomic digital data resource is controlled by a role identifier linked to a policy-based access control definition; the computer-implemented method further includes, in response to a request to access the genomic digital data resource, providing the role identifier specified in the policy-based access control definition for the access request. Computer-implemented methods.

2. The computer-implemented method of claim 1 , wherein the software-as-a-service platform supports multiple different cloud provider account types per single tenant.

3. The computer-implemented method of claim 1 or 2, wherein the software-as-a-service platform supports multiple different cloud provider accounts per single tenant.

4. receiving policy-based access control configuration information for the plurality of access tenants; The computer-implemented method of any one of claims 1 to 3, wherein the restricted temporary derived credential is restricted to rights indicated in the policy-based access control configuration information.

5. receiving underlying credentials for the cloud provider account; The computer-implemented method of any one of claims 1 to 4, wherein the restricted temporary derived credential is derived from the underlying credential.

6. The computer-implemented method of any one of claims 1 to 5, wherein the software-as-a-service platform supports limited, temporary, derived credentials for multiple cloud provider types.

7. The computer-implemented method of claim 6 , wherein discovering the cloud provider account comprises discovering a cloud provider type of the cloud provider account.

8. The computer-implemented method of any one of claims 1 to 7, wherein the identity is one of a plurality of different identity types supported by the software-as-a-service platform.

9. The computer-implemented method of claim 8 , wherein the identity is of type “application.”

10. The computer-implemented method of claim 8 , wherein the identity is of type “workgroup.”

11. The computer-implemented method of claim 10 , wherein a workgroup identity spans multiple tenants of the software-as-a-service platform.

12. The identity types supported by the software-as-a-service platform are: Applications and Tenants and Workgroups and A computer-implemented method according to any one of claims 8 to 11, comprising:

13. the cloud provider account stores genomic digital data resources; access to said genomic digital data resource is controlled by a role identifier linked to a policy-based access control definition; The computer-implemented method comprises:

13. The computer-implemented method of claim 1, further comprising: in response to a request for access to the genomic digital data resource, providing the role identifier specified in the policy-based access control definition for the access request.

14. One or more non-transitory computer-readable storage media containing computer-executable instructions, The computer-executable instructions may include: In a computing system, providing access to genomic computing services in a software-as-a-service platform to multiple access tenants; Orchestrating access to genomic digital data resources through policy-based access control, Discovering a cloud provider account for the identity to access the software-as-a-service platform; Sending a request to a credential management service for a limited, temporary, derived credential valid for the cloud provider account; receiving the restricted temporary derived credential valid for the cloud provider account; and providing the limited temporary derived credential for use by the identity; The restricted temporary derived credential is based on a policy-based access control definition; the restricted temporary derived credential is restricted to the rights permitted in the policy-based access control definition; the restricted temporary derived credential is derived from an underlying credential; the restricted temporary derived credential provides more restricted access than the underlying credential; the restricted, temporary, derived credentials based on the policy-based access control definition are generated based on underlying credentials provided via cloud provider account management; the limited temporary derived credential is valid for a cloud provider account; the restricted, temporary, derived credential provides access to the genomic digital data resource; the software-as-a-service platform is configured to support a particular cloud provider type selected from a plurality of different cloud provider types specified by an operational service; The underlying credentials are persisted in a credential object; the credential object stores the particular cloud provider type selected from the plurality of different cloud provider types for the underlying credential; the particular cloud provider type selected from the plurality of different cloud provider types is provided during cloud provider account discovery; The computer-executable instructions may further cause the computing system to store a genomic digital data resource with the cloud provider account; access to said genomic digital data resource is controlled by a role identifier linked to a policy-based access control definition; The computer-executable instructions may further cause the computing system to: in response to a request to access the genomic digital data resource, provide the role identifier specified in the policy-based access control definition for the access request. One or more non-transitory computer-readable storage media.

15. A software-as-a-service platform that orchestrates access to genomic digital data resources through policy-based access control, comprising: a computing system that provides access to genomic computing services to multiple access tenants; one or more processors; a memory coupled to the one or more processors; The memory includes computer-executable instructions that cause the one or more processors to perform operations, the operations comprising: Discovering a cloud provider account for the identity to access the software-as-a-service platform; Sending a request to a credential management service for a limited, temporary, derived credential valid for the cloud provider account; receiving the restricted temporary derived credential valid for the cloud provider account; and providing the limited, temporary, derived credential for use by the identity to access the genomic digital data resource; The restricted temporary derived credential is based on a policy-based access control definition; the restricted temporary derived credential is restricted to the rights permitted in the policy-based access control definition; the restricted temporary derived credential is derived from an underlying credential; the restricted temporary derived credential provides more restricted access than the underlying credential; the restricted, temporary, derived credentials based on the policy-based access control definition are generated based on underlying credentials provided via cloud provider account management; the limited temporary derived credential is valid for a cloud provider account; the restricted, temporary, derived credential provides access to the genomic digital data resource; the software-as-a-service platform is configured to support a particular cloud provider type selected from a plurality of different cloud provider types specified by an operational service; The underlying credentials are persisted in a credential object; the credential object stores the particular cloud provider type selected from the plurality of different cloud provider types for the underlying credential; the particular cloud provider type selected from the plurality of different cloud provider types is provided during cloud provider account discovery; the operations further include storing, with the cloud provider account, a genomic digital data resource; access to said genomic digital data resource is controlled by a role identifier linked to a policy-based access control definition; the operations further include, in response to a request for access to the genomic digital data resource, providing the role identifier specified in the policy-based access control definition for the access request. system.

16. the software-as-a-service platform supports multiple different cloud provider account types per tenant; The system of claim 15 , wherein the software-as-a-service platform supports multiple different cloud provider accounts per tenant.

Images