Abstract: Embodiments operate a multi-tenant cloud system. At a first data center, embodiments authenticate a first client corresponding to a first tenant ID and store resources that correspond to the first client, the first data center in communication with a second data center that is configured to authenticate the first client and replicate the resources. The first data center receives an Application Programming Interface (“API”) request for the first client corresponding to a change to the resources, and generates a change log and corresponding change event message in response to the API request. Embodiments compute a first hash corresponding to the first tenant ID of the change log to determine a first partition of a first queue at the first data center. The first data center pushes the change event message to the second data center via an API call.

Abstract: Embodiments operate a multi-tenant cloud system. At a first data center, embodiments authenticate a first client and store resources that correspond to the first client, the first data center in communication with a second data center that is configured to authenticate the first client. Embodiments divide the resources into base data and regular data, where the base data is a minimum data needed to allow the resources to be available to the first client at the second data center. Embodiments store the base data on a cloud storage in a base data export file and store the regular data on the cloud storage in a regular data export file. Embodiments export the base data export file to the second data center and when the exporting the base data export file has completed, exports the regular data export file to the second data center.

Abstract: Embodiments operate a multi-tenant cloud system. At a first data center, embodiments authenticate a first client corresponding to a first tenant ID and store resources that correspond to the first client, the first data center in communication with a second data center that is configured to authenticate the first client and replicate the resources. The first data center receives an Application Programming Interface (“API”) request for the first client corresponding to a change to the resources, and generates a change log and corresponding change event message in response to the API request. Embodiments compute a first hash corresponding to the first tenant ID of the change log to determine a first partition of a first queue at the first data center. The first data center pushes the change event message to the second data center via an API call.

Abstract: Embodiments include a multi-tenant cloud system with a first data center and a second remote data center. The first data center authenticates a first client and stores resources that correspond to the first client, and is in communication with the second data center. The second data center authenticates the first client and replicates the resources. The first data center receives a write request for the first client, writes the write request and generates change event messages in a first order. The first data center pushes the change event messages to the second data center via REST API calls. In response to receiving the change event messages, the second data center is configured to write the change event messages in the first order to its local database.

Abstract: Embodiments operate a multi-tenant cloud system. At a first data center, embodiments authenticate a first client and store resources that correspond to the first client, the first data center in communication with a second data center that is configured to authenticate the first client. Embodiments divide the resources into base data and regular data, where the base data is a minimum data needed to allow the resources to be available to the first client at the second data center. Embodiments store the base data on a cloud storage in a base data export file and store the regular data on the cloud storage in a regular data export file. Embodiments export the base data export file to the second data center and when the exporting the base data export file has completed, exports the regular data export file to the second data center.

Abstract: Techniques for managing privileged accounts via a privileged access management service are provided. In some examples, the service may be configured with a plug-in framework for accessing secure resources. In some aspects, a log-in request that includes authentication information and corresponds to the service may be received. Session access to at least one secure resource may be provided when a user is authenticated. In some examples, a request to perform an action associated with the secure resource may be received during the session. Additionally, in some examples, the plug-in framework may be implemented to determine whether the user is allowed to perform the action. Further, performance of the action may be allowed or denied during the session based on the determination.

Abstract: A privileged account manager is provided for monitoring privileged sessions on target systems of an enterprise. In an embodiment, the privileged account manager is configured to capture metadata related to a privileged session and generate a first activity pattern for the privileged session based on the captured metadata. The first activity pattern may include a sequence of one or more activities performed by a first user during the privileged session. The privileged account manager may be configured to identify a second activity pattern that comprises at least a subset of the one or more activities performed by the first user during the privileged session and determine an appropriate action to be performed for the first activity pattern based on the identification of the second activity pattern. In some embodiments, the privileged account manager may be configured to transmit the action to a second user on a client device.

Abstract: Embodiments include a multi-tenant cloud system with a first data center and a second remote data center. The first data center authenticates a first client and stores resources that correspond to the first client, and is in communication with the second data center. The second data center authenticates the first client and replicates the resources. The first data center receives a write request for the first client, writes the write request and generates change event messages in a first order. The first data center pushes the change event messages to the second data center via REST API calls. In response to receiving the change event messages, the second data center is configured to write the change event messages in the first order to its local database.

Abstract: Techniques for managing privileged accounts via a privileged access management service are provided. In some examples, the service may be configured with a plug-in framework for accessing secure resources. In some aspects, a log-in request that includes authentication information and corresponds to the service may be received. Session access to at least one secure resource may be provided when a user is authenticated. In some examples, a request to perform an action associated with the secure resource may be received during the session. Additionally, in some examples, the plug-in framework may be implemented to determine whether the user is allowed to perform the action. Further, performance of the action may be allowed or denied during the session based on the determination.

Abstract: Techniques for managing privileged accounts via a privileged access management service are provided. In some examples, the service may be configured with a plug-in framework for accessing secure resources. In some aspects, a log-in request that includes authentication information and corresponds to the service may be received. Session access to at least one secure resource may be provided when a user is authenticated. In some examples, a request to perform an action associated with the secure resource may be received during the session. Additionally, in some examples, the plug-in framework may be implemented to determine whether the user is allowed to perform the action. Further, performance of the action may be allowed or denied during the session based on the determination.

Abstract: Techniques for managing privileged accounts via a privileged access management service are provided. In some examples, the service may be configured with a plug-in framework for accessing secure resources. In some aspects, plug-in code for implementing a workflow that includes step-up validation associated with a user attempting to access at least one secure resource may be received. Access to the at least one secure resource may be provided when the user is authenticated with respect to the service. In some examples, a request to access a second secure resource may be received. Additionally, in some examples, the workflow to perform the step-up validation may be implemented at least in response to the request to access the second secure resource. The workflow implemented based at least in part on an attribute associated with the request.

Abstract: A privileged account manager is provided for monitoring privileged sessions on target systems of an enterprise. In an embodiment, the privileged account manager is configured to capture metadata related to a privileged session and generate a first activity pattern for the privileged session based on the captured metadata. The first activity pattern may include a sequence of one or more activities performed by a first user during the privileged session. The privileged account manager may be configured to identify a second activity pattern that comprises at least a subset of the one or more activities performed by the first user during the privileged session and determine an appropriate action to be performed for the first activity pattern based on the identification of the second activity pattern. In some embodiments, the privileged account manager may be configured to transmit the action to a second user on a client device.

Abstract: A system and method can support user account management in a computing environment. A user account manager can configure one or more recording policies, wherein said one or more recording policies operates to define detailed information on how user activities on a target system should be recorded. Furthermore, the user account manager can provide said one or more recording policies to one or more visual session recording processes associated with the target system. Then, the user account manager can use said one or more visual session recording processes to record activities in a user session on the target system based on said one or more recording policies.

Abstract: Techniques for managing accounts are provided. An access management system may check out credentials for accessing target systems. For example a user may receive a password for a period of time or until checked back in. Access to the target system may be logged during this time. Upon the password being checked in, a security account may modify the password so that the user may not log back in without checking out a new password. Additionally, in some examples, password policies for the security account may be managed. As such, when a password policy changes, the security account password may be dynamically updated. Additionally, in some examples, hierarchical viewing perspectives may be determined and/or selected for visualizing one or more managed accounts. Further, accounts may be organized into groups based on roles, and grants for the accounts may be dynamically updated as changes occur or new accounts are managed.

Abstract: Techniques for managing privileged accounts via a privileged access management service are provided. In some examples, the service may be configured with a plug-in framework for accessing secure resources. In some aspects, a log-in request that includes authentication information and corresponds to the service may be received. Session access to at least one secure resource may be provided when a user is authenticated. In some examples, a request to perform an action associated with the secure resource may be received during the session. Additionally, in some examples, the plug-in framework may be implemented to determine whether the user is allowed to perform the action. Further, performance of the action may be allowed or denied during the session based on the determination.

Abstract: Techniques for managing privileged accounts via a privileged access management service are provided. In some examples, the service may be configured with a plug-in framework for accessing secure resources. In some aspects, plug-in code for implementing a workflow that includes step-up validation associated with a user attempting to access at least one secure resource may be received. Access to the at least one secure resource may be provided when the user is authenticated with respect to the service. In some examples, a request to access a second secure resource may be received. Additionally, in some examples, the workflow to perform the step-up validation may be implemented at least in response to the request to access the second secure resource. The workflow implemented based at least in part on an attribute associated with the request.

Abstract: Various embodiments of the present disclosure provide for an asynchronous state engine incorporated within a host application program. The state engine may operate based on a state transition table that may be updated independently of the host application. The state transition table may instruct the asynchronous state engine as to actions that should be performed prior to changing states. Such actions may include interacting with external applications. The state transition table may also instruct the host application to reside in a hold state until responses from external applications are received. Furthermore, the state transition table may instruct the host application as to follow up actions that should be performed when a state is entered. By allowing an external application to plug-in criteria for state changes within the host application, development of the host application may maintain a significant level of flexibility.

Abstract: Various embodiments of the present disclosure provide for an asynchronous state engine incorporated within a host application program. The state engine may operate based on a state transition table that may be updated independently of the host application. The state transition table may instruct the asynchronous state engine as to actions that should be performed prior to changing states. Such actions may include interacting with external applications. The state transition table may also instruct the host application to reside in a hold state until responses from external applications are received. Furthermore, the state transition table may instruct the host application as to follow up actions that should be performed when a state is entered. By allowing an external application to plug-in criteria for state changes within the host application, development of the host application may maintain a significant level of flexibility.