Troubleshooting single sign on failure

The automatic troubleshooting of failed single sign on attempts via an identity provider to a service provider. When an error message is encountered due to that failed single sign on attempt, that error message is used to automatically identify a root cause of the failure of the single sign on attempt. In some embodiments, a resolution of the failure is also identified, and a tool for the resolution automatically provided to the user. Such failures in single sign on attempts usually are due to improper configuration information being provided to the identity provider. The principles described herein allow a user to test ahead of time whether they have provided proper configuration information to the identity provider, and potentially correct any problems in the single sign on experience in advance, perhaps well in advance of actually needing a resource provided by the service provider.

BACKGROUND

Many applications (also called “service providers”) are offered over the Internet, often in cloud computing environments. In order to ensure the right services are provided to the right user, it is critical to authenticate the user to verify their identity. Accordingly, service providers often require the user to sign on by providing appropriate credentials. Sometimes, a user would like to sign on to multiple related service providers.

“Single sign on” is a procedure that allows the user to sign onto one of the multiple related service providers, without having to perform a separate sign on for each. An example is when one of the services is an identity provider, and another is a hosting service provider that hosts a resource that the user wants access to. The hosting service provider trusts assertions by the identity provider regarding the identity of users and/or authorizations for those identities.

The user issues a request to access the resource from the hosting service provider. The hosting service provider redirects the user to an identity provider that the hosting service provider trusts. The user then signs on with the identity provider, which provides information (perhaps in the form of a token) that the user then relays back to the hosting service provider. The hosting service provider verifies that the information did indeed originate from the trusted identity provider, and then authenticates the user based on that information. The hosting service provider then decides access control of the resource based on that authentication. In this case, the user really only had a single sign on experience with the identity provider.

When a user sets up a service provider to provide a single sign on experience with a particular identity provider, the user will provide configuration information to the identity provider. This configuration information is used by the identity provider when receiving a sign on request from the user, and to send appropriate information back to the user for relay to the hosting service provider. If there is something wrong with the configuration information, the single sign on experience may fail. That is, the identity provider might respond with an error message. Even if there was no error message, and the identity provider provides the information in the form of a token, the service provider itself may still respond with an error message.

BRIEF SUMMARY

At least some embodiments described herein relate to the automatic troubleshooting of failed single sign on attempts via an identity provider to a service provider. When an error message is encountered due to that failed single sign on attempt, that error message is used to automatically identify a root cause of the failure of the single sign on attempt. In some embodiments, a resolution of the failure is also identified, and a tool for the resolution automatically provided to the user.

Such failures in single sign on attempts usually are due to improper configuration information being provided to the identity provider. The principles described herein allow a user to test ahead of time whether they have provided proper configuration information to the identity provider, and potentially correct any problems in the single sign on experience in advance, perhaps well in advance of actually needing a resource provided by the service provider. Thus, the user can more easily configure the single sign on experience, and reduce errors in single sign on attempts during subsequent requests to the service providers. This enhances the performance of the identity provider and service provider.

The error message may be issued by the identity provider, in which case the sign on attempt stops there. On the other hand, even if the identity provider does not reply with an error message, but returns back information (e.g., in the form of a token), the service provider itself may respond to that information with an error message. For instance, perhaps the service provider cannot properly interpret a token provided by the identity provider. Thus, in accordance with some embodiments herein, the error that is encountered due to that failed single sign on attempt might be provided by the identity provider, or might alternatively be provided by the service provider. The principles described in accordance with those embodiments might resolve either type of error message.

DETAILED DESCRIPTION

At least some embodiments described herein relate to the automatic troubleshooting of failed single sign on attempts via an identity provider to a service provider. When an error message is encountered due to that failed single sign on attempt, that error message is used to automatically identify a root cause of the failure of the single sign on attempt. In some embodiments, a resolution of the failure is also identified, and a tool for the resolution automatically provided to the user.

Such failures in single sign on attempts usually are due to improper configuration information being provided to the identity provider. The principles described herein allow a user to test ahead of time whether they have provided proper configuration information to the identity provider, and potentially correct any problems in the single sign on experience in advance, perhaps well in advance of actually needing a resource provided by the service provider. Thus, the user can more easily configure the single sign on experience, and reduce errors in single sign on attempts during subsequent requests to the service providers. This enhances the performance of the identity provider and service provider as viewed by the end user.

The error message may be issued by the identity provider, in which case the sign on attempt stops there. On the other hand, even if the identity provider does not reply with an error message, but returns back information (e.g., in the form of a token), the service provider itself may respond to that information with an error message. For instance, perhaps the service provider cannot properly interpret a token provided by the identity provider. Thus, in accordance with some embodiments herein, the error that is encountered due to that failed single sign on attempt might be provided by the identity provider, or might alternatively be provided by the service provider. The principles described in accordance with those embodiments might resolve either type of error message.

Because the principles described herein operate in the context of a computing system, a computing system will be described with respect toFIG. 1. Then the use of a computing system to test and troubleshoot a single sign on experience will be described with respect to subsequent figures.

Computing systems are now increasingly taking a wide variety of forms. Computing systems may, for example, be handheld devices, appliances, laptop computers, desktop computers, mainframes, distributed computing systems, datacenters, or even devices that have not conventionally been considered a computing system, such as wearables (e.g., glasses, watches, bands, and so forth). In this description and in the claims, the term “computing system” is defined broadly as including any device or system (or combination thereof) that includes at least one physical and tangible processor, and a physical and tangible memory capable of having thereon computer-executable instructions that may be executed by a processor. The memory may take any form and may depend on the nature and form of the computing system. A computing system may be distributed over a network environment and may include multiple constituent computing systems.

As illustrated inFIG. 1, in its most basic configuration, a computing system100typically includes at least one hardware processing unit102and memory104. The memory104may be physical system memory, which may be volatile, non-volatile, or some combination of the two. The term “memory” may also be used herein to refer to non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well.

The computing system100has thereon multiple structures often referred to as an “executable component”. For instance, the memory104of the computing system100is illustrated as including executable component106. The term “executable component” is the name for a structure that is well understood to one of ordinary skill in the art in the field of computing as being a structure that can be software, hardware, or a combination thereof. For instance, when implemented in software, one of ordinary skill in the art would understand that the structure of an executable component may include software objects, routines, methods that may be executed on the computing system, whether such an executable component exists in the heap of a computing system, or whether the executable component exists on computer-readable storage media.

The term “executable component” is also well understood by one of ordinary skill as including structures that are implemented exclusively or near-exclusively in hardware, such as within a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other specialized circuit. Accordingly, the term “executable component” is a term for a structure that is well understood by those of ordinary skill in the art of computing, whether implemented in software, hardware, or a combination. In this description, the term “component” may also be used. As used in this description and in the case, this term (regardless of whether the term is modified with one or more modifiers) is also intended to be synonymous with the term “executable component” or be specific types of such an “executable component”, and thus also have a structure that is well understood by those of ordinary skill in the art of computing.

In the description that follows, embodiments are described with reference to acts that are performed by one or more computing systems. If such acts are implemented in software, one or more processors (of the associated computing system that performs the act) direct the operation of the computing system in response to having executed computer-executable instructions that constitute an executable component. For example, such computer-executable instructions may be embodied on one or more computer-readable media that form a computer program product. An example of such an operation involves the manipulation of data.

The computer-executable instructions (and the manipulated data) may be stored in the memory104of the computing system100. Computing system100may also contain communication channels108that allow the computing system100to communicate with other computing systems over, for example, network110.

While not all computing systems require a user interface, in some embodiments, the computing system100includes a user interface112for use in interfacing with a user. The user interface112may include output mechanisms112A as well as input mechanisms112B. The principles described herein are not limited to the precise output mechanisms112A or input mechanisms112B as such will depend on the nature of the device. However, output mechanisms112A might include, for instance, speakers, displays, tactile output, holograms, virtual reality, and so forth. Examples of input mechanisms112B might include, for instance, microphones, touchscreens, holograms, virtual reality, cameras, keyboards, mouse of other pointer input, sensors of any type, and so forth.

Those skilled in the art will also appreciate that the invention may be practiced in a cloud computing environment, which is supported by one or more datacenters or portions thereof. Cloud computing environments may be distributed, although this is not required. When distributed, cloud computing environments may be distributed internationally within an organization and/or have components possessed across multiple organizations.

In this description and the following claims, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of “cloud computing” is not limited to any of the other numerous advantages that can be obtained from such a model when properly deployed.

For instance, cloud computing is currently employed in the marketplace so as to offer ubiquitous and convenient on-demand access to the shared pool of configurable computing resources. Furthermore, the shared pool of configurable computing resources can be rapidly provisioned via virtualization and released with low management effort or service provider interaction, and then scaled accordingly.

The principles described herein allow a user to test a single sign on experience and automatically find a root cause of problems if encountered during that single sign on experience, and potentially troubleshoot those problems. Thus, the environment and process of an example single sign on experience will thus now be described with respect toFIG. 2, so that the concept of the single sign on experience may be more fully understood.

FIG. 2illustrates an environment200in which the single sign on experience may occur. The single sign on experience allows a user to be authenticated to multiple service providers by signing onto just one service provider. In the context ofFIG. 2, a user211authenticates to both the identity provider221and the service provider231by signing onto just the identity provider221. That is, the user211signs onto the identity provider221by providing credentials to the identity provider221, which allows the user211to be identified by the service provider231also. The identity provider221and the service provider231may be computer programs that operate on a computing system that operates within the computing system100described above with respect toFIG. 1. Such a computing system100may even be a datacenter.

In a typical example, the user211might first interact with the service provider231to request a service. The term “user” mean at least an application that is capable of issuing requests to service providers. An example of such an application is a browser. Because such browsers typically are operated by a human being, and may be considered an extension of that human being for purposes of interacting with a service provider, the term “user” is appropriate to describe such an application. In this description, the term “user” means an application that interfaces with a service provider, whether or not operating at the direction of a human being or artificial intelligence. Likewise, when the authentication of a user is referred to, that means that the application is being authenticated, or (if the application is being directed by a human being or artificial intelligence) that the authentication of the associated human being or artificial intelligence is being authenticated. Thus, the user211may be an executable component(s) that operates on a computing system, such as the computing system100described above with respect toFIG. 1.

This interaction is represented by the initial service provider interaction201. The user211issue a resource request201A to the service provider231that is hosting the requested resource. If the service provider231has not already authenticated the user211, the service provider231redirects the service provider211to the identity provider221. Specifically, the service provider231instructs the user211to authenticate to the identity provider221via the redirection response201B.

This causes the user211to actually begin the single sign on to the identity provider221. The interaction with the service provider is represented by the identify provider interaction202. This interaction is represented by dashed lines to represent that it is a sign on interaction in which the user211providers credentials to authenticate. Specifically, the user211provides an authentication request202A to the identity provider221. The identity provider221checks configuration information that the user211previously provided to the identity provider221, and dispatches a response202B. If the configuration information does not allow the identity provider221to authenticate the user211, then an error message is returned. If the configuration information does allow the identity provider221to authenticate the user211, then the identity provider221returns a response that includes data that may be interpreted by the service provider231. That included data might be a token that may then be provided to the service provider231.

The user211then engages in interaction203with the service provider231. Specifically, the user211issues another resource request203A to the service provider231, and the service provider231returns an appropriate response203B. This time, the request203A includes the data (e.g., a token) that was returned by the identity provider221in the response202B. If that data is not sufficient for the service provider231to authenticate the user211, then the service provider231return an error message as the response203B. If the data is sufficient is sufficient for the service provider231to authenticate the user211, then the service provider231makes an appropriate determination as to whether that authenticated user is authorized to have the requested access to the resource, and responds as appropriate by granting or denying access to the resource.

FIG. 3illustrates an extended environment300that includes multiple users310, multiple identity providers320, and multiple service providers330. The users310includes three users311,312and313, with the ellipsis314representing that the environment300may including any number of users. The identity providers320include two identity provider321and322, with the ellipsis323representing that the environment300may including any number of identity providers. The service providers330include four service providers331,332,333and334, with the ellipsis335representing that the environment300may include any number of service providers.

As an example, the user311ofFIG. 3may be the user211ofFIG. 2, the identity provider321ofFIG. 3may be the identity provider221ofFIG. 2, and the service provider331ofFIG. 3may be the service provider231ofFIG. 2. Each user may interact with respective identity providers so that the identity providers can provide appropriate identities (e.g., a “token”) for the respective user to a respective service provider, as described above with respect toFIG. 2.

As previously mentioned, in order for an identity provider to properly authenticate the user, the user first provides or sets configuration information that is specific to that user and service provider. For instance,FIG. 4illustrates a two-dimensional array (or table)400of configuration information that might be maintained by the identity provider321. The configuration information need not be organized as a table, but a table is used for purpose ofFIG. 4for purposes of example only, and to demonstrate that configuration information is specific to a combination of a user and a service provider. Furthermore, there may be additional dimensions that may warrant different configuration information. For instance, configuration information may be different by the mode of single sign on. As an example, Security Assertion Markup Language (SAML) is a common mode for single sign on, but there are others. Another example mode is a single password application that requires a single secure password to log into the password service, and then that service will assist in logging in or automatically perform logging into other services thereafter on behalf of the user.

The four columns401A through401D correspond to the four service providers331,332,333, and334. The three rows402ato402ccorresponds to the three users311,312and313. The entry in the corresponding row and column represents the configuration information for the combination of the respective row and column. For instance, configuration403aA, is used when user311requests identification to the service provider331, configuration403aB is used when user311requests identification to the service provider332, configuration403aC is used when user311requests identification to service provider333, and configuration403aD is used when user311requests identification to service provider334. Furthermore, configuration403bA is used when user312requests identification to the service provider331, and configuration403bB is used when user312requests identification to the service provider332. Finally for purposes of this example, configuration403aC is used when user313requests identification to the service provider331.

It is not a trivial task for a user to set up configuration to enable single sign on with a particular identity provider and service provider. Mistakes can easily be made in providing or setting up that configuration information. Accordingly, an error message may often be encountered when a user attempts to perform a single sign on using an identity provider to access a resource hosted by a service provider. The principles provided herein provide significant assistance in testing and troubleshooting such error messages.

FIG. 5illustrates a flowchart of a method500for troubleshooting a single sign on of a user into a service provider using an identity provider in accordance with the principles described herein. The method500is initiated when a user performs a single sign on attempt into a service provider using an identity provider (initiating event501). In one particular example which will be referred to herein as the “sign on example”, the user211ofFIG. 2attempts to gain access to a resource provided by the service provider231by signing onto the identity provider221. Recall that user311, identity provider321, and the service provider331ofFIG. 3may be the user211, the identity provider221, and the service provider231, respectively, ofFIG. 2. Accordingly, the sign on example also involvesFIG. 3in which the user311attempts to gain access to a resource provided by the service provider331by signing onto the identity provider321. InFIG. 4, the configuration information that is used by the identity provider321to provide an identity for the user311to the service provider331is the configuration403aA in column401A and row402a.Thus, the success or failure of the single sign on attempt in the sign on example will depend on whether the configuration403aA is correct.

Ideally, the sign on attempt in the sign on example would be successful. However, in order to illustrate the principles described herein, assume that in the sign on example that an error message is encountered. Accordingly, the method500includes accessing an error message (act510). In the most direct embodiment, the error message is accessed as a response from the identity provider (e.g., in response202B from identity provider221). This means that the identity provider (e.g., identity provider221or321in the sign on example) was not able to authenticate the user (e.g., user211or311in the sign on example) using the configuration information (e.g., configuration403aA in the sign on example). In a secondary embodiment, the identity provider (identity provider221or321in the sign on example) was able to identify the user (e.g., user211or311in the sign on example) to the service provider (e.g., service provider231or331in the sign on example) using the configuration information (e.g., configuration403aA in the sign on example), but that service provider could still not interpret that identity using the data (e.g., a token) provided by the identity provider. This still indicates that the configuration (e.g., configuration403aA in the sign on example) is not correct.

In any case, the method500includes automatically identifying from at least the error message what a root cause (act520) of a failure of the single sign on attempt is. Referring toFIG. 6, this be accomplished using a decision tree environment600in which decision tree input data601is fed to an input tree610to generate possible decision tree output data620. The decision tree610in this case is a directed acyclic graph. Each node in the decision tree represents a decision to be made, which decision will depend on the data provided to it. Depending on result of the decision, navigation is made along one of the output directed edges from the node to the next node, and appropriate data is provided also along that directed edge.

For instance, in this case, the input data601includes the error message601A as well as the request (e.g., the request202A to the identity provider in the sign on example). The root node614of the decision tree600receives all of this input data and makes a determination of which directed edge641or642to direct the input data to, and which portions of the input data601(if less than all) to direct along that directed edge. If appropriate, the root node614could also perform some transform of the input data. Suppose that the navigation proceeds along edge642to node613. Node613is a leaf node in the decision tree610, and corresponds to particular output623, which indicates that the root cause of the error message is root cause C. In addition, data633helpful for expressing the root cause C is also extracted. For instance, the root cause might be that the user identity was expressed as “UserA@domain1.com” whereas the user identity should have been expressed as “UserA@domain1.net”. In that case, the information “UserA@domain1.com” would be extracted from the request.

Suppose instead that navigation proceeds along edge641to node615. The node615receives data along directed edge641, and decides which directed edge643or644to select, and what data to transmit along that directed edge. If navigation proceeds along edge643to leaf node611, the corresponding output is output621, which is that the root cause is root cause A, along with extracted data631. On the other hand, if navigation proceeds along edge644to leaf node612, the corresponding output is output622, which is that the root cause is root cause B, along with extracted data632.

The decision tree610has been kept quite simple in order not to unduly convolute and complicate this description. However, the principles described herein may involve any decision tree of any complexity. In essence, the decision tree mimics the decisions of what a trained technologist would follow if encountering an error message that he/she is fully capable of interpreting. The input data at each node would represent all of the possible relevant information that such a technologist would consider as potentially relevant. The number of root causes might be quite high also. However, the root cause is expressed in a manner that is much more intuitive to a non-trained individual. For example, “you put the wrong user identifier into the identifier field” might be a root cause that is relatively understandable, whereas the raw error message might be far less interpretable. The decision tree610may be constructed manually be a trained technologist610. Alternatively or in addition, the decision tree610may be formulated, grown, pruned, edited, and so forth, using machine learning or artificial intelligence.

The ellipsis601C represents that the set of input data601is not restricted to the shown input data601. Other data might be useful for identifying a root cause. For instance, all or portions of the configuration itself (e.g., configuration403aA in the sign on example) could be input. Also, in case the error message is from the service provider (e.g., service provider231or331in the sign on example, that service provider request (e.g., request203A in the sign on example) may also be provided.

The method500may be performed multiple times to test out different configuration, whether for the same user or a different user, for the same identity provider or for a different identity provider, and/or whether for the same service provider or a different service provider.

FIG. 7illustrates a testing and troubleshooting tool environment700that may be used to help a user to test and troubleshoot problems when encountering errors performing single sign on. The environment700includes a user interface710that may be used to present testing and troubleshooting information to a human being or artificial intelligence, as well as receiving input from that human being or artificial intelligence. The user interface710may be, for instance, an example of the user interface112ofFIG. 1.

The user interface710includes a configuration population component711which a user may interface with to enter, edit, or remove configuration information (e.g., configuration403aA in the sign on example) into the identity provider (e.g. the identity provider221or321in the sign on example). The user interface710also includes a test control712that the user may trigger to initiate the single sign on attempt using the configuration information. The test control712allows the user to immediately and conveniently test whether the configuration information the user has just entered will lead to success or failure. This initiation of the single sign on attempt is represented by the arrow701. At this point, the user may be directed to a sign on page associated with the identity provider.

If the single sign on attempt results in an error message (as represented by arrow702), that error message702may be reported through the user interface710to the user. But rather than having to interpret the error message702directly, the error message702may be fed (either by a manual copy and paste operation of the user, or automatically via an error message population component713) to a root cause determination component714. This represents the act510ofFIG. 5). The root cause determination component714then determines the root cause behind the error message (act520ofFIG. 5), and potentially displays that root cause to the user. As described above, the identification of the root cause may be performed using a decision tree.

The environment700may also include a resolution determination component715determines a resolution of the identified root cause of the failure of the single sign on attempt. The resolution may follow deterministically once the root cause of the error message is identified. In one embodiment, the resolution identification is also included within the decision tree output data. For instance, the output621associated with one root cause may include identifications for one or more resolutions to address that root cause, or maybe even an executable that when triggered would perform the resolution. Also, a resolution tool716may be provided that the user may use to execute the determined resolution. Such might be offered to the user via the user interface710. In response to user interaction with the resolution tool716, the environment700executes the determined resolution.

The components711through716may be structured as described above for the executable component106of the computing system100ofFIG. 1. Furthermore, if the user interface710is provided by a browser, all or some of the components711through716may be offered by a browser extension. For instance, the error message population component713may be part of that browser extension relieving the user from having to manually interact with the user interface710in order to provide the error message to the root cause determination module. Furthermore, the root cause determination component714, the resolution determination component715, and the resolution tool716may be a component of that browser extension, may be a component running below the user interface710, or may have parts that are within the user interface710.

The principles described herein allow a user to test ahead of time whether they have provided or set proper configuration information to the identity provider, and potentially correct any problems in the single sign on experience in advance, perhaps well in advance of actually needing a resource provided by the service provider. Thus, the user can more easily configure the single sign on experience, and reduce errors in single sign on attempts during subsequent requests to the service providers. This enhances the performance of the identity provider and service provider as viewed by the end user. Furthermore, the user may be guided through resolution of the root case, or perhaps the resolution may be substantially automated through user interaction with a resolution tool.