Patent Description:
A computer network may include multiple resources that are shared among several users potentially wanting to access the resources. In order to ensure a given user does not abuse a resource, a user may be authenticated before being given access to a resource. In some instances, a given resource may handle the authentication locally-e.g., by asking for authentication information and comparing it against locally stored authentication for authorized users. In other instances, a computer network may rely on a trusted centralized authority to maintain authentication information and authenticate users. A centralized authority can be advantageous as it may be easier to maintain and afford greater protection of user authentication information. Examples of authentication schemes that use a central authority include Kerberos, remote authentication dial-in user service (RADIUS), etc.
<CIT> describes an authorization process, wherein an application requests access to a resource server. This request is passed to a token agent of the computing device on which the application is running, which in turn requests an application specific token from an authentication service. This application specific token is then passed from the token agent to the requesting application, which in turn uses it to obtain the requested resource. In case the user is not authorized to access the requested resource with the current credentials, the authentication service initiates a step-up authentication, which involves a user dialog with the token agent through a user interface in order to obtain credentials associated with additional authentication requirements. <CIT> discloses a process of accessing a resource, wherein a request for a resource is passed on to an intermediate agent, which interacts with an authorization component, which, other than allowing or refusing the request, may cause the intermediate component to provide additional credentials. In this case the intermediate component acquires additional login credentials from the user and passes these on to an authentication component. An exception is thrown by an application authorization service, if the session credentials do not indicate that the requesting entity is sufficiently authorized. <CIT> describes a system and method for automatic porting of software applications into a cloud computing environment. When a user application is deployed to the environment, a deployment logic determines those aspects of the application, such as certain service usages, that may be incompatible with features provided by the environment, or that should use a particular cloud service, and automatically ports the application, including the use of one or more handlers or extensions, for use within the environment by replacing part of the original code of the user application by replacement code that is compatible with the cloud computing environment.

This disclosure includes references to "one embodiment" or "an embodiment. " The appearances of the phrases "in one embodiment" or "in an embodiment" do not necessarily refer to the same embodiment. Particular features, structures, or characteristics may be combined in any suitable manner consistent with this disclosure.

Within this disclosure, different entities (which may variously be referred to as "units," "circuits," other components, etc.) may be described or claimed as "configured" to perform one or more tasks or operations. This formulation-[entity] configured to [perform one or more tasks]-is used herein to refer to structure (i.e., something physical, such as an electronic circuit). More specifically, this formulation is used to indicate that this structure is arranged to perform the one or more tasks during operation. A structure can be said to be "configured to" perform some task even if the structure is not currently being operated. An "authentication server configured to perform an authentication of a user" is intended to cover, for example, a computer system having a processor and memory having program instructions executable to perform this function during operation, even if the integrated circuit in question is not currently being used (e.g., a power supply is not connected to it). Thus, an entity described or recited as "configured to" perform some task refers to something physical, such as a device, circuit, memory storing program instructions executable to implement the task, etc. This phrase is not used herein to refer to something intangible. Thus the "configured to" construct is not used herein to refer to a software entity such as an application programming interface (API).

The term "configured to" is not intended to mean "configurable to. " An unprogrammed FPGA, for example, would not be considered to be "configured to" perform some specific function, although it may be "configurable to" perform that function and may be "configured to" perform the function after programming.

Reciting in the appended claims that a structure is "configured to" perform one or more tasks is expressly intended not to invoke <NUM> U. § <NUM>(f) for that claim element. Accordingly, none of the claims in this application as filed are intended to be interpreted as having means-plus-function elements. Should Applicant wish to invoke Section <NUM>(f) during prosecution, it will recite claim elements using the "means for" [performing a function] construct.

As used herein, the terms "first," "second," etc. are used as labels for nouns that they precede, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless specifically stated. For example, in a computing system having multiple user accounts, the terms "first" and "second" user accounts can be used to refer to any users. In other words, the "first" and "second" user accounts are not limited to initial two created user accounts, for example.

As used herein, the term "based on" is used to describe one or more factors that affect a determination. This term does not foreclose the possibility that additional factors may affect a determination. That is, a determination may be solely based on specified factors or based on the specified factors as well as other, unspecified factors. Consider the phrase "determine A based on B. " This phrase specifies that B is a factor used to determine A or that affects the determination of A. This phrase does not foreclose that the determination of A may also be based on some other factor, such as C. This phrase is also intended to cover an embodiment in which A is determined based solely on B. As used herein, the phrase "based on" is thus synonymous with the phrase "based at least in part on.

In some instances, a developer may want to authenticate a user before enabling requested functionality of an application. If the authentication is being handled by an authentication server, the developer may be responsible for writing code in the application that redirects a user to the authentication server as well as code that handles returning the user to the application in order to be given access to the requested functionality. Writing this code, however, may be tedious and could be implemented incorrectly.

The present disclosure describes embodiments in which a platform may host one or more applications on an application server that is accessible to client devices via a web browser. As will be described in greater detail below in various embodiments, the platform supports a new type of exception that can be thrown by an application to cause user authentication to be performed. As used herein, the term "exception" is to be interpreted according to its understood meaning in the art, which includes a data structure that <NUM>) is returned in response to occurrence of an event (such as the occurrence of an error), and that <NUM>) includes information about the event usable by an exception handler to take an action associated with the occurrence of the event. In various embodiments, when the particular type of exception is thrown, an exception handler provided by the platform receives an indication of the thrown exception and facilitates redirecting a user's web browser to an authentication server configured to authenticate the user. In some embodiments, the exception handler also facilitates returning the user's browser to the application after authentication is performed-e.g., by causing the browser to replay the earlier request that caused the particular type of exception to be initially thrown.

In various embodiments, an application developer wanting to authenticate a user at a particular location in an application can merely write an instruction to throw the particular type of exception and use the exception handler provided by the platform to facilitate the user authentication. In many instances, being able to handle authentication via throwing an exception can simplify a developer's task of writing application code-and potentially encourage greater application development.

Turning now to <FIG>, a block diagram of a development platform <NUM> supporting user authentication through exception handling is depicted. In the illustrated embodiment, platform <NUM> includes an application server <NUM>, client device <NUM>, database <NUM>, and an authentication server <NUM>. Application server <NUM> includes an application <NUM>, which includes a thrower <NUM> and an exception handler <NUM>. Client device <NUM> includes a web browser <NUM>. In some embodiments, platform <NUM> may be implemented differently than shown-e.g., client device <NUM> may not be a part of platform10; servers <NUM>, <NUM>, and/or <NUM> may be implemented by the same computer system; database <NUM> may not be present; etc..

Development platform <NUM>, in various embodiments, provides various services including the hosting of applications, such as application <NUM>, on an application server <NUM>, which may be accessible to one or more client devices <NUM> via a web browser <NUM>. In some embodiments, application server <NUM> is one of multiple computing systems working together as a computer cluster in order for platform <NUM> to implement a cloud. In some embodiments, platform <NUM> provides a database <NUM>, which may be accessible to applications for storing application data. In some embodiments, platform <NUM> may provide services for facilitating development of applications such as application <NUM>. For example, these services may include providing a user interface to receive program instructions from a developer, providing libraries having program instructions that can be incorporated by into an application, facilitating compilation of developer code, etc..

Application <NUM> may correspond to any suitable application in which user authentication is desired. Accordingly, in one embodiment, application <NUM> is executable to facilitate customer relationship management (CRM). As shown, application <NUM> may include developer code 113A and platform code 113B. Developer code 113A is program instructions written by a developer of application <NUM>. In contrast, platform code 113B is program instructions supplied by platform <NUM> and may be included in application <NUM> via, for example, an incorporation of a library, an application programmable interface (API) reference, extending a base class, etc..

As noted above, a developer may want to authenticate a user at one or more locations in application <NUM>. For example, web browser <NUM> may be participating in a hypertext transport protocol (HTTP) exchange <NUM> with application <NUM> in which a user is presented with a user interface web page of the application. As a user interacts with application <NUM>, browser <NUM> may request access to confidential information (e.g., via an HTTP GET request), request to update important information (e.g., via HTTP POST request), request performance of a particular function in application <NUM>, etc. Rather than provide program instructions in developer code 113A to handle user authentication during these circumstances, in various embodiments, a developer can include a program instruction (shown as thrower <NUM>) to trigger the user authentication.

Thrower <NUM>, in the illustrated embodiment, is a program instruction (or program instructions) executable to throw a particular type of exception (shown as authentication exception <NUM>) that causes user authentication in response to determining that web browser <NUM> has requested an action that warrants the authentication. In various embodiments, authentication exception <NUM> may include (or be accompanied with) various information usable to facilitate further processing of exception <NUM>. Accordingly, in some embodiments, this information may identify the particular type of exception in order to distinguish it from other types. This information may also include information about the context in which exception <NUM> such as identifying the particular action being requested, whether it was associated with an HTTP GET request or HTTP POST request, etc. In some embodiments, exception <NUM> also includes (or is accompanied with) a stack trace identifying the call stack (i.e., the particular sequence of called functions) associated with the function that threw exception <NUM>. For example, the stack trace might indicate that a function "main" called a function "foo", which called a function "bar" that threw exception <NUM> (i.e., included thrower <NUM>). In some embodiments, authentication exception <NUM> may also identify a particular authentication policy, which may identify a threshold hold security level for a user, identify the manner in which the user should be authenticated, etc. As will be discussed below, this information may be used to determine whether redirection to server <NUM> is warranted, how to replay a request that triggered exception <NUM>, etc. An example of developer code including a thrower <NUM> is discussed below in greater detail with respect to <FIG>. Once authentication exception <NUM> has been throw, it may propagate up the call stack until it is caught by exception handler <NUM>.

Exception handler <NUM>, in various embodiments, is executable to receive an indication of a thrown authentication exception <NUM> and process exception <NUM>, including redirecting web browser <NUM> to authentication server <NUM> for authentication. As will be discussed below in greater detail, in some embodiments, handler <NUM> may initially analyze the information included with exception <NUM>, such as the stack trace, in order to determine whether authentication is even warranted. If the authentication is warranted, in the illustrated embodiment, exception handler <NUM> issues a request to redirect web browser <NUM> (shown as authentication redirection <NUM>) to interface authentication server <NUM>. In some embodiments, authentication redirection <NUM> is an HTTP response including a 3XX status code (such as code <NUM>) and a new uniform resource locator (URL) directed to authentication server <NUM>.

Authentication server <NUM>, in the various embodiments, is a computer system configured to authenticate users of platform <NUM>. Accordingly, server <NUM> may serve an authentication web page that includes one or more input fields for receiving authentication information <NUM> from a user. Server <NUM> may then compare received authentication information <NUM> against maintained authentication of authorized users and may indicate a result <NUM> to application server <NUM>, which may convey result <NUM> to application <NUM>. Authentication server <NUM> may support any suitable form of authentication. In some embodiments, server <NUM> performs a two-factor authentication in which a user may, for example, present <NUM>) a user name and password and <NUM>) a one-time authentication code, which may be sent to a user's phone. Once server <NUM> has performed the authentication, web browser <NUM> may be redirect back to application <NUM>.

In some embodiments, handler <NUM> facilitates this returning redirection by analyzing various information received with exception <NUM> and determining where browser <NUM> should return after authentication. As will be discussed in greater detail with respect to <FIG>, in some embodiments, handler <NUM> includes, in authentication redirection <NUM>, a return URL identifying the return location in application <NUM>. In response to receiving this URL, authentication server <NUM> may issue a corresponding redirection to that URL after performing the authentication. In some embodiments, this approach may be used if exception <NUM> is thrown in response to browser <NUM> initially sending an HTTP GET request that specified the URL in order to cause browser <NUM> to replay the HTTP get request. In some embodiments, handler <NUM> may instead store information in database <NUM> and include an identifier in redirection <NUM> to subsequently retrieve this information to facilitate replay. In such an embodiment, authentication server <NUM> may redirect browser <NUM> to another location and include the identifier in the redirection. In such an embodiment, this other location (which is described as handler <NUM> below with <FIG>, but may be another location in other embodiments) may retrieve the stored information from database <NUM> and redirect browser <NUM> to replay a HTTP request using this information. In some embodiments, this approach may be used if exception <NUM> is thrown in response to browser <NUM> initially sending an HTTP POST request specifying various parameters, which may be stored and retrieved from database <NUM> to cause them to be replayed in another HTTP POST request. In other embodiments, replaying the initial HTTP request may be performed differently.

Turning now to <FIG>, an example of developer code 113A including a thrower <NUM> is depicted. In this example, application <NUM> is executable to keep track of a student's grade point average (GPA). If a browser <NUM> has issued a request to update the student's GPA, a determination is made whether the user's authentication level is equal to "HIGH_ASSURANCE" (a level assigned to a school administrator in this example). If the authentication is not equal, execution of thrower <NUM> occurs.

In the illustrated embodiment, thrower <NUM> specifies an exception indication <NUM>, policy indication <NUM>, and action indication <NUM>, which may be provided to exception handler <NUM> when exception <NUM> is thrown. Exception indication <NUM> identifies the particular type of exception being thrown, so that it can be distinguished from other types and routed to the appropriate hander. Policy indication <NUM> identifies the authentication policy associated with the authentication and may be used, for example, to determine what level of authentication is desired for the requested action. Action indication <NUM> identifies the particular action (e.g., "updating GPA") being requested that causes the exception <NUM> to be thrown. In other embodiments, thrower <NUM> may specify more (or less) information. Although not depicted, a stack trace may be returned through invoking the "throw" operator. Notably, however, thrower <NUM> does not, in the illustrated embodiment, explicitly specify a particular location to send browser <NUM> (such as URL to authentication server <NUM>) or explicitly specify that browser <NUM> has to return to a particular location.

When thrower <NUM> is executed, exception handler <NUM> may receive an indication of the thrown exception <NUM>. In some embodiments, this indication is in the form of a pointer to the data structure, which, in this example, is instantiated by invoking the "new" operator and thrown by the "throw" operator. In another embodiment, the received indication is the data structure including information the exception <NUM>. (Although the illustrated example is written in APEX™, any suitable language may be used.

Turning now to <FIG>, a block diagram of exception handler <NUM> is depicted. In the illustrated embodiment, exception handler <NUM> includes exception analyzer <NUM>, redirector <NUM>, and replay assistant <NUM>. In some embodiments, handler <NUM> may be implemented different than shown-e.g., replay assistant <NUM> may be distinct from handler <NUM>, located at authentication server <NUM>, and/or located elsewhere.

Exception analyzer <NUM>, in some embodiments, is a set of program instructions executable to analyze the information returned with exception <NUM> and determine whether authentication is warranted. In various embodiments, this analysis may include examining the various information discussed above with respect to <FIG>. For example, analyzer <NUM> may identify the origin (e.g., function) of the thrown exception <NUM> based on the call stack in the stack trace. If the exception <NUM> originated from an application programming interface (API) call (as opposed to a function in developer code 113A), analyzer <NUM> may determine that authentication is not warranted. Analyzer <NUM> may also analyze the particular function being requested by browser <NUM> (e.g., action indication <NUM> returned with exception <NUM>). If authentication is not warranted, analyzer <NUM> may return an error message to application <NUM> and/or browser <NUM>. If authentication is warranted, however, analyzer <NUM> may pass exception <NUM> to redirector <NUM>.

Redirector <NUM>, in some embodiments, is a set of program instructions executable to redirect web browser <NUM> to an authentication server <NUM> to cause performance of a user authentication. As noted above, this redirection may include, for example, sending an HTTP redirection status code (e.g., a 3XX code) to browser <NUM> with the address of authentication server <NUM>. In various embodiments, redirector <NUM> is also executable to collect various information usable to facilitate browser <NUM>'s return to application <NUM>. In some embodiments, redirector <NUM> includes this information as one or more parameters in a URL included in authentication redirection <NUM>. For example, if an HTTP GET request from browser <NUM> triggered exception <NUM>, redirector <NUM> may include a return URL <NUM> identifying the location where browser <NUM> is to return upon authentication. In response to receiving return URL <NUM>, authentication server <NUM> may include return URL <NUM> in a replay redirection <NUM> to cause browser <NUM> to return to application <NUM> and replay the initial HTTP GET request <NUM>. In some embodiments, redirector <NUM> may alternatively store replay information <NUM> in database <NUM> and include an information identifier <NUM> within the URL in authentication redirection <NUM> in order to later retrieve information <NUM>. For example, if an HTTP POST request from browser <NUM> triggered exception <NUM>, redirector <NUM> may store the parameters specified in the HTTP POST request in database <NUM> for subsequent retrieval. In some embodiments, redirector <NUM> may further encrypt replay information <NUM> in order to protect it. (Although database <NUM> is depicted in <FIG> as separate from application server <NUM>, any suitable storage may be used to store replay information <NUM> such as a local cache at server <NUM>.

Replay assistant <NUM>, in some embodiments, is a set of program instructions executable to cause the web browser to return to the particular application by instructing the web browser to replay a request <NUM> that caused the indication of the particular type of exception to be thrown. Although depicted within handler <NUM> in the illustrated embodiment, assistant <NUM> may reside elsewhere such as within application <NUM>, authentication server <NUM> (e.g., to issue replay redirection <NUM>), etc. Multiple instances of replay assistant <NUM> may also be used. In the illustrated embodiment, assistant <NUM> receives information identifier <NUM> from authentication server <NUM> (which may be conveyed via browser <NUM> in a redirection request) in response to performance of an authentication. In response to receiving identifier <NUM>, assistant <NUM> may use identifier <NUM> to retrieve earlier stored replay information <NUM> from database <NUM> and provide information <NUM> in a replay redirection <NUM> to cause browser <NUM> to replay the appropriate HTTP request <NUM> to return to application <NUM>.

Turning now to <FIG>, a flowchart of a method <NUM> for authenticating a user through exception handling is depicted. In one embodiment, method <NUM> is performed by a computing system executing an application such as application server <NUM> executing application <NUM>.

In step <NUM>, an exception handler (e.g., handler <NUM>) of a software development platform (e.g., platform <NUM>) is maintained, the exception handler being executable to process a particular type of exception (e.g. exception <NUM>) that causes an authentication of users of applications (e.g., application <NUM>) running on the software development platform.

In step <NUM>, an indication of the particular type of exception thrown by a particular application is received at the exception handler.

In step <NUM>, in response to receiving the indication of the particular type of exception, the exception handler issues, to a web browser (e.g., browser <NUM>) interacting with the particular application, a request (e.g., redirection <NUM>) that the web browser redirect to an authentication server (e.g., server <NUM>) configured to perform an authentication of a user of the particular application. In some embodiments, the issued request includes a hypertext transfer protocol (HTTP) redirection status code. In some embodiments, the authentication is a two-factor authentication. In some embodiments, a stack trace received with the indication of the particular type of exception is analyzed, the stack trace identifying a name of an application function that threw the particular type of exception. Based on the analyzing, a determination is made whether to issue the request that the web browser redirect to an authentication server.

In step <NUM>, a result (e.g., result <NUM>) of the performed authentication is received from the authentication server. In step <NUM>, the result is returned to the particular application. In some embodiments, method <NUM> further includes, in response to the authentication, causing the web browser to return to the particular application by instructing the web browser (e.g., via redirection <NUM>) to replay a request (e.g., a request <NUM>) that caused the indication of the particular type of exception to be thrown. In some embodiments, a uniform resource locator (URL) is provided to the web browser that includes information (e.g., return URL <NUM> or info. identifier <NUM>) usable to replay the request that caused the indication of the particular type of exception to be thrown. In some embodiments, method <NUM> includes storing, in a database, information (e.g., replay information <NUM>) about the request that caused the indication of the particular type of exception to be thrown. In such an embodiment, the stored information is used to replay the request that caused the indication of the particular type of exception to be thrown. In some embodiments, method <NUM> includes determining where to cause the web browser to return in the particular application by analyzing a stack trace received with the indication of the particular type of exception, the stack trace identifying a name of an application function that threw the particular type of exception.

Turning now to <FIG>, a flowchart of another method <NUM> for authenticating a user through exception handling is depicted. In one embodiment, method <NUM> is performed by a computing system performing a user authentication such as authentication server <NUM>.

Method begins in step <NUM> with receiving a request from a web browser (e.g., browser <NUM>) to authenticate a user of an application. In various embodiments, the request is issued by the web browser in response to the application throwing a particular type of exception (e.g., exception <NUM>) that causes an exception handler (e.g., handler <NUM>) to redirect the web browser to the computing system. In step <NUM>, in response to the request, an authentication page is served to the web browser. In step <NUM>, an authentication of the user is performed based on an input (e.g., authentication information <NUM>) received via the authentication page. In step <NUM>, the web browser is redirected to the application (e.g., via replay redirection <NUM>). In various embodiments, the redirecting includes providing, to the web browser, information usable by the web browser to replay a request to the application that caused the particular type of exception to be thrown. In some embodiments, the information provided to the web browser is determined based on a value (e.g., information identifier <NUM>) included in a uniform resource locator (URL) within the received request to authenticate. In some embodiments, the replayed request is a hypertext transfer protocol (HTTP) post request (e.g., request <NUM>) that includes one or more parameters corresponding to the provided information. In one embodiment, the value is usable to obtain the one or more parameters from a database (e.g., database <NUM>).

Turning now to <FIG>, a block diagram of an exemplary computer system <NUM>, which may implement functionality of platform <NUM> (such as server <NUM>, device <NUM>, database <NUM>, or server <NUM>), is depicted. Computer system <NUM> includes a processor subsystem <NUM> that is coupled to a system memory <NUM> and I/O interfaces(s) <NUM> via an interconnect <NUM> (e.g., a system bus). I/O interface(s) <NUM> is coupled to one or more I/O devices <NUM>. Computer system <NUM> may be any of various types of devices, including, but not limited to, a server system, personal computer system, desktop computer, laptop or notebook computer, mainframe computer system, tablet computer, handheld computer, workstation, network computer, a consumer device such as a mobile phone, music player, or personal data assistant (PDA). Although a single computer system <NUM> is shown in <FIG> for convenience, system <NUM> may also be implemented as two or more computer systems operating together.

Processor subsystem <NUM> may include one or more processors or processing units. In various embodiments of computer system <NUM>, multiple instances of processor subsystem <NUM> may be coupled to interconnect <NUM>. In various embodiments, processor subsystem <NUM> (or each processor unit within <NUM>) may contain a cache or other form of on-board memory. In one embodiment, processor subsystem <NUM> may include processor(s) <NUM> described above.

System memory <NUM> is usable store program instructions executable by processor subsystem <NUM> to cause system <NUM> perform various operations described herein. System memory <NUM> may be implemented using different physical memory media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read only memory (PROM, EEPROM, etc.), and so on. Memory in computer system <NUM> is not limited to primary storage such as memory <NUM>. Rather, computer system <NUM> may also include other forms of storage such as cache memory in processor subsystem <NUM> and secondary storage on I/O Devices <NUM> (e.g., a hard drive, storage array, etc.). In some embodiments, these other forms of storage may also store program instructions executable by processor subsystem <NUM>. In some embodiments, application <NUM> described above may program instructions stored within system memory <NUM>.

I/O interfaces <NUM> may be any of various types of interfaces configured to couple to and communicate with other devices, according to various embodiments. In one embodiment, I/O interface <NUM> is a bridge chip (e.g., Southbridge) from a front-side to one or more back-side buses. I/O interfaces <NUM> may be coupled to one or more I/O devices <NUM> via one or more corresponding buses or other interfaces. Examples of I/O devices <NUM> include storage devices (hard drive, optical drive, removable flash drive, storage array, SAN, or their associated controller), network interface devices (e.g., to a local or wide-area network), or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, computer system <NUM> is coupled to a network via a network interface device <NUM> (e.g., configured to communicate over WiFi, Bluetooth, Ethernet, etc.).

Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even where only a single embodiment is described with respect to a particular feature. Examples of features provided in the disclosure are intended to be illustrative rather than restrictive unless stated otherwise. The above description is intended to cover such alternatives, modifications, and equivalents as would be apparent to a person skilled in the art having the benefit of this disclosure.

Claim 1:
A method comprising:
maintaining a software development platform providing a user interface to receive program instructions from a developer and providing platform code to be supplied by the platform, said software development platform hosting applications comprising program instructions written by a developer,
maintaining an exception handler provided by the software development platform, wherein the exception handler is executable to process a particular type of exception that causes an authentication of users of applications running on the software development platform;
receiving, at the exception handler, an indication of the particular type of exception thrown by a particular application, said particular exception having been thrown by developer - supplied program instructions;
in response to receiving the indication of the particular type of exception:
issuing, by the exception handler to a web browser interacting with the particular application, a request that the web browser redirect to an authentication server configured to perform an authentication of a user of the particular application;
receiving, from the authentication server, a result of the performed authentication; and
returning the result to the particular application,
wherein the method further comprises:
analyzing a stack trace received with the indication of the particular type of exception, wherein the stack trace identifies a name of an application function that threw the particular type of exception; and
based on the analyzing, determining whether to issue the request that the web browser redirect to an authentication server.