Abstract: Software development kit (“SDK”) applications may be implemented with user data on an enterprise end-user or shared device subsequent to a single check-out process on the device. A user profile and a context ID for a user can be accessed based on user provided credentials. An agent application can set a value of an agent context ID to a server context ID corresponding to the context ID for the user profile. A status of a local context ID (“LCID”) of an SDK application can be determined in response to an application launch. Using the LCD, a context ID comparison can be performed on the device with a value of a context ID from one of the SDK application, the server, and the agent application based on the LCID status. The SDK application can be implemented with user specific user data obtained from one of the SDK application and the agent application based on a result of the context ID comparison.

Abstract: Software development kit (“SDK”) applications may be implemented with user data on an enterprise end-user or shared device subsequent to a single check-out process on the device. A user profile and a context ID for a user can be accessed based on user provided credentials. An SDK application can be identified as one application of an application cluster including at least two applications. A status of a local context ID (“LCID”) of the SDK application can be determined, and a value for the LCID can be established based on the status and a value of a comparison context ID obtained from a server or an agent application. The LCID and a context ID for a keychain for the application cluster can be compared, and the SDK application can be implemented with user specific user data obtained from the agent application or the keychain based on a result of the comparison.

Abstract: Aspects of providing single sign on (SSO) sessions are described. An access interval key is generated using an access code as a seed to a key derivative function. The access interval key is encrypted using a public key of an SSO-enabled application to generate an encrypted access interval key for a sign on session. The sign on session is established by storing the encrypted access interval key in a memory location of an SSO session map shared by SSO-enabled applications.

Abstract: Software development kit (“SDK”) applications may be implemented with user data on an enterprise end-user or shared device subsequent to a single check-out process on the device. A user profile and a context ID for a user can be accessed based on user provided credentials. An SDK application can be identified as one application of an application cluster including at least two applications. A status of a local context ID (“LCID”) of the SDK application can be determined, and a value for the LCID can be established based on the status and a value of a comparison context ID obtained from a server or an agent application. The LCID and a context ID for a keychain for the application cluster can be compared, and the SDK application can be implemented with user specific user data obtained from the agent application or the keychain based on a result of the comparison.

Abstract: Software development kit (“SDK”) applications may be implemented with user data on an enterprise end-user or shared device subsequent to a single check-out process on the device. A user profile and a context ID for a user can be accessed based on user provided credentials. An agent application can set a value of an agent context ID to a server context ID corresponding to the context ID for the user profile. A status of a local context ID (“LCID”) of an SDK application can be determined in response to an application launch. Using the LCD, a context ID comparison can be performed on the device with a value of a context ID from one of the SDK application, the server, and the agent application based on the LCID status. The SDK application can be implemented with user specific user data obtained from one of the SDK application and the agent application based on a result of the context ID comparison.

Abstract: Software development kit (“SDK”) applications may be implemented with user data on an enterprise end-user or shared device subsequent to a single check-out process on the device. A user profile and a context ID for a user can be accessed based on user provided credentials. An agent application can set a value of an agent context ID to a server context ID corresponding to the context ID for the user profile. A status of a local context ID (“LCID”) of an SDK application can be determined in response to an application launch. Using the LCD, a context ID comparison can be performed on the device with a value of a context ID from one of the SDK application, the server, and the agent application based on the LCID status. The SDK application can be implemented with user specific user data obtained from one of the SDK application and the agent application based on a result of the context ID comparison.

Abstract: Software development kit (“SDK”) applications may be implemented with user data on an enterprise end-user or shared device subsequent to a single check-out process on the device. A user profile and a context ID for a user can be accessed based on user provided credentials. An SDK application can be identified as one application of an application cluster including at least two applications. A status of a local context ID (“LCID”) of the SDK application can be determined, and a value for the LCID can be established based on the status and a value of a comparison context ID obtained from a server or an agent application. The LCID and a context ID for a keychain for the application cluster can be compared, and the SDK application can be implemented with user specific user data obtained from the agent application or the keychain based on a result of the comparison.

Abstract: Software development kit (“SDK”) applications may be implemented with user data on an enterprise end-user or shared device subsequent to a single check-out process on the device. A user profile and a context ID for a user can be accessed based on user provided credentials. An agent application can set a value of an agent context ID to a server context ID corresponding to the context ID for the user profile. A status of a local context ID (“LCID”) of an SDK application can be determined in response to an application launch. Using the LCD, a context ID comparison can be performed on the device with a value of a context ID from one of the SDK application, the server, and the agent application based on the LCID status. The SDK application can be implemented with user specific user data obtained from one of the SDK application and the agent application based on a result of the context ID comparison.

Abstract: Software development kit (“SDK”) applications may be implemented with user data on an enterprise end-user or shared device subsequent to a single check-out process on the device. A user profile and a context ID for a user can be accessed based on user provided credentials. An SDK application can be identified as one application of an application cluster including at least two applications. A status of a local context ID (“LCID”) of the SDK application can be determined, and a value for the LCID can be established based on the status and a value of a comparison context ID obtained from a server or an agent application. The LCID and a context ID for a keychain for the application cluster can be compared, and the SDK application can be implemented with user specific user data obtained from the agent application or the keychain based on a result of the comparison.

Abstract: Various examples for application management detection are described. In one example, depending upon whether an installation token includes a unique token value, a client device can determine whether an application is managed or unmanaged. Additionally, the client device can determine whether the application is managed or unmanaged based on whether a keychain installation token includes a unique token value, a value of a keychain installation token, and a value of a launched flag for the application. Using the concepts described herein, an unmanaged application can proceed to execute with limited functionality, present a notification that it should be reinstalled by the management service, stop executing, or take other measures.

Abstract: Aspects of providing single sign on (SSO) sessions are described. An access interval key is generated using an access code as a seed to a key derivative function. The access interval key is encrypted using a public key of an SSO-enabled application to generate an encrypted access interval key for a sign on session. The sign on session is established by storing the encrypted access interval key in a memory location of an SSO session map shared by SSO-enabled applications.

Abstract: To extend a sign on session among applications, an inter-application workflow request can be initiated from a first to a second application. The workflow request can identify one or more memory locations in a shared memory for secure data transfer between the applications. The first application can then monitor the memory locations for the presence of a public key stored in shared memory by the second application in response to the workflow request. Once the public key is present in the shared memory, the first application can retrieve and use it to encrypt an access interval key. The encrypted access interval key can then be stored in the shared memory for retrieval by the second application. The access interval key is associated with a sign on session of the first application, and the second application can retrieve and decrypt it to extend the sign on session to the second application.

Abstract: To establish a sign on session among single sign on (SSO)-enabled applications, a user can be prompted by an application for an access code. An access interval key can be generated using a key derivative function based on the access code. The access interval key can be considered a session key, and it can be used during a valid SSO session to decrypt a master key stored in a shared memory. In turn, the master key can be used to encrypt and decrypt the contents of the shared memory. To securely distribute the access interval key among the SSO-enabled applications during a current session, individual SSO-enabled applications can each store a public key in the shared memory. The access interval key can then be encrypted, respectively, by the public keys of the SSO-enabled applications and stored in the shared memory to be retrieved securely by the SSO-enabled applications.

Abstract: Disclosed are examples that relate to monitoring network usage by client devices and enforcing compliance rules related thereto. In various examples, a system can intercept a network call in transit from a client application to an operating system of a client device, wherein the network call is configured to cause a content provider to transmit content to the operating system over a carrier network, and wherein the network call is further configured to cause the operating system to transmit the content to the client application; can modify the configuration of the network call such that the network call causes the operating system to transmit the content to the management component; can receive the content from the operating system; can analyze the content for network usage; can create a network usage analysis; and, can provide the content to the client application.

Abstract: Disclosed are examples of managing access sessions for a computing device. In some examples, a key is generated using a code obtained through a user interface. The key decrypts data stored in a data store of a client device. The key is decrypted using a boot time that represents a latest time the client device was booted. The key is stored in secured storage that is accessible by the at least one application based on a developer certificate.

Abstract: Disclosed are examples of managing access sessions for a computing device. In some examples, a key is generated using a code obtained through a user interface. The key decrypts data stored in a data store of a client device. The key is decrypted using a boot time that represents a latest time the client device was booted. The key is stored in secured storage that is accessible by the at least one application based on a developer certificate.

Abstract: To establish a sign on session among single sign on (SSO)-enabled applications, a user can be prompted by an application for an access code. An access interval key can be generated using a key derivative function based on the access code. The access interval key can be considered a session key, and it can be used during a valid SSO session to decrypt a master key stored in a shared memory. In turn, the master key can be used to encrypt and decrypt the contents of the shared memory. To securely distribute the access interval key among the SSO-enabled applications during a current session, individual SSO-enabled applications can each store a public key in the shared memory. The access interval key can then be encrypted, respectively, by the public keys of the SSO-enabled applications and stored in the shared memory to be retrieved securely by the SSO-enabled applications.

Abstract: To extend a sign on session among applications, an inter-application workflow request can be initiated from a first to a second application. The workflow request can identify one or more memory locations in a shared memory for secure data transfer between the applications. The first application can then monitor the memory locations for the presence of a public key stored in shared memory by the second application in response to the workflow request. Once the public key is present in the shared memory, the first application can retrieve and use it to encrypt an access interval key. The encrypted access interval key can then be stored in the shared memory for retrieval by the second application. The access interval key is associated with a sign on session of the first application, and the second application can retrieve and decrypt it to extend the sign on session to the second application.

Abstract: Disclosed are examples of managing access sessions for a computing device. In some examples, a computing device obtains a key and timeout data from secured storage. The computing device determines whether an access session has expired based on the timeout data. Responsive to determining that the access session has expired, the computing device erases the key from the secured storage.

Abstract: Various examples for application management detection are described. In one example, depending upon whether an installation token includes a unique token value, a client device can determine whether an application is managed or unmanaged. Additionally, the client device can determine whether the application is managed or unmanaged based on whether a keychain installation token includes a unique token value, a value of a keychain installation token, and a value of a launched flag for the application. Using the concepts described herein, an unmanaged application can proceed to execute with limited functionality, present a notification that it should be reinstalled by the management service, stop executing, or take other measures.