Patent ID: 12199971

DETAILED DESCRIPTION

The present disclosure relates to transferring identifying information of a client device to an identity provider. The identity provider can receive an authentication request from a client device, possibly including an authentication credential. As an example, a software application executed on the client device may request authentication from the identity provider including a username and password. The identity provider can request that the client negotiate a ticket with a key distribution center. Once a ticket is received from the client device, the identity provider can extract an identifier from the ticket. The identity provider can query a management service using the device identifier to determine whether the client device satisfies compliance rules prior to authenticating the user.

With reference toFIG.1, shown is a networked environment100according to various examples. The networked environment100includes an identity provider server103, a management server106, a key distribution server109, a client device112, and a certificate authority115, each of which is communicably coupled through a network121.

The identity provider server103can include a data store124and an identity provider service127. The data store124can store user accounts130that include identifiers133and session data136. The identity provider service127can execute add-on software modules to add additional functionality. As an example, the identity provider service127can execute a key distribution module139, a device compliance module142, a ticket module145, an authentication module148, and other add-on modules.

The management server106can include a data store151with a list of managed devices157, each of which includes a corresponding identifier160. The data store151can also include one or more compliance rules161.

The management service154can manage and oversee the operation of one or more client devices112. The management service154can manage access to resources for a user account from various client devices112. That is, the management service154can determine whether a user, a device, or a pairing of a user and a device are authorized to access resources based on access rights. In one example, access rights are compliance rules161that can be determined at the time of the access request.

The management service154can facilitate enrollment of a client device112on behalf of a user account. In one example, an employer can operate the management service154to ensure that the client devices112of its employees operate in compliance with the security policies. In another example, an employer can configure the management service154to enforce different policies (or no policies at all) based upon which users or employees are currently logged into or otherwise operating the client device112. The management service154can also facilitate access to email, calendar data, contact information, and other resources accessible on the client device112.

The managed devices157portion of the data store151can include information regarding the client devices112that are managed and controlled by the management service154. A managed device157entry in the data store151can correspond to a particular client device112and include, for example, an identifier160for the client device112, the identification of a user assigned to the client device112, whether a management component179is installed on the client device112, an identification of applications that are installed in the client device112, historical data regarding the operation of the client device112, a list of profiles installed on the client device112, an indicia of enrollment on the client device112, geographic locations and time periods that the client device112is configured to be operable, and other information.

In addition, the managed device157entry for a particular client device112can include one or more device profiles. A device profile can include settings embodied in a file. When a device profile is installed on a client device112, the client device112can force functions or applications executed on the client device112to adhere to the settings embodied in the file. The managed device157entry can also include a set of compliance rules161that can be specified by the management service154. The management service154can assign various compliance rules161to a client device112, a user account associated with the client device112, or to a pairing of the client device112and the user account associated with the client device112.

The compliance rules161can specify conditions that must be satisfied for a client device112to be deemed compliant with the compliance rule161. In one example, a compliance rule161can specify that particular applications are prohibited from being installed on a client device112. In another example, a compliance rule161can specify that a lock screen is required to be generated when the client device112is “awoken” from a low power (e.g., “sleep”) state and that a passcode is required for a user to unlock the lock screen. In yet another example, the compliance rule can specify that the operating system not be modified, such as being rooted or jail broken.

Additionally, some compliance rules161can be based on time, hardware configuration, software configuration, geographical location, network properties, or other predefined conditions.

When the compliance rules161for a particular device profile are satisfied, the management service154can determine that the corresponding client device112is compliant with the device policy. According to one example, a client device112can fail to satisfy a compliance rule161if an agent is not installed on the client device112, and access to resources through the client device can be prohibited until the agent is installed and the compliance rule161is satisfied. In yet another example, the client device112can satisfy a compliance rule161when a client device112is located within a particular geographic location. In one example, a client device112can satisfy a compliance rule161when the client device112is in communication with a particular network121, such as a particular local area network that is managed by the management service154. Furthermore, a compliance rule161in another example can be satisfied upon the time and date matching specified values.

Another example of a compliance rule161can involve determining whether a user belongs to a particular group of authorized users. A compliance rule161can include a whitelist or a blacklist that specifies whether particular users or groups of users are authorized users. In various examples, the management service154, the client device112, or a combination of both the management service154and the client device112can determine whether a client device112satisfies a compliance rule161.

As yet another example, a compliance rule161can involve detecting whether an unauthorized application is installed on the client device112, determining whether an agent, container, application profile, or device management profile has been removed from the client device112, determining whether the certificate has expired, or determining whether the client device112is located within a geo-fence. If a client device fails to satisfy a compliance rule161, a remedial action can be taken.

In some cases, network resources can be accessed by the computing device112only if certain compliance rules161are met for the user account130, the computing device112, the network121, other device or network operating factors, or some combination thereof. For example, the compliance rules161can include various compliance rules associated with individual users, groups of users, devices, groups of devices, communications networks, and other factors. The management service154can permit or deny access to one or more resources depending upon who is seeking to access the resources, what client devices112are used to seek access to the resources, and over what networks the client devices112are seeking to access to the resources, among other compliance rules161. As other examples, the compliance rules161can include rules associated with the operating parameters or operating conditions of the client device112, among others. The management service154can permit or deny access to one or more resources depending upon the operating status of the client device112. In that sense, the client device112incorporates additional aspects of compliance-only access to the resources.

The compliance rules161include certain profile, credential, compliance, and other parameters or rules associated with access to resources. The compliance rules161can define requirements for users of the client device112, requirements of client device112, requirements of the network121, and other device or network operational requirements of factors. For example, the compliance rules161can define whether or not a certain class or category of users, certain client devices112, or certain networks can be used to access one or more resources. The management service154can refer to the compliance rules161to determine when and how to perform content access control and authentication procedures.

The compliance rules161can also define the enforcement of certain remedial actions in the event that the management service154blocks access to any of the resources or the user account130fails the authorization process. Remedial actions can be taken under various circumstances based on the compliance rules161, such as when an operating system of the client device112is jailbroken (e.g., rooted or modified), when an unauthorized application, such as a blacklisted application or an application known to include malware, is detected on the client device112, when one or more mobile device management profiles or agents have been removed from the client device112, when an application or service profile is removed from the client device112, when user identity verification or credentials fail to meet compliance rules, or when the client device112is not compliant with certain geographical or location-based requirements, among other situations.

In some examples, a company can operate the management service154to ensure that the client devices112of its users satisfy respective compliance rules161. By ensuring that the client devices112of its users are operating in compliance with the compliance rules161, the company can control access to resources to thereby improve the security of client devices112associated with the company and the users of the client devices112.

The key distribution server109can execute a key distribution service166. The key distribution service166can be, for example, a Kerberos Key Distribution Center (KDC). The key distribution service166can supply a ticket, such as session tickets and temporary session keys, to client devices112and user accounts130. A management component179executed on the client device112can send a certificate to the key distribution service166to authenticate the client device112. The key distribution service166can verify the certificate is valid and issue a ticket to the management component179. To verify the certificate is valid, the key distribution service166can determine that the certificate is signed by the certificate authority115. The key distribution service166can also ensure data within the certificate is valid. As an example, the key distribution service166can determine whether the certificate has expired based on a time range specified in the certificate.

The key distribution service166can extract an identifier from the certificate. The management server106can use the certificate authority115to generate a certificate that includes the identifier160that corresponds to a client device. The key distribution service166can extract this identifier from the certificate. In one example, the ticket module145extracts the identifier from the ticket. The ticket module145can pass the identifier and username to the authentication module148. The identifier can be embedded within the certificate as a property. As an example, the identifier can be stored in a Domain Name Server Subject Alternate Name field in the certificate. As such, if the value of the identifier is maliciously changed, the digital signature from the certificate authority115will not match and the key distribution service166will reject the certificate. When generating the ticket for the client device112, the key distribution service166can embed the identifier into the ticket. The key distribution service166can send the generated ticket including the identifier to the management component179when the certificate is valid.

In one example, a key distribution service166can be executed for each domain controller. For example, the key distribution service166can be part of an Active Directory Domain Services (AD DS). In another example, the key distribution service166can be a cloud-based service. In this example, a single key distribution service166can be associated with multiple domain controllers simultaneously.

The client device112can include a data store175, a client application178, and a management component179. The data store175can include a certificate181corresponding to the client device112. The management component179can locally manage the client device112and facilitate remote management by the management service154. The client application178can include third party applications such as productivity applications, messaging applications or other applications. The client application178can read and write to the data store175. The client device112can receive a certificate from the management service154. The management component179can store the certificate as certificate181in the data store175.

According to one example, the management service154and management component179can restrict the client application178from accessing some or all of the data store175if the client device fails to comply with a compliance rule161. The management component179can act as an agent on the client device112for the management service154. In one example, the client application178is still able to read the certificate181when failing to comply with a compliance rule161. The client application178can query the management service154or management component179to determine permissions for the user account. As an example, the management component179or management service154can determine that a user account is not authorized if a compliance rule161corresponding to the client device112is not satisfied.

The certificate authority115can include a data store187and a certificate authority service190. The data store187can include client keys193and certificate authority keys196. The certificate authority keys196can include a private key and a public key. The certificate authority service190can share the pubic key with other network devices, such as the identity provider server103, management server106, the key distribution server109, and one or more client devices112. The certificate authority service190can store the private key securely in the data store187without sharing the private key. The certificate authority service190can receive a request to generate a certificate from the management service154. In one example, the certificate authority115is connected to a private network accessible by management service154. In this example, the certificate authority service190can rely on the physical security of the private network to ensure only authorized services can generate certificates.

When a request is received to generate a certificate, the certificate authority service190can generate a certificate based on data contained in the request. As an example, the request to generate a certificate can include the identifier160corresponding to the client device112for which the certificate is being generated. The request can also include a duration for which the certificate will be valid, descriptive text indicating a purpose for the certificate, identifying information for the issuer of the certificate, identifying information for the intended client device112of the certificate, and other information. The identifying information for the intended client device112can include an internet protocol (IP) address of the client device112. The certificate authority115can store the generated certificate in client keys193. Alternatively in some examples, the client keys193are not stored in the data store187.

The management service154can generate a certificate for a client device112that includes an identifier160corresponding to the client device112. The management service154can issue a signed certificate to any of the managed devices157. The management service154can send the certificate to the client device112to be stored in the data store175as a certificate181. As an example, management service154can send a message to the certificate authority service190instructing the certificate authority service190to generate a certificate, such as a client key193, for a specific client device112. The client key193can include a private key and a public key. The certificate authority service190can sign the client key193with a certificate authority key196to create a certificate. In one example, the certificate authority service190uses a private key from the certificate authority key196to generate a certificate by signing the public key of the client key193.

The management component179can send an authentication request to the identity provider service127. The authentication request can include authorization credentials, such as, for example, a username and password. The authentication request can also include biometric information, such as fingerprint data, retinal data, or other biometric information. The authentication module148can extract the authentication credentials from the authentication request and forward the request to the key distribution module139.

The identity provider service127can send a request to the management component179to send the certificate181to the key distribution service166. As an example, the identity provider service127can send an HTTP 401 Authorization Required command to the management component179. The command can specify a scheme used to authenticate, including a network address of the key distribution service166. For example, the command can specify that a certificate should be sent to the key distribution service166in order to obtain a ticket. The command can be sent by the key distribution module139. In one example, the request sent is a redirect command. In response receiving the request, the management component179can send the certificate181to the key distribution service166. The management component179can send a certificate including an identifier to the key distribution service166.

The key distribution service166can extract the identifier from the certificate181. The key distribution service166can generate a ticket that includes the identifier and send the ticket to the management component179. The management component179can send the ticket to the identity provider service127, and the identity provider service127can extract the identifier from the ticket.

The identity provider service127can determine whether the authentication credentials received from the client device112authenticate against a user account130in the data store124. As an example, the identity provider service127can execute a hashing algorithm on the user supplied password. The identity provider service127can search the data store124for a user name corresponding to a user account130. The identity provider service127can compare a stored hashed password to the hashed password provided in order to authenticate the user account. Further, the identity provider service127can determine whether the client device112complies with compliance rules161using the extracted identifier. The identity provider service127can authenticate one or more client applications178for access to the user account130if the authentication credentials match a user account130and the client device112complies with the compliance rules161.

To determine whether the client device112complies with the compliance rules161, the identity provider service127can query the management service154. The device compliance module can send the query to the management service154. In one example, the identity provider service127sends a network request to a representational state transfer application programming interface (REST API) of the management service154. The request can be sent by the device compliance module142. The network request can include the identifier that was extracted from the ticket. Communications over the network121between the management service154and the identity provider service127can be encrypted. The management service154and identity provider service127can share a key and a certificate. The identity provider service127can include the certificate in the network request to the REST API. The management service154can validate the certificate using the shared key prior to responding to the network request with a status of whether the client device112complies with compliance rules161.

The identity provider service127can cache the identifier and session data in a data store124associated with the user account130as identifiers133and session data136. The session data136can include a most recent status of whether the client device112complies with compliance rules161. The identity provider service127can poll the management service154for an updated status of whether the client device112complies with the compliance rule161. The poll can be periodically sent by the identity provider service127. The identity provider service127can also query for the status upon receipt of a request to authenticate through the identity provider service103. The management service154can determine whether the client device112complies with the compliance rules and send the result to the identity provider service127. The identity provider service127can update the session data in the data store with the updated status. The network environment100can also include one or more service providers206, as shown inFIG.2.

With reference toFIG.2, shown is an example of the networked environment100baccording to various examples. The networked environment100bincludes computing environment203, a service provider206, and one or more client devices112. Shown in the networked environment100b, the identity provider service127, the management service154, the key distribution service166, and certificate authority service190fromFIG.1are executed in a single computing environment203. The computing environment203also includes a data store209that stores the user accounts130and a data store210that stores the managed devices157, the client keys193, and the certificate authority keys196. In one example, the data store209stores the client keys193and certificate authority keys196.

The identity provider service127can receive a log in request including a user account from a service application212, such as, for example, a single sign on (SSO) request. The identity provider service127can generate a token, such as an SSO token, that includes a current status of whether the client device112complies with compliance rules161. The determination can be based on session data136in either data store124or data store209. As an example, the identity provider service127can query the data store124or209using the user account from the log in request to determine a stored status in the session data136. The identity provider service127can send the token to the service provider206to authenticate the user account130. In one example, the status put into a security assertion markup language (SAML) attribute field of a SSO token. In another example, the status is stored as an OAuth2 token attribute. In yet another example, the status is stored as an OpenID Connect token attribute.

Referring next toFIG.3, shown is a flowchart that provides one example of the operation of a portion of the identity provider service127. As an alternative, the flowchart ofFIG.3can be viewed as depicting an example of elements of a method implemented in the identity provider server103or the computing environment203.FIG.3illustrates an example of how the identity provider service127can ensure a client device112complies with compliance rules161when authenticating a user account130for use by one or more client applications178on the client device112.

At step303, the identity provider service127can receive an authentication request from a management component179executed on a client device112. The authentication request can include an authentication credential. For example, a user of the client device112can enter a username and password on a user interface on the client device112. The username and password can be sent to the identity provider service127as part of the authentication request. The authentication module148can extract the authentication credentials from the authentication request and forward the request to the key distribution module139.

At step306, the identity provider service127can send instructions to the management component179to negotiate a ticket with a key distribution service166. As an example, the identity provider service127can send an HTTP 401 Authorization Required command to the management component179. The command can specify a scheme used to authenticate include a network address of the key distribution service166. For example, the command can specify that a certificate should be sent to the key distribution service166in order to obtain a ticket. The command can be sent by the key distribution module139.

At step309, the identity provider service127can receive a ticket from the management component179. The management component179can receive a ticket from the key distribution service166. The management component179can send the ticket to the identity provider service127. The identity provider service127can extract an identifier from the ticket. In one example, the ticket module145extracts the identifier from the ticket. The ticket module145can pass the identifier and username to the authentication module148.

At step312, the identity provider service127can determine whether authentication credentials provided by a management component179match against a user account130. In one example, the authentication credentials are a username and password. The identity provider service127can search the user accounts130for the username and validate the password against the user account130. The identity provider service127can evaluate an access policy for the user account130to determine whether the client device112is authorized for access. If the authentication credentials match, the identity provider service127proceeds to step315. If the authentication credentials fail to match, the identity provider service127proceeds to step321.

According to one example, when the number of times a user account130fails meets a threshold, the identity provider service127or the management service154can lock the client device112. As an example, the client device112can require that a user enters a passcode before being able to use the client device112. The identity provider service127or the management service154can block the client device112from accessing local or remote services, uninstall profiles from the client device112, delete or wipe all data from the client device112, un-enroll the client device112from the management service154, delete an agent from the client device112, or perform another remedial action.

At step315, the identity provider service127determines whether the client device112is in compliance with compliance rules161. The identity provider service127can send a request to the management service154to determine whether the client device112complies with the compliance rules161. The request can include the identifier extracted from ticket. The identity provider service127can send the request to a REST API of the management service154. The request can be sent by the device compliance module142. The management service154can send the status of whether the client device112complies with the compliance rules161in response to the request from the identity provider service127. If the identity provider service127determines that the client device112complies with the one or more compliance rule161, the identity provider service127proceeds to step318. Otherwise, the identity provider service127proceeds to step321.

At step318, the identity provider service127authenticates the client device112. As an example, the identity provider service127can send an authentication confirmation message to the management component179. The identity provider service127can authorize the client device112to access the user account130.

At step321, the identity provider service127denies authorization for the client device112. The identity provider service127can send a message denying access to the user account130to the management component179. In one example, the identity provider service127can block further communication with the client application178or the management component179. The communication can be blocked when a number of authentication attempts meets a predefined threshold. Thereafter, the process proceeds to completion.

Referring next toFIG.4, shown is a flowchart that provides one example of the operation of a portion of the identity provider service127. As an alternative, the flowchart ofFIG.4can be viewed as depicting an example of elements of a method implemented in the identity provider server103or the computing environment203.FIG.4illustrates an example of how the identity provider service127can ensure a client device112complies with compliance rules161when authenticating a user account130for a service provider206.

At step403, the identity provider service127can store an identifier133and session data136associated with a user account130in a data store124or209. The identity provider service127can cache the status of whether a client device112complies with compliance rules161in session data136. The identifier for the client device112can also be stored in identifier133.

At step406, the identity provider service127can poll the management service154. The identity provider service127can iterate through each of the user accounts130. For each user account130that has a corresponding identifier133, the identity provider service127polls the management service154using the identifier for a status of the respective client device. As an example, the identity provider service127can determine whether the client device112complies with compliance rules161, as discussed in step315.

In other examples, the management service154can push the status of one or more client device112to the identity provider service127. As an example, the identity provider service127can receive a push notification of a status change. When the management service154detects a change in the status of a client device112, the management service154can send a push notification to the identity provider service127.

At step409, the identity provider service127can update the session data136with a status of whether a client device112complies with compliance rules161. In one example, the status stored in session data136can be replaced with the updated status determined in step406. In another example, the session data136includes a history of past statuses. The identity provider service127can append the updated status to the history of past statuses. In one example, the identity provider service127only appends the updated status when the updated status is different than the last stored status in the session data136. The session data136can include a timestamp of the last poll for each of the user accounts130.

At step412, the identity provider service127can receive a single sign-on request from a service provider206. A service provider206can submit a request to authenticate a user account to the identity provider service127. The request can be a single sign-on request. The request can include a username for a user account130. If the request is received, the identity provider service127proceeds to step415. Otherwise, the identity provider service127can proceed to step406.

At step415, the identity provider service127can send the current status of the client device112to the service provider206. The identity provider service127can look up the status in the session data136for the user account130being authenticated. The identity provider service127can embed the status in an authentication token. The identity provider service127can send the authentication token to the service provider206including the status of whether the client device112complies with the compliance rules161. Thereafter, the process proceeds to completion.

According to one example, if a client device112uses an unsecure communication channel for a service that requires a secure communication channel, the status can indicate that the client device112fails to satisfy a compliance rule161that requires the secure communication channel. In addition, the identity provider service127can send a notification to the client device112to inform the user of the non-compliance. The identity provider service127or the management service154can also lock the client device112, block local or remote services on the client device112, wipe the client device112, or perform another remedial action.

Referring next toFIG.5, shown is a flowchart that provides one example of the operation of a portion of the management service154. As an alternative, the flowchart ofFIG.5can be viewed as depicting an example of elements of a method implemented in the management server106or the computing environment203.FIG.5illustrates an example of how the management service154provides a client device112with a certificate including an identifier while enrolling the client device112.

At step503, the management service154can receive an enrollment request from a management component179executed on a client device112. In one example, when a user signs onto a new client device112for a first time, the management component179can send an enrollment request to the management service154.

At step506, the management service154can determine an identifier for the client device. While enrolling the client device112, the management service154can generate the identifier. The identifier can be generated to be unique relative to other identifiers for other client devices112. The management service154can generate a new entry for a managed device157for the new client device112including the generated identifier as identifier160.

At step509, the management service154can generate a private key and a certificate for a client device112. The certificate can include the identifier. The management service154can send a request to the certificate authority service190to generate the private key and the certificate for the client device112. The request can include the identifier. The certificate authority service190can generate a public key including the identifier and a private key for the client device112. The certificate authority service190can sign the public key with the certificate authority key196to generate the certificate.

At step512, the management service154can send the private key and the certificate to the client device112. The management service154can encrypt and transmit the private key and certificate to the client device112. In one example, the management service154manages a secured storage system located on the client device112. The management service154can place the private key and the certificate in a secured storage location of the secured storage system. In another example, the management service154uses secure certificate enrollment protocol (SCEP) to move the private key and certificate to the client device112.

At step515, the management service154can receive a request to verify compliance of the client device112. The management service154can provide a REST API for the identity provider service127to submit requests for client device112compliance.

At step518, the management service154can determine whether the client device112is compliant. In one example, management service154sends a request the management component179to determine whether the client device112complies with the compliance rules161. The management service154can send the result of whether the client device112is compliant to the identity provider service127. Thereafter, the process proceeds to completion.

Referring next toFIG.6, shown is a flowchart that provides one example of the operation of a portion of the client application178and management component179. As an alternative, the flowchart ofFIG.6can be viewed as depicting an example of elements of a method implemented in the client device112.FIG.6illustrates an example of how the client application178and management component179can send an identifier corresponding to the client device112when authenticating the client device112.

At step603, the management component179can send an enrollment request to the management service154. The client device112can be preloaded with the management component179. The management component179can be a trusted application executed on the client device112. In one example, when a user logs into the client device112for the first time, the management component179can send an enrollment request to the management service154. If the client device112does not have a connection to network121, the management component179can send the request when a connection is established to the network121or the next time a user attempts to login to the client device112while connected to the network121.

At step606, the management component179can receive a certificate from the management service154. The management component179can access a secured storage location on the client device112. The management component179can communicate with the management service154to transfer files to the secured storage location. The management component179can receive the certificate from the management service154and store the certificate in the secured storage location as certificate181.

At step609, the management component179can initiate authentication with the identity provider service127. A user can attempt to log in to the client device112with authentication credentials. The management component179can send the authentication credentials to the identity provider service127for validation.

At step612, the management component179can receive instructions to negotiate a ticket. The management component179can receive a response from the identity provider service127requesting the management component179to negotiate with a key distribution service166for a ticket.

At step615, the management component179can send the certificate181to the key distribution service166. If the certificate181is validated by the key distribution service166, the key distribution service166can send a ticket including the identifier to the management component179. The key distribution service166can use a public key associated with the certificate authority115to determine whether the certificate181from the management component179is a valid certificate. If the certificate181provided by the management component179is valid, the key distribution service166can send the ticket to the management component179in response to the request from the management component179.

At step618, the management component179can send the ticket to the identity provider service127. After the management component179receives the ticket from the key distribution service166, the management component179can use the ticket to authenticate with the identity provider service127. The management component179can send the ticket to the identity provider service127for authentication. The identity provider service127can use the ticket to determine an identifier for the client device112by extracting the identifier from the ticket. The management component179can wait for a response from the identity provider service127regarding whether the management component179is authenticated.

At step621, the management component179can complete authentication. As an example, the management component179can receive a confirmation of authentication from the identity provider service127. Once authenticated, one or more client applications178can access network resources based on permissions of the authenticated user account and compliance rules161associated with the client device112. The management component179can restrict access to a network resource by a client application178if the management component179determines the client device112fails to comply with a compliance rule161. Thereafter, the process proceeds to completion.

The flowcharts ofFIGS.3-6show examples of the functionality and operation of implementations of components described herein. The components described herein can be embodied in hardware, software, or a combination of hardware and software. If embodied in software, each element can represent a module of code or a portion of code that includes program instructions to implement the specified logical function(s). The program instructions can be embodied in the form of source code that includes human-readable statements written in a programming language or machine code that includes machine instructions recognizable by a suitable execution system, such as a processor in a computer system or other system. If embodied in hardware, each element can represent a circuit or a number of interconnected circuits that implement the specified logical function(s).

Although the flowcharts ofFIGS.3-6show a specific order of execution, it is understood that the order of execution can differ from that which is shown. The order of execution of two or more elements can be switched relative to the order shown. Also, two or more elements shown in succession can be executed concurrently or with partial concurrence. Further, in some examples, one or more of the elements shown in the flowcharts can be skipped or omitted. In addition, any number of counters, state variables, warning semaphores, or messages could be added to the logical flow described herein, for purposes of enhanced utility, accounting, performance measurement, or troubleshooting aid. It is understood that all of these variations are within the scope of the present disclosure.

The identity provider server103, the management server106, the key distribution server109, the client devices112, the certificate authority115, the computing environment203, or other components described herein, can each include at least one processing circuit. The processing circuit can include one or more processors and one or more storage devices that are coupled to a local interface. The local interface can include a data bus with an accompanying address/control bus or any other suitable bus structure. The one or more storage devices for a processing circuit can store data or components that are executable by the one or processors of the processing circuit. Also, a data store can be stored in the one or more storage devices.

The identity provider service127, the management service154, the key distribution service166, the client application178, the management component179, the certificate authority service190, the service application212, and other components described herein can be embodied in the form of hardware, as software components that are executable by hardware, or as a combination of software and hardware. If embodied as hardware, the components described herein can be implemented as a circuit or state machine that employs any suitable hardware technology. The hardware technology can include one or more microprocessors, discrete logic circuits having logic gates for implementing various logic functions upon an application of one or more data signals, application specific integrated circuits (ASICs) having appropriate logic gates, programmable logic devices (e.g., field-programmable gate array (FPGAs), and complex programmable logic devices (CPLDs)).

Also, one or more or more of the components described herein that includes software or program instructions can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as a processor in a computer system or other system. The computer-readable medium can contain, store, or maintain the software or program instructions for use by or in connection with the instruction execution system.

The computer-readable medium can include physical media, such as, magnetic, optical, semiconductor, or other suitable media. Examples of a suitable computer-readable media include, but are not limited to, solid-state drives, magnetic drives, flash memory. Further, any logic or component described herein can be implemented and structured in a variety of ways. One or more components described can be implemented as modules or components of a single application. Further, one or more components described herein can be executed in one computing device or by using multiple computing devices.

It is emphasized that the above-described examples of the present disclosure are merely examples of implementations to set forth for a clear understanding of the principles of the disclosure. Many variations and modifications can be made to the above-described examples without departing substantially from the spirit and principles of the disclosure. All of these modifications and variations are intended to be included herein within the scope of this disclosure.