Abstract: Techniques are disclosed for unifying a first identity management service with a second identity management service within a distributed computing system. The first identity management service can receive a request to perform an entity operation. The request may be formatted for an interface of the first identity service. The first identity service can determine that the account is in a second domain associated with the second identity service and transform the request to a format corresponding to an interface of the second identity service. The transformed request may be transmitted to the second identity service using an external proxy and based in part on the second domain corresponding to the second identity service.

Abstract: In some aspects, an authentication service may divide authentication data into one or more data stripes, the authentication data including at least one of: user identifier (userID); group identifier (groupID); group membership; client identifier (clientID); dynamic group (DG) membership; or dynamic group identifier. The authentication service may store the one or more data stripes in one or more databases, the databases being contained in a host machine of a fleet, where the fleet contains one or more host machines. The authentication service may update the databases from the data stripe via a background thread. Numerous other aspects are described.

Abstract: Systems and methods for a single logout between two independent systems are described herein. The system includes a first access control system having a first login protocol. The first access control system includes at least one first processor, and a memory comprising a plurality of instructions executable by the at least one first processor. The system includes a second access control system. The second access control system has a second login protocol independent of the first login protocol. The first access control system can receive a logout request from a user at the first access control system, logging the user out of the first access control system, and utilizing a trust mechanism to log the user out of the second access control system.

Abstract: The present embodiments relate to a CI replication service that can replicate domain data from IDCS control plane to data plane and to all subscribed regions of a domain. For instance, the CI replication service can provide replication of required resources of a domain for AuthN and AuthZ from an IDCS local region to other regions for high availability (e.g., to improve latency). The CI replication service can replicate the resources from a domain's home region to all subscribed regions for local availability of data for workloads running in those regions. Further, when a new region is subscribed for a domain, then the service can bootstrap that domain's data from home region before enabling that region for the domain.

Abstract: Techniques are discloses for exchanging tokens between different identity systems that follow different identity models. A token exchange system of an integrated identity management system of a cloud service can determine that that an entity is authorized to access a first identity system based on credentials of the entity entered in the first identity system. The token exchange system can exchange a first token for the first identity system for a second token for the second identity system without requiring entry of credentials to access the second identity system.

Abstract: Techniques are described that enable, in a multi-region cloud environment, information regarding one or more tenancy sessions that a network access program (e.g., a browser) participates in to be efficiently stored in a centralized location. The centrally stored sessions information can then be used for various purposes such as for restricting the number of tenancy sessions using a network access program, sessions cleanup, and other sessions-related tasks. In certain implementations, the centrally stored sessions information is used to prevent the network access program from opening multiple sessions for the same tenancy. In such implementations, for a particular tenancy, the network access program is allowed to have only one active session for the particular tenancy at a time. The centrally stored sessions information facilitates efficient sessions management including session cleanup after a session is closed.

Abstract: A host computing device may receive a request to authorize an entity, the authorization request comprising an entity tag. The host may send a domain request, containing an entity tag, for a domain tag to a first fleet. The host may receive the domain tag from the first fleet and store the domain tag in a cache memory. The host may identify a data stripe tag, stored in a host database, associated with the domain tag. The host may send a fleet request for a fleet tag, with the data stripe tag, to a second fleet. The host may receive the fleet tag. The host may send an information request for a plurality of authentication information to an identified fleet associated with the fleet tag. The host may receive the plurality of authentication information. The host may determine whether to authorize the entity based on the authentication information.

Abstract: A framework for migrating a customer tenancy from a first identity and access management (TAM) system to a second IAM system. A first snapshot of the customer tenancy is obtained from a first data storage. The first snapshot is processed and migrated to the second IAM system. A second snapshot of the customer tenancy is obtained from a second data storage and migrated to the second IAM system. A state of a lock associated with the second data storage is modified, where after a third snapshot of the customer tenancy is obtained from the second data storage and migrated to the second IAM system. Responsive to the third snapshot being migrated, directing a request regarding the customer tenancy to the second IAM system.

Abstract: Techniques are disclosed for restricting operations between two attached two compute instances. An infrastructure and a generalized method is described for attaching two or more cloud resources (e.g., two compute instances) in spite of the compute resources being provisioned by two different services from different cloud tenancies, and then modifying the allowed operations that can be performed due to the attachment.

Abstract: Systems and methods described herein support tag based request context in a cloud infrastructure environment. Cloud administrators do not generally have the ability to restrict resource usage in existing clouds. Granting a user permission to create resources allows them to create and/or terminate any number of resources up to a predefined account limit. Tags are associated with requests for resources for allowing administrators to restrict a user's handling of resources to the appropriate level by allowing fine-tuned control of access to the resources based on the context of the request for the resources. Request context information of the request is compared against a required credential gate level for permitting handling of resources in a tenancy having the first privilege level classification, and the request is selectively granted based on the request context information matching the first required credential gate level.

Abstract: Techniques are described for enabling resources within a cloud computing system to interact with each other. In certain embodiments, a token renewal mechanism is provided for extending the duration in which a first resource can access another resource. The token renewal mechanism can involve the first resource periodically causing a new credential to be generated for itself and then communicating the new credential to an identity and access management (IAM) system. The new credential may be generated for compliance with a credential rotation policy specifying that credentials should be changed after a certain period of time. The IAM system may associate a digital access token with the new credential so that for subsequent requests, the IAM system will only recognize the resource principal based upon the new credential. The digital token can be invalidated if a new credential is not changed within the specified period of time.

Abstract: The present embodiments relate to systems and methods for automatic sign in upon account signup. Particularly, the present embodiments can utilize a federated login approach for automatic sign in upon account signup for a cloud infrastructure. Specifically, the signup and sign in service (also known as SOUP) and an identity provider portal can be configured such that the nodes are aware of each other as Security Assertion Markup Language (SAML) partners. After new account registration, the signup service can redirect the user browser to a cloud infrastructure console to start with a federated login flow, where a sign in service can issue a SAML authentication request, and redirects it to signup service. Responsive to validating the browser using a SAML authentication process, the browser can be automatically signed into the new account and allowed access the account relating to the cloud infrastructure service.

Abstract: A cloud-based security solution that provides a robust and secure framework for managing and enforcing security policies related to various resources managed in the cloud is disclosed. The cloud-based security solution is implemented by a security zone policy enforcement system in a cloud service provider infrastructure. The system receives a request to perform an operation on a resource and determines a compartment associated with the resource. The system determines that the compartment is associated with a security zone and determines a set of one or more security zone policies applicable to the resource. The system then determines that the operation on the resource is permitted based on the set of one or more security zone policies and responsive to determining that the operation on the resource is permitted, allows the operation to be performed on the resource.

Abstract: Techniques are described for enabling resources within a cloud computing system to interact with each other. In certain embodiments, a resource is assigned a digital token that provides certain access privileges for the duration in which the digital token is valid. The digital token permits the resource to have access for a duration sufficient to perform some operation (e.g., run one-time code or the same code periodically on a scheduled basis), but without extending the level of access for significantly longer than necessary to complete the operation. Each time the resource principal is to perform the operation, the token can be reissued to the resource to provide the resource with time-limited access privileges. The use of this short-lived token avoids having to create permanent credentials for the resource.

Abstract: Techniques are described for enabling resources within a cloud computing system to interact with each other. In certain embodiments, a token renewal mechanism is provided for extending the duration in which a first resource can access another resource. The token renewal mechanism can involve the first resource periodically causing a new credential to be generated for itself and then communicating the new credential to an identity and access management (IAM) system. The new credential may be generated for compliance with a credential rotation policy specifying that credentials should be changed after a certain period of time. The IAM system may associate a digital access token with the new credential so that for subsequent requests, the IAM system will only recognize the resource principal based upon the new credential. The digital token can be invalidated if a new credential is not changed within the specified period of time.

Abstract: Techniques are described for enabling resources within a cloud computing system to interact with each other. In certain embodiments, a base identifier assigned to a first resource is extended by mapping the base identifier onto a second identifier assigned to a logical resource that is built upon the first resource. This allows the first resource to have two identities, one identity indicating what the first resource is (e.g., a particular compute instance) and another identity indicating the purpose of the first resource (e.g., operating as a database for a particular tenancy). Consequently, the first resource may be provided with access privileges different from those associated with the base identifier. For example, the first resource may access another resource in the tenancy using the second identifier, but may have no access to the other resource using the base identifier.

Abstract: Techniques are provided for establishing a session with an application using asymmetric cryptography. Techniques include secure single-sign on capabilities using asymmetric cryptography. With asymmetric signatures, the use of browser local storage and the Web Crypto application programming interface (API), the key cannot be extracted from the browser that it was generated for. The mechanism allows a web domain to track a user login session using a non-extractable asymmetric key stored in the client's web browser, and leverage the non-extractable asymmetric key for single sign-on.

Abstract: Techniques are provided for establishing a session with an application using asymmetric cryptography. Techniques include secure single-sign on capabilities using asymmetric cryptography. With asymmetric signatures, the use of browser local storage and the Web Crypto application programming interface (API), the key cannot be extracted from the browser that it was generated for. The mechanism allows a web domain to track a user login session using a non-extractable asymmetric key stored in the client's web browser, and leverage the non-extractable asymmetric key for single sign-on.

Abstract: Systems, methods, and software technology for managing keys used to encrypt data at-rest and decrypt the data when serving requests for the data. In an implementation, a data service receives a request for data that has been encrypted at rest using a data key, wherein the data key has been encrypted using a policy key, and wherein the policy key has been encrypted using a root key. When the root key is unavailable, the data service requests a key service to decrypt the policy key using an alternative root key. When the data service receives the policy key in an unencrypted state from the key service, it decrypts the data key using the policy key and decrypts the data using the data key.

Abstract: Systems and methods described herein support tag based request context in a cloud infrastructure environment. Cloud administrators do not generally have the ability to restrict resource usage in existing clouds. Granting a user permission to create resources allows them to create and/or terminate any number of resources up to a predefined account limit. Tags are associated with requests for resources for allowing administrators to restrict a user's handling of resources to the appropriate level by allowing fine-tuned control of access to the resources based on the context of the request for the resources. Request context information of the request is compared against a required credential gate level for permitting handling of resources in a tenancy having the first privilege level classification, and the request is selectively granted based on the request context information matching the first required credential gate level.