Abstract: Disclosed are various embodiments for resolving conflicts between workflows in a workflow processing system. A plurality of workflows stored in a workflow queue are evaluated to identify a common dependency of the plurality of workflows. Then, a version hierarchy is created for the common dependency of the plurality of workflows, the version hierarchy identifying multiple versions of the common dependency. In response to execution of a first one of the plurality of workflows stored in the workflow queue, the version hierarchy can be evaluated to identify the most recent version of the common dependency. Then, installation of the most recent version of the common dependency can be initiated.

Abstract: Disclosed are various embodiments for resolving conflicts between workflows in a workflow processing system. A plurality of workflows stored in a workflow queue are evaluated to identify a common dependency of the plurality of workflows. Then, a version hierarchy is created for the common dependency of the plurality of workflows, the version hierarchy identifying multiple versions of the common dependency. In response to execution of a first one of the plurality of workflows stored in the workflow queue, the version hierarchy can be evaluated to identify the most recent version of the common dependency. Then, installation of the most recent version of the common dependency can be initiated.

Abstract: Disclosed are various embodiments for resolving conflicts between workflows in a workflow processing system. A plurality of workflows stored in a workflow queue are evaluated to identify a common dependency of the plurality of workflows. Then, a version hierarchy is created for the common dependency of the plurality of workflows, the version hierarchy identifying multiple versions of the common dependency. In response to execution of a first one of the plurality of workflows stored in the workflow queue, the version hierarchy can be evaluated to identify the most recent version of the common dependency. Then, installation of the most recent version of the common dependency can be initiated.

Abstract: Disclosed are various embodiments for recognizing state changes in client devices and managing the state of client devices using device-driven management workflows. A computing device can receive a state of a client device. The computing device can then determine if the received state matches an expected, compliant state of the client device. When the computing device determines that the received state does not match the expected state, the computing device can identify a remedial workflow that would bring the client device into compliance. The computing device can send the remedial workflow and an instruction to run the remedial workflow to the client device.

Abstract: Disclosed are various embodiments for managing the state of client devices using device-driven management workflows. A computing device can be evaluated to determine the current state of the computing device. Then, the current state of the computing device is compared to an expected state of the computing device. The expected state of the computing device may be based at least in part on a result of execution of at least one device-driven management workflow by the computing device. In response to a determination that the current state of the computing device fails to match the expected state of the computing device, the device-driven management workflow can be executed to resolve the discrepancy between the expected state and the current state.

Abstract: Disclosed are various examples for distributed profile and key management. In one example, a client device can include an agent application and a PIV-D application. The agent application can receive a partially populated device profile generated by a management service to configure a setting on the client device. The PIV-D application can generate a derived credential and provide the derived credential to the agent application. The agent application can modify the partially populated device profile to include the credential to create a fully populated device profile and configure the client device in accordance with the fully populated device profile.

Abstract: Disclosed are various embodiments for securely distributing certificates or encryption keys. A management service can receive an enrollment request from a client device. The management service can then send a key request to a certificate provider, the key request comprising a user identifier. The management service can also send a skeleton payload to an enterprise gateway. In response, the management service can receive an encrypted profile from the enterprise gateway, the encrypted profile comprising the skeleton payload with an encryption key inserted by the enterprise gateway into the skeleton payload. Finally, the management service can send the encrypted profile to the client device.

Abstract: Disclosed are various embodiments for resolving conflicts between workflows in a workflow processing system. A plurality of workflows stored in a workflow queue are evaluated to identify a common dependency of the plurality of workflows. Then, a version hierarchy is created for the common dependency of the plurality of workflows, the version hierarchy identifying multiple versions of the common dependency. In response to execution of a first one of the plurality of workflows stored in the workflow queue, the version hierarchy can be evaluated to identify the most recent version of the common dependency. Then, installation of the most recent version of the common dependency can be initiated.

Abstract: Disclosed are various embodiments for managing the state of client devices using device-driven management workflows. A computing device can be evaluated to determine the current state of the computing device. Then, the current state of the computing device is compared to an expected state of the computing device. The expected state of the computing device may be based at least in part on a result of execution of at least one device-driven management workflow by the computing device. In response to a determination that the current state of the computing device fails to match the expected state of the computing device, the device-driven management workflow can be executed to resolve the discrepancy between the expected state and the current state.

Abstract: Disclosed are various approaches for validating public keys pinned to services or servers on private networks. A client device can request a first certificate from a trust service. The client device can then validate that the first certificate from the trust service is signed by a preinstalled certificate stored on the client device. Subsequently, the client device can receive a uniform resource locator identifying a network location of a secure sockets layer (SSL) pinning service, wherein the SSL pinning service is configured to provide a hash value for a first public key issued to a computing device. Finally, the client device can receive a second public key from the trust service, wherein the second public key is configured to encrypt network traffic sent to the SSL pinning service.

Abstract: Disclosed are various embodiments for securely distributing certificates or encryption keys. A management service can receive an enrollment request from a client device. The management service can then send a key request to a certificate provider, the key request comprising a user identifier. The management service can also send a skeleton payload to an enterprise gateway. In response, the management service can receive an encrypted profile from the enterprise gateway, the encrypted profile comprising the skeleton payload with an encryption key inserted by the enterprise gateway into the skeleton payload. Finally, the management service can send the encrypted profile to the client device.

Abstract: Disclosed are various embodiments for securely distributing certificates or encryption keys. A management service can receive an enrollment request from a client device. The management service can then send a key request to a certificate provider, the key request comprising a user identifier. The management service can also send a skeleton payload to an enterprise gateway. In response, the management service can receive an encrypted profile from the enterprise gateway, the encrypted profile comprising the skeleton payload with an encryption key inserted by the enterprise gateway into the skeleton payload. Finally, the management service can send the encrypted profile to the client device.

Abstract: Disclosed are various examples for distributed profile and key management. In one example, a management service can generate a partially populated device profile and provide the partially populated device profile to a client application executable on a client device. The client application can generate a credential and insert the credential into the partially populated device profile to generate a fully populated device profile. The credential can be shared with at least one other client application on the client device. The management service can use the fully populated device profile to generate multiple profiles that rely on a single credential, such as a single X.509 security certificate.

Abstract: Disclosed are various approaches for validating public keys pinned to services or servers on private networks. A client device can request a first certificate from a trust service. The client device can then validate that the first certificate from the trust service is signed by a preinstalled certificate stored on the client device. Subsequently, the client device can receive a uniform resource locator identifying a network location of a secure sockets layer (SSL) pinning service, wherein the SSL pinning service is configured to provide a hash value for a first public key issued to a computing device. Finally, the client device can receive a second public key from the trust service, wherein the second public key is configured to encrypt network traffic sent to the SSL pinning service.

Abstract: Disclosed are various approaches for implementing certificate pinning in a tunnel client on a client device. A tunnel client receives a connection request from an application executed by the client device to connect to a remote server. The tunnel client determines that the remote server corresponds to a known pinned host and then determines whether the remote server presents a certificate matching a pinned certificate for the known pinned host. If the presented certificate matches the pinned certificate, the tunnel client allows a connection to be established between the application and the remote server through a network tunnel between the tunnel client and a tunnel server.

Abstract: Disclosed are various approaches for validating public keys pinned to services or servers on private networks. A client device can request a first certificate from a trust service. The client device can then validate that the first certificate from the trust service is signed by a preinstalled certificate stored on the client device. Subsequently, the client device can receive a uniform resource locator identifying a network location of an secure sockets layer (SSL) pinning service, wherein the SSL pinning service is configured to provide a hash value for a first public key issued to a computing device. Finally, the client device can receive a second public key from the trust service, wherein the second public key is configured to encrypt network traffic sent to the SSL pinning service.

Abstract: Disclosed are various approaches for providing single sign-on capabilities for a user on a client device. A user's credentials can be authenticated by an identity provider application. The identity provider application can facilitate single sign-on capabilities for browser-based applications and native applications on the client device.

Abstract: Disclosed are various approaches for a secure communication session between applications installed on a client device. The secure communication session can be provided over an insecure operating system application programming interface (API). By exchanging session information and encryption data, communications over the insecure API can be secured.

Abstract: Disclosed are various examples for distributed profile and key management. In one example, a client device can include an agent application and a PIV-D application. The agent application can receive a partially populated device profile generated by a management service to configure a setting on the client device. The PIV-D application can generate a derived credential and provide the derived credential to the agent application. The agent application can modify the partially populated device profile to include the credential to create a fully populated device profile and configure the client device in accordance with the fully populated device profile.

Abstract: Disclosed are various examples for distributed profile and key management. In one example, a management service can generate a partially populated device profile and provide the partially populated device profile to a client application executable on a client device. The client application can generate a credential and insert the credential into the partially populated device profile to generate a fully populated device profile. The credential can be shared with at least one other client application on the client device. The management service can use the fully populated device profile to generate multiple profiles that rely on a single credential, such as a single X.509 security certificate.