Abstract: Techniques are provided for granting an application of a first type of identity system, which uses a first type of identity token, access to a second type of identity system, which uses a second type of identity token. An application can make a request to a token exchange system. The request can include a bearer token and a public key of the application. The token exchange system can exchange the bearer token for a Proof-of-Possession token after performing verification steps. A token exchange system can exchange the first token (e.g., bearer token) for the first identity system for the second token (e.g., Proof-of-Possession token) for the second identity system without requiring entry of credentials to access the second identity system.

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: 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: 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: Described is a technology including an evaluation methodology by which a set of privileged code such as a platform's API method may be marked as being security critical and/or safe for being called by untrusted code. The set of code is evaluated to determine whether the code is security critical code, and if so, it is identified as security critical. Such code is further evaluated to determine whether the code is safe with respect to being called by untrusted code, and if so, is marked as safe. To determine whether the code is safe, a determination is made as to whether the first set of code leaks criticality, including by evaluating one or more code paths corresponding to one or more callers of the first set of code, and by evaluating one or more code paths corresponding to one or more callees of the first set of code.

Abstract: Described are security critical data containers for platform code, comprising a Get container and Set container that allow data to be marked as security critical for critical usage of that data, but left unmarked for non-critical usage. The number of critical methods in the code is reduced, facilitating better code analysis. A container's method may be marked as security critical, with the only access to the data via the method. By using a generic class for a Get container, access to the critical data only occurs through the property on the class, which is marked as critical. The field pointing to the generic class instance need not be critical, whereby initialization or existence checking may remain non-critical. The Set container handles security critical situations such as data that controls whether code can elevate permissions; a set method is marked as critical, while other methods can be accessed by non-critical code.

Abstract: Described is a mechanism for enabling an application operating as a web application to transition to a client-side application without impacting a user's interaction with the application. The progressive installation transitions through three states: a start-up state, a demand state, and an install state. During the start-up state, a subset of components associated with the application is downloaded and stored in a local data store. The subset is sufficient to allow execution of the application in a manner similar to a web application. During the demand state, additional resources associated with the application are downloaded. Transitioning from the demand state to the installed state occurs without impacting a user's interaction with the application. The transition may occur autonomously based on the number of additional resources stored in the local data store or upon an external trigger.

Abstract: Described is a mechanism for enabling an application operating as a web application to transition to a client-side application without impacting a user's interaction with the application. The progressive installation transitions through three states: a start-up state, a demand state, and an install state. During the start-up state, a subset of components associated with the application is downloaded and stored in a local data store. The subset is sufficient to allow execution of the application in a manner similar to a web application. During the demand state, additional resources associated with the application are downloaded. Transitioning from the demand state to the installed state occurs without impacting a user's interaction with the application. The transition may occur autonomously based on the number of additional resources stored in the local data store or upon an external trigger.

Abstract: Described is a mechanism for enabling an application operating as a web application to transition to a client-side application without impacting a user's interaction with the application. The progressive installation transitions through three states: a start-up state, a demand state, and an install state. During the start-up state, a subset of components associated with the application is downloaded and stored in a local data store. The subset is sufficient to allow execution of the application in a manner similar to a web application. During the demand state, additional resources associated with the application are downloaded. Transitioning from the demand state to the installed state occurs without impacting a user's interaction with the application. The transition may occur autonomously based on the number of additional resources stored in the local data store or upon an external trigger.