Methods for load balancing in a federated identity environment and devices thereof

Abstract

Methods, non-transitory computer readable media, network traffic management apparatuses, and network traffic management systems performing load balancing in a federated identity environment. An enhanced identity service provider server receives a redirected user authentication from a client device. Upon successfully authenticating the user of the client device a token is generated. Further another service provider server is selected based on a comparison of one or more network parameters and the client device is redirected with the token to the another selected service provider server. Based on a validation of the token the client device accesses applications protected by the selected another service provider server.

Description

FIELD

This technology generally relates to enterprise networks and, more particularly, to methods and devices for improved workload scheduling.

BACKGROUND

Federated identity environments provide a way of securely exchanging identity information across internet domains. Traditional load balancing enables load distribution, however when applications are deployed in a federated identity environment, then the existing technology does not perform any load balancing. Prior technologies have failed to address the issue of load balancing of user traffic across multiple service provider server devices by selecting a service provider server based on network parameters for servicing the user access request.

SUMMARY

A method for load balancing in a federated identity environment implemented by one or more enhanced identity provider server devices includes receiving a redirected authentication request from a client to access one of a plurality of service provider servers. A token is generated when the authentication request is successfully authenticated. One or more network parameter values of the one of the plurality of service provider server devices are compared against one or more network parameter values associated with each of the other plurality of service provider server devices. One of the other plurality of service provider server devices is selected based on the comparison and one or more selection rules. The client is redirected to the selected one of the other plurality of service provider server devices with the generated token for accessing one or more applications associated with the selected one of the plurality of service provider server devices.

An enhanced identity provider apparatus comprising a memory with programmed instructions stored thereon and one or more processors configured to be capable of executing the stored programmed instructions to receive a redirected authentication request from a client to access one of a plurality of service provider servers. A token is generated when the authentication request is successfully authenticated. One or more network parameter values of the one of the plurality of service provider server devices are compared against one or more network parameter values associated with each of the other plurality of service provider server devices. One of the other plurality of service provider server devices is selected based on the comparison and one or more selection rules. The client is redirected to the selected one of the other plurality of service provider server devices with the generated token for accessing one or more applications associated with the selected one of the plurality of service provider server devices.

A non-transitory computer readable medium having stored thereon instructions for load balancing in a federated identity environment comprising executable code which when executed by one or more processors, causes the one or more processors to receive a redirected authentication request from a client to access one of a plurality of service provider servers. A token is generated when the authentication request is successfully authenticated. One or more network parameter values of the one of the plurality of service provider server devices are compared against one or more network parameter values associated with each of the other plurality of service provider server devices. One of the other plurality of service provider server devices is selected based on the comparison and one or more selection rules. The client is redirected to the selected one of the other plurality of service provider server devices with the generated token for accessing one or more applications associated with the selected one of the plurality of service provider server devices.

This technology has a number of advantages including providing methods, non-transitory computer readable media, and enhanced identity provider apparatus that provides optimized load balancing. With this technology, load balancing of user traffic across multiple service providers is provided to select a service provider server based on multiple parameters for servicing user access request. Additionally, this technology optimizes servicing of requests by selecting a service provider based on the current status of network utilization to provide a more optimal end-user experience.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary network environment with an exemplary enhanced identity provider (E-IdP) device;

FIG. 2 is a block diagram of the exemplary E-IdP device of FIG. 1;

FIG. 3 is a flowchart of an exemplary method for initializing the exemplary E-IdP device of FIG. 1; and

FIG. 4 is a flowchart of an exemplary method for load balancing in a federated identity environment.

DETAILED DESCRIPTION

Referring to FIG. 1, an exemplary network environment which incorporates an exemplary network traffic management system 10 that includes an enhanced identity provider (E-IdP) device 12 to load balance in a federated identity environment is illustrated. The network traffic management system 10 in this example includes an enhanced identity provider (E-IdP) device 12 that is coupled to a plurality of service provider server devices 14(1)-14(n), and each of the plurality of service provider server devices 14(1)-14(n) are coupled to a corresponding backend application server devices 20(1)-20(n) associated with it. Although, the E-IdP device 12, service provider server devices 14(1)-14(n), backend application server devices 20(1)-20(n) and/or client devices 16(1)-16(n) may be coupled together via other topologies. Additionally, the network traffic management system 10 may include other network devices, such as one or more routers and/or switches, for example, which are well known in the art and thus will not be described herein. This technology provides a number of advantages including methods, non-transitory computer readable media, network traffic management systems, and the E-IdP device 12 that collect and monitor current load, health and geographical location for a plurality of service provider server devices. Further advantages include load balancing the user traffic across plurality of service provider server devices for improved availability and manageability of the applications to provide improved availability and manageability of the applications.

Referring to FIGS. 1-2, the E-IdP device 12 of the network traffic management system 10 may perform any number of functions including authenticating a request from the client devices 16(1)-16(n) for application access, generating tokens for validation, collecting and monitoring current load, health and geographical location for a plurality of service provider server devices 14(1)-14(n), although other types and/or numbers of other functions may be performed. The E-IdP device 12 performs the function of collection user identity information from the client devices 16(1)-16(n) and authenticating requests. The E-IdP device 12 may function as an access policy management apparatus (APM) to perform functions of managing network traffic, load balancing network traffic across the service provider server devices 14(1)-14(n) as well as functions including authenticating a client application access request, generating tokens for validation, collecting and monitoring current load, health and geographical location for a plurality of service provider server devices 14(1)-14(n), although other types and/or numbers of other functions may be performed. Further the E-IdP device 12 may function as a service provider server devices 14(1)-14(n) to perform functions of receiving application access request, send a redirected authentication request and further perform functions of authenticating a request, generating tokens for validation, collecting and monitoring current load, health and geographical location for the plurality of service provider server devices 14(1)-14(n). The E-IdP device 12 includes one or more processors 24, a memory 26, and/or a communication interface 22, which are coupled together by a bus 30 or other communication link, although the E-IdP device 12 can include other types and/or numbers of elements in other configurations.

The processor(s) of the E-IdP device 12 may execute programmed instructions stored in the memory 26 of the E-IdP device 12 for the any number of the functions identified above. The processor(s) of the E-IdP device 12 may include one or more CPUs or general purpose processors with one or more processing cores, for example, although other types of processor(s) can also be used.

The memory 26 of the E-IdP device 12 stores these programmed instructions for one or more aspects of the present technology as described and illustrated herein, although some or all of the programmed instructions could be stored elsewhere. A variety of different types of memory storage devices, such as random access memory (RAM), read only memory (ROM), hard disk, solid state drives, flash memory, or other computer readable medium which is read from and written to by a magnetic, optical, or other reading and writing system that is coupled to the processor(s) 24, can be used for the memory 26.

Accordingly, the memory 26 of the E-IdP device 12 can store one or more applications that can include computer executable instructions that, when executed by the E-IdP device 12, cause the E-IdP device 12 to perform actions, such as collecting and monitoring the current load, health and geographical location of a plurality of service provider server devices 14(1)-14(n) and load balancing the user traffic across multiple service provider server devices 14(1)-14(n) for improved availability and manageability of the applications, for example, and to perform other actions described and illustrated below with reference to FIGS. 3-4. The application(s) can be implemented as modules or components of other applications. Further, the application(s) can be implemented as operating system extensions, module, plugins, or the like.

Even further, the application(s) may be operative in a cloud-based computing environment. The application(s) can be executed within or as virtual machine(s) or virtual server(s) that may be managed in a cloud-based computing environment. Also, the application(s), and even the E-IdP device 12 itself, may be located in virtual server(s) running in a cloud-based computing environment rather than being tied to one or more specific physical network computing devices. Also, the application(s) may be running in one or more virtual machines (VMs) executing on the E-IdP device 12. Additionally, in one or more embodiments of this technology, virtual machine(s) running on the E-IdP device 12 may be managed or supervised by a hypervisor.

In this particular example, the memory of the E-IdP device 12 includes a memory 26 for processing received authentication requests and a user identity information storage although the memory 26 can include other policies, modules, databases, or applications, for example. The E-IdP device 12 receives an authentication request to access one of a plurality of service provider server devices 14(1)-14(n) and the E-IdP device 12 may act as an authentication module, to authenticate the user requests before accessing applications at one of the backend application server devices 20(1)-20(n) associated with one of the plurality of service provider server devices 14(1)-14(n). The E-IdP device 12 may have access to user's identity information stored within the user identity information storage 28. The E-IdP device 12 collects user identity information from the client devices 16(1)-16(n) and accesses stored user identity information to authenticate the user. Upon authentication the E-IdP device 12 generates a token associated with the request. The E-IdP device 12 also collects and monitors current load parameter, health parameter, and geographical location parameter of the plurality of service provider server devices 14(1)-14(n).

The user identity information storage 28 may store information associated with users identity and is utilized to authenticate the user request. The user identity information includes, for example, user ID, username, password, mobile number, personal preferences, user location information or user preferences.

The communication interface 22 of the E-IdP device 12 operatively couples and communicates between the E-IdP device 12, the service provider server devices 14(1)-14(n), and/or the client devices 16(1)-16(n), which are all coupled together by the communication network(s) 18, although other types and/or numbers of communication networks 18 or systems with other types and/or numbers of connections and/or configurations to other devices and/or elements can also be used.

By way of example only, the communication network(s) 18 can include local area network(s) (LAN(s)) or wide area network(s) (WAN(s)), and can use TCP/IP over Ethernet and industry-standard protocols, although other types and/or numbers of protocols and/or communication networks 18 can be used. The communication network(s) 18 in this example can employ any suitable interface mechanisms and network communication technologies including, for example, teletraffic in any suitable form (e.g., voice, modem, and the like), Public Switched Telephone Network (PSTNs), Ethernet-based Packet Data Networks (PDNs), combinations thereof, and the like. The communication network(s) 18 can also include direct connection(s) (e.g., for when a device illustrated in FIG. 1, such as the E-IdP device 12, one or more of the client devices 16(1)-16(n), one or more of the service provider server devices 14(1)-14(n), or one or more backend application server devices 20(1)-20(n) operate as virtual instances on the same physical machine).

While the E-IdP device 12 is illustrated in this example as including a single device, the E-IdP device 12 in other examples can include a plurality of devices or blades each having one or more processors (each processor with one or more processing cores) that implement one or more steps of this technology. In these examples, one or more of the devices can have a dedicated communication interface or memory. Alternatively, one or more of the devices can utilize the memory, communication interface, or other hardware or software components of one or more other devices included in the E-IdP device 12.

Additionally, one or more of the devices that together comprise the E-IdP device 12 in other examples can be standalone devices or integrated with one or more other devices or apparatuses, such as one of the service provider server devices 14(1)-14(n), for example. Moreover, one or more of the devices of the E-IdP device 12 in these examples can be in a same or a different communication network 18 including one or more public, private, or cloud networks, for example.

Each of the service provider server devices 14(1)-14(n) of the network traffic management system 10 in this example includes one or more processors, a memory, and a communication interface, which are coupled together by a bus or other communication link, although other numbers and/or types of network devices could be used. Each of the plurality of service provider server devices 14(1)-14(n) are coupled to corresponding backend application server devices 20(1)-20(n). In yet another example, each of the plurality of service provider server devices 14(1)-14(n) are coupled to one or more backend application server devices 20(1)-20(n). The service provider server devices 14(1)-14(n) in this example process requests received from the client devices 16(1)-16(n) via the communication network(s) 18 according to the HTTP-based application RFC protocol, for example. Various applications may be operating on the service provider server devices 14(1)-14(n) and transmitting data (e.g., files or Web pages) to the client devices via the E-IdP device 12 in response to requests from the client devices 16(1)-16(n). The service provider server devices 14(1)-14(n) may be hardware or software or may represent a system with multiple service provider server devices 14(1)-14(n) in a pool, which may include internal or external networks.

Although the service provider server devices are illustrated as single devices, one or more actions of each of the service provider server devices may be distributed across one or more distinct network computing devices that together comprise one or more of the service provider server devices. Moreover, the service provider server devices are not limited to a particular configuration. Thus, the service provider server devices may contain a plurality of network computing devices that operate using a master/slave approach, whereby one of the network computing devices of the service provider server devices operate to manage and/or otherwise coordinate operations of the other network computing devices. The service provider server devices may operate as a plurality of network computing devices within a cluster architecture, a peer-to peer architecture, virtual machines, or within a cloud architecture, for example.

Each of the backend application server devices of the network traffic management system in this example includes one or more processors, a memory including one or more applications, and a communication interface, which are coupled together by a bus or other communication link, although other numbers and/or types of network devices could be used. The one or more client devices may access the one or more applications associated with the backend application server device. The backend application server device in this example process requests received from the client devices via the communication network(s) 18 according to the HTTP-based application RFC protocol, for example. Various applications may be operating on the backend application server devices and transmitting data (e.g., files or Web pages) to the client devices in response to requests from the client devices. The backend application server device may be hardware or software or may represent a system with multiple backend application servers in a pool, which may include internal or external networks.

Although the backend application server device may be single devices, one or more actions of each of the backend application server devices may be distributed across one or more distinct network computing devices that together comprise one or more of the backend application server devices. In yet another example, each of the backend application server devices can operate within the service provider server device rather than as a stand-alone server communicating with the service provider server device. Moreover, each of the backend application server devices are not limited to a particular configuration. Thus, each of the backend application server devices may contain a plurality of network computing devices that operate using a master/slave approach, whereby one of the network computing devices of the backend application server devices operate to manage and/or otherwise coordinate operations of the other network computing devices. Each of the backend application server devices may operate as a plurality of network computing devices within a cluster architecture, a peer-to peer architecture, virtual machines, or within a cloud architecture, for example. Each of the backend application server devices may also communicate with the client devices, service provider server devices and the E-IdP device 12.

Thus, the technology disclosed herein is not to be construed as being limited to a single environment and other configurations and architectures are also envisaged. For example, the E-IdP device 12 depicted in FIG. 1 can operate within an access policy manager apparatus (APM) rather than as a stand-alone server communicating with the client devices and the backend application servers. In this example the E-IdP device 12 operates within the memory of the access policy manager apparatus. Further in another example, the one or more of the plurality of service provider servers depicted in FIG. 1 can operate within the E-IdP device 12 rather than as a stand-alone server communicating with the client devices and the backend application servers. In this example the plurality of service provider servers operate within the memory of the E-IdP device 12. Further in another example, the E-IdP device 12 and the one or more of the plurality of service provider servers depicted in FIG. 1 both together can operate within the APM rather than as a stand-alone server communicating with the client devices and the backend application servers. Further in another example, the E-IdP device 12 depicted in FIG. 1 can operate as the APM communicating with the service provider server devices 14(1)-14(n) and the client devices 16(1)-16(n).

The client devices 16(1)-16(n) of the network traffic management system 10 in this example include any type of computing device that can receive, render, and facilitate user interaction with a webtop, such as mobile computing devices, desktop computing devices, laptop computing devices, tablet computing devices, virtual machines (including cloud-based computers), or the like. Each of the client devices 16(1)-16(n) in this example includes a processor, a memory, and a communication interface, which are coupled together by a bus or other communication link, although other numbers and/or types of network devices could be used. In one example, the client devices 16(1)-16(n) may communicate with the backend application server devices 20(1)-20(n). In another example the client devices 16(1)-16(n) may communicate with the E-IdP device 12 directly. Further in another example the client devices 16(1)-16(n) may communicate with each of the service provider server devices 14(1)-14(n) directly.

The client devices 16(1)-16(n) may run interface applications, such as standard Web browsers or standalone client applications, which may provide an interface to make requests for, and receive content stored on, one or more of the service provider server devices 14(1)-14(n) via the communication network(s) 18. The client devices 16(1)-16(n) may further include a display device, such as a display screen or touchscreen, and/or an input device, such as a keyboard for example.

Although the exemplary network traffic management system 10 with the E-IdP device 12, service provider server devices 14(1)-14(n), backend application server devices 20(1)-20(n), client devices 16(1)-16(n), and communication network(s) 18 are described and illustrated herein, other types and/or numbers of systems, devices, components, and/or elements in other topologies can be used. It is to be understood that the systems of the examples described herein are for exemplary purposes, as many variations of the specific hardware and software used to implement the examples are possible, as will be appreciated by those skilled in the relevant art(s).

One or more of the components depicted in the network traffic management system 10, such as the E-IdP device 12, client devices 16(1)-16(n), service provider server devices 14(1)-14(n) or backend application server devices 20(1)-20(n), for example, may be configured to operate as virtual instances on the same physical machine. In other words, one or more of the E-IdP device 12, client devices 16(1)-16(n), service provider server devices 14(1)-14(n) or backend application server devices 20(1)-20(n) may operate on the same physical device rather than as separate devices communicating through communication network(s) 18. Additionally, there may be more or fewer E-IdP device 12, client devices 16(1)-16(n), service provider server devices 14(1)-14(n) or backend application server devices 20(1)-20(n) than illustrated in FIG. 1. The client devices could also be implemented as applications on the E-IdP device 12 itself as a further example.

In addition, two or more computing systems or devices can be substituted for any one of the systems or devices in any example. Accordingly, principles and advantages of distributed processing, such as redundancy and replication also can be implemented, as desired, to increase the robustness and performance of the devices and systems of the examples. The examples may also be implemented on computer system(s) that extend across any suitable network using any suitable interface mechanisms and traffic technologies, including by way of example only teletraffic in any suitable form (e.g., voice and modem), wireless traffic networks, cellular traffic networks, Packet Data Networks (PDNs), the Internet, intranets, and combinations thereof.

The examples may also be embodied as one or more non-transitory computer readable media having instructions stored thereon for one or more aspects of the present technology as described and illustrated by way of the examples herein. The instructions in some examples include executable code that, when executed by one or more processors, cause the processors to carry out steps necessary to implement the methods of the examples of this technology that are described and illustrated herein.

An exemplary method of load balancing in a federated identity environment and devices thereof will now be described with reference to FIGS. 1-4. Referring more specifically to FIG. 3, in this example in a first step 310, the E-IdP device 12 receives from one of the client devices 16(1)-16(n) a redirected authentication request which was redirected by one of the plurality of service provider server devices 14(1)-14(n). In this example, the one of the plurality of service provider server devices 14(1)-14(n) is the service provider server device-114(1) and is referred to herein as the intended service provider server 14(1). The enhanced identity provider (E-IdP) device 12 of the network traffic management system 10 receives the redirected authentication request from one of the client devices 16(1)-16(n) to access the intended service provider server device 14(1). After receiving the authentication request from the requesting one of the client devices 16(1)-16(n), the E-IdP device 12 collects identity information from the user of the client devices 16(1)-16(n) to authenticate the user to provide access to the intended service provider server device 14(1). The E-IdP device 12 performs the authentication by associating the collected user identity information with information stored in the user identity information storage 28 of the E-IdP device 12 to authenticate the request. In yet another example, the E-IdP device 12 performs the authentication by validating the collected user identity information with information stored in the user identity information storage 28 of the E-IdP device 12, and upon a successful validation the request is authenticated.

In step 315, the E-IdP device 12 determines whether the request from the requesting one of the client devices 16(1)-16(n) is authenticated. If in step 315, the E-IdP device 12 determines that the request is not authenticated, then the No branch is taken to step 320.

In step 320, the E-IdP device 12 sends a redirected error notification message to the requesting one of the client devices 16(1)-16(n). This redirected error notification message redirects the requesting one of the client devices 16(1)-16(n) with the error message to the intended service provider server device 14(1) which provides a notification that the request is not authenticated and this example of the method may end.

If back in step 315, the E-IdP device 12 determines that the request from the requesting one of the client devices 16(1)-16(n) is authenticated, then the Yes branch is taken to step 325. In step 325, the E-IdP device 12 generates a token used for validation as described in greater detail further below. After generating the token the method proceeds to step 330.

In step 330, the E-IdP device 12 periodically monitors one or more parameters of the plurality of service provider servers 14(1)-14(n). The E-IdP device 12 periodically monitors one or more network parameters for the plurality of service provider server devices 14(1)-14(n) which are utilized to perform the comparison. By way of example, the one or more network parameters may include, a current load parameter, a server health parameter, and/or geographic location parameter associated with the plurality of service provider server devices 14(1)-14(n), although other types and/or numbers of parameters may be used. The E-IdP device 12 periodically monitors one or more network parameter and collects one or more network parameter data values associated with the one or more network parameters. By way of example, the one or more network parameter data values may include, a current load value, a server health value, and/or geographic location value associated with the plurality of service provider server devices 14(1)-14(n), although other types and/or numbers of parameter data values may be used. The collected one or more network parameters values for the plurality of service provider server devices 14(1)-14(n) are utilized in step 335 below.

In step 335, the E-IdP device 12 compares the collected one or more network parameter values associated with the intended service provider server device 14(1) against corresponding other one or more network parameter values associated with the other of the plurality of service provider server devices 14(2)-14(n). By way of example, the one or more network parameter data values may include, a current load value, a server health value, and/or geographic location value associated with the plurality of service provider server devices 14(1)-14(n), although other types and/or numbers of parameter values may be used. By way of example, the E-IdP device 12 compares the current load value associated with the service provider server device-114(1) with each of the corresponding current load values associated with the service provider server devices 14(2)-14(n). By way of example, the E-IdP device 12 compares the CPU utilization value associated with the service provider server device-114(1) with each of the corresponding CPU utilization values associated with the service provider server devices 14(2)-14(n). In another example, the E-IdP device 12 compares the server health value associated with the service provider server device-114(1) with corresponding each of the server health value associated with the service provider server devices 14(2)-14(n). In yet another example, the E-IdP device 12 compares the geographic location value associated with the service provider server device-114(1) with each of the corresponding geographic location value associated with the service provider server devices 14(2)-14(n). The detecting of the hardware deficiencies or failures in the service provider server devices 14(1)-14(n) is performed to identify potential issues in the service provider server devices 14(1)-14(n).

Further, the E-IdP device 12 performs the comparing, for example, by comparing the current load parameter value of the intended service provider server device 14(1) with the current load parameter value of the other service provider server devices 14(2)-14(n). The current load parameter value of the plurality of service provider server devices 14(1)-14(n) may be the current load capacity of the server determined based on the number of processes waiting in a queue to access a processor of the associated service provider server devices 14(1)-14(n) for a specific time period. The smaller the current load means more resources available to process the requests and hence better performance state of the service provider server devices 14(1)-14(n). Based on the comparison in step 335 the capacity of current load for each of the plurality of service provider server devices 14(1)-14(n) is determined. By way of example, the current load parameter value for the intended service provider server device 14(1) may be determined at 60% of its capacity and further the current load parameter value associated with the other service provider server devices 14(2)-14(n) are all determined to be less than 60% of their capacity. In another example, the current load parameter value for the intended service provider server device 14(1) may be determined at 60% of its capacity and further the current load parameter value associated with the other service provider server devices 14(2)-14(n) are all determined to be more than 60% of their capacity. Further, by way of another example, the comparison may also determine the current load parameter value associated with the intended service provider server device 14(1) is the same as that of the other service provider server device 14(2)-14(n).

The health parameter associated with service provider server devices 14(1)-14(n) for example helps in determining the performance of the service provider server devices 14(1)-14(n). The health parameters include server response time of the service provider server devices 14(1)-14(n), hardware failures or deficiencies associated with the service provider server devices 14(1)-14(n), CPU utilization associated with the service provider server devices 14(1)-14(n), server heartbeats associated with the service provider server devices 14(1)-14(n). Although, any other parameters associated with determining health of the service provider server devices may also be included. The monitoring of the server response times is performed to determine potential latency issues for the service provider server devices 14(1)-14(n). By way of example, the comparison may be determine that the server response time of the intended service provider server device 14(1) is 50 ms and the server response time associated with each of the other service provider server devices 14(2)-14(n) is less than 50 ms. In another example, the comparison may be determine that the server response time of the intended service provider server device 14(1) is 50 ms and the server response time associated with each of the other service provider server devices 14(2)-14(n) is more than 50 ms. Further, by way of another example, the comparison may also determine the server response time parameter value associated with the intended service provider server device 14(1) is the same as that of the other service provider server device 14(2)-14(n).

The monitoring of the CPU utilization of a server is performed to determine memory utilization of the server, high CPU utilization may cause alerts of performance issues with the service provider server devices 14(1)-14(n). By way of example, the comparison may be determine that the CPU utilization of the intended service provider server device 14(1) is 65% of its usage capacity and the CPU utilization associated with each of the other service provider server devices 14(2)-14(n) is less than 65%. In another example, the comparison may be determine that the CPU utilization of the intended service provider server device 14(1) is 65% of its usage capacity and the CPU utilization associated with each of the other service provider server devices 14(2)-14(n) is more than 65%. Further, by way of another example, the comparison may also determine the CPU utilization parameter value associated with the intended service provider server device 14(1) is the same as that of the other service provider server device 14(2)-14(n).

The heartbeat of the service provider server devices 14(1)-14(n) may be determined by sending a network ping command or a heartbeat message to the service provider server devices 14(I)-14(n), and a response to the ping command provides information of the service provider server devices 14(1)-14(n) being alive and accepting communications. By way of example, the comparison may be determine that the response time to the ping for determining the heartbeat of the intended service provider server device 14(1) is 20 ms and the response time to the ping for determining the heartbeat associated with each of the other service provider server devices 14(2)-14(n) is less than 20 ms. In another example, the comparison may be determine that the response time to the ping for determining the heartbeat of the intended service provider server device 14(1) is 20 ms and the response time to the heartbeat message for determining the heartbeat associated with each of the other service provider server devices 14(2)-14(n) is more than 20 ms. Further, by way of another example, the comparison may also determine the response time parameter value associated with the intended service provider server device 14(1) is the same as that of the other service provider server device 14(2)-14(n).

The geographic location parameter of the service provider server devices 14(1)-14(n) may be determined as a distance between geographic location of the service provider server devices 14(1)-14(n) potentially servicing the request and the requesting one of the client devices 16(1)-16(n) requesting to access the application. Lesser the distance lesser would be the latency, number of hops, and lesser would be a potential of hardware failure as the number of hardware components are reduced with lesser distance. By way of example, the comparison may be determine that the geographic distance between the intended service provider server device 14(1) and the requesting one of the client devices 16(1)-16(n) is less than and the distance associated with each of the other service provider server devices 14(2)-14(n). In another example, the comparison may be determine that the geographic distance between the intended service provider server device 14(1) and the requesting one of the client devices 16(1)-16(n) is more than and the distance associated with each of the other service provider server devices 14(2)-14(n). Further, by way of another example, the comparison may also determine the geographic distance associated with the intended service provider server device 14(1) is the same as that of the other service provider server device 14(2)-14(n).

In another embodiment, if in the comparison step 335 of FIG. 3 the one or more of the other service provider server devices 14(1)-14(n) has a current load parameter equal to the current load parameter of the intended service provider server devices 14(1)-14(n), then the intended service provider server is selected. In another embodiment, when the one or more of the other service provider server devices 14(1)-14(n) has a current load parameter equal to the current load parameter of the intended service provider server, then the one or more of the other service provider servers devices 14(1)-14(n) may be selected over the intended service provider server. In another embodiment, more than one other service provider server devices 14(1)-14(n) may be selected.

In yet another embodiment, the comparison may be performed by comparing more than one parameters of the service provider server devices 14(1)-14(n) based on priorities assigned to the parameters. By way of example, the comparison may be performed by comparing the current load parameter, the health parameter and the geographic location parameter for the intended service provider server and the other service providers based on priorities assigned to each of the parameters. The current load parameter may be assigned the highest priority rank of 1 followed by the health parameter having a lower priority rank of 2 and the geographic location parameter having the least priority rank of 3. Although other types and/or numbers of other parameter comparison may be performed with any number of priorities.

In step 340, the E-IdP device 12 selecting from the plurality of service provider server devices 14(1)-14(n) based on the comparison and one or more selection rules stored in the memory 26. The stored selection rules, may include, selecting the service provider server device with the least current load parameter value, selecting the service provider server device with the least response time, selecting the service provider service device with the least CPU utilization, selecting the service provider service device with the least response time for heartbeat messages, selecting the service provider service device with least geographic distance between the client devices 16(1)-16(n) and the service provider server devices 14(1)-14(n). Further, the selection rules may include, when the one or more network parameter values between the intended service provider server device 14(1) and the other service provider server devices 14(2)-14(n) are equal, then selecting the intended service provider server device 14(1). Based on the selection rules, the E-IdP device 12 selects of a service provider server device that would process the request from the service provider server devices 14(1)-14(n).

Specifically, the selection rules, may include, by way of example, selecting one of the other service provider server devices 14(2)-14(n) when the comparison indicates that the current load parameter value for the intended service provider server device 14(1) may be determined at 60% of its capacity and further the current load parameter value associated with the other service provider server devices 14(2)-14(n) are all determined to be less than 60% of their capacity. In this example, from the other service provider server devices 14(2)-14(1) the E-IdP device 12 selects the service provider server device with the least current load parameters. By way of example, E-IdP device 12 selects the service provider server device 14(2) as it is determined in step 335 that the service provider server device 14(2) has a current load parameters value of 40% and is the least in comparison to all of the other service provider server devices 14(1), 14(3)-14(n). By way of example, another selecting rules may include, selecting the intended service provider server device 14(1) when the comparison of step 335 determines that the current load parameter value for the intended service provider server device 14(1) may be determined at 60% of its capacity and further the current load parameter value associated with the other service provider server devices 14(2)-14(n) are all determined to be more than 60% of their capacity. In this example, as the intended service provider server device 14(1) has the least current load parameter value it is selected.

In another example, the selection rules, may include, by way of example, selecting one of the other service provider server devices 14(2)-14(n) when the comparison of step 335 determines that the response time of the intended service provider server device 14(1) is 50 ms and the response time associated with each of the other service provider server devices 14(2)-14(n) is less than 50 ms. In this example, from the other service provider server devices 14(2)-14(1) the E-IdP device 12 selects the service provider server device with the least response time value. By way of example, E-IdP device 12 selects the service provider server device 14(2) as it is determined in step 335 that the service provider server device 14(2) has a response time value of 30 ms and is the least response time in comparison to all of the other service provider server devices 14(1), 14(3)-14(n). By way of example, another selecting rules may include, selecting the intended service provider server device 14(1) when the response time of the intended service provider server device 14(1) is 50 ms and the response time associated with each of the other service provider server devices 14(2)-14(n) is more than 50 ms. In this example, from the other service provider server devices 14(1)-14(n) the E-IdP device 12 selects the service provider server device with the least response time value. By way of example, E-IdP device 12 selects the service provider server device 14(1) as it is determined in step 335 that the service provider server device 14(1) has a response time value of 50 ms, which is the least response time in comparison to all of the other service provider server devices 14(2)-14(n).

In another example, the selection rules, may include, by way of example, selecting one of the other service provider server devices 14(2)-14(n) when the comparison of step 335 determines that the CPU utilization of the intended service provider server device 14(1) is 65% and the CPU utilization associated with each of the other service provider server devices 14(2)-14(n) is less than 65%. In this example, from the other service provider server devices 14(2)-14(1) the E-IdP device 12 selects the service provider server device with the least CPU utilization value. By way of example, E-IdP device 12 selects the service provider server device 14(2) as it is determined in step 335 that the service provider server device 14(2) has a CPU utilization value of 45% and is the least CPU utilization in comparison to all of the other service provider server devices 14(1), 14(3)-14(n). By way of example, another selecting rules may include, selecting the intended service provider server device 14(1) when the CPU utilization of the intended service provider server device 14(1) is 65% and the CPU utilization associated with each of the other service provider server devices 14(2)-14(n) is more than 65%. In this example, from the other service provider server devices 14(1)-14(n) the E-IdP device 12 selects the service provider server device with the least CPU utilization value. By way of example, E-IdP device 12 selects the service provider server device 14(1) as it is determined in step 335 that the service provider server device 14(1) has a CPU utilization value of 65%, which is the least CPU utilization in comparison to all of the other service provider server devices 14(2)-14(n).

In another example, the selection rules, may include, by way of example, selecting one of the other service provider server devices 14(2)-14(n) when the comparison of step 335 determines that the geographic distance between the intended service provider server device 14(1) and the requesting one of the client devices 16(1)-16(n) is more than and the geographic distance between each of the other service provider server devices 14(2)-14(n) and the requesting one of the client devices 16(1)-16(n). In this example, from the other service provider server devices 14(2)-14(1) the E-IdP device 12 selects the service provider server device with the least geographic distance between each of the other service provider server devices 14(2)-14(n) and the requesting one of the client devices 16(1)-16(n). By way of example, E-IdP device 12 selects the service provider server device 14(2) as it is determined in step 335 that the service provider server device 14(2) has the least geographic distance between each of the other service provider server devices 14(2)-14(n) and the requesting one of the client devices 16(1)-16(n) in comparison to all of the other service provider server devices 14(1), 14(3)-14(n). By way of example, another selecting rules may include, selecting the intended service provider server device 14(1) geographic distance between the intended service provider server device 14(1) and the requesting one of the client devices 16(1)-16(n) is less than and the geographic distance between each of the other service provider server devices 14(2)-14(n) and the requesting one of the client devices 16(1)-16(n). In this example, from the other service provider server devices 14(1)-14(n) the E-IdP device 12 selects the service provider server device with the least geographic distance between each of the other service provider server devices 14(1)-14(n) and the requesting one of the client devices 16(1)-16(n). By way of example, E-IdP device 12 selects the service provider server device 14(1) as it is determined in step 335 that the service provider server device 14(1) has the least geographic distance to the requesting one of the client devices 16(1)-16(n) in comparison to all of the other service provider server devices 14(2)-14(n).

In step 345, the E-IdP device 12 determines if in step 340 one of the other plurality of service provider server devices 14(2)-14(n) are selected in step 340. By way of example, when the E-IdP device 12 determines that in step 340 one of the other plurality of service provider server devices 14(2)-14(n) is selected over the intended service provider server device 14(1), then the method takes the Yes branch and proceeds to step 350. By way of example, E-IdP device 12 selects the service provider server device 14(2) as it is determined in step 335 that the service provider server device 14(2) has a current load parameters value of 40% which is the least current load parameter value in comparison to all of the other service provider server devices 14(1), 14(3)-14(n) and the method proceeds to step 350.

In step 350, the E-IdP device 12 redirects the requesting one of the client devices 16(1)-16(n) to the selected one of the one or more other of the plurality of service provider server devices 14(2)-14(n) with the generated token for accessing one or more applications associated with the selected one of one or more other of the plurality of service provider server devices 14(2)-14(n). The E-IdP device 12 may send a redirect request to the requesting one of the client devices 16(1)-16(n), which redirects the requesting one of the client devices 16(1)-16(n) to the selected one of the other plurality of service provider server devices 14(2)-14(n) with the generated token. As part of a registration process the E-IdP device 12 registers URI for each of the other plurality of service provider server devices 14(2)-14(n) in the memory and based on a service provider server selected, the requesting one of the client devices 16(1)-16(n) are redirected back to the registered redirect URI associated with the selected service provider server device. The redirect request redirects the requesting one of the client devices 16(1)-16(n) to the selected one of the other plurality of service provider server devices 14(2)-14(n) with the token for accessing one or more applications associated with the selected one of the plurality of service provider server devices 14(2)-14(n) and the method proceeds to step 360 and ends.

If back in step 345 the E-IdP device 12 determines, that the determined selection in step 340 is not selecting one of the other plurality of service provider server devices 14(2)-14(n) then the method takes the No branch and proceeds to step 355. By way of example, when the E-IdP device 12 determines that in step 340 intended service provider server devices 14(1) is selected over the other plurality of service provider server devices 14(2)-14(n), then the method takes the No branch and proceeds to step 355. By way of example, E-IdP device 12 selects the service provider server device 14(1) as it is determined in step 335 that the service provider server device 14(1) has a current load parameters value of 40% which is the least current load parameter value in comparison to all of the other service provider server devices 14(2)-14(n) and the method proceeds to step 355.

In step 355, the E-IdP device 12 redirects the requesting one of the client devices 16(1)-16(n) to the selected intended service provider server device 14(1) with the generated token for accessing one or more applications associated with the selected intended service provider server device 14(1). The E-IdP device 12 may send a redirect request to the requesting one of the client devices 16(1)-16(n), which redirects the requesting one of the client devices 16(1)-16(n) to the selected intended service provider server device 14(1) with the generated token. As part of a registration process the E-IdP device 12 registers URI for each of the plurality of service provider server devices 14(1)-14(n) in the memory and based on a service provider server selected, the requesting one of the client devices 16(1)-16(n) are redirected back to the registered redirect URI associated with the selected service provider server devices. The redirect request redirects the requesting one of the client devices 16(1)-16(n) to the selected intended service provider server device 14(1) with the token for accessing one or more applications associated with the selected intended service provider server device 14(1) and the method proceeds to step 360 and ends.

An exemplary method of load balancing in a federated identity environment and devices thereof will now be described with reference to FIGS. 1-4. Specifically, referring to FIG. 4 an example of a method for load balancing in a federated identity environment and devices. Flow of the FIG. 4 includes one or more client devices 16(1)-16(n), E-IdP device 12, one or more service provider server devices 14(1)-14(n) and one or more backend application server devices 20(1)-20(n).

In step 1, the client device sends an application access request to an intended service provider server-1 to access application associated with the service provider server-1. As the request is sent to the service provider server-1, the service provider server-1 is intended to service the request by providing the client access to one or more backend application servers associated with the service provider server-1. The service provider server-1 is also referred to in the examples herein as the intended service provider server.

In step 2, upon receiving the application access request, the service provider server-1 sends a redirected authentication request that redirects the client device to an E-IdP device 12 for user authentication. The redirected authentication request redirects the client device to the E-IdP device 12 for user authentication.

In step 3, the client device follows the redirected authentication request to the E-IdP device 12 for user authentication. The redirected authentication request redirects the client device to the E-IdP device 12 for authentication. The E-IdP device 12 receives the redirected authentication request from the client device.

In step 4 the received redirected authentication request from the client device which was redirected by the service provider server-1 is authenticated. After receiving the authentication request, the E-IdP device 12 collects identity information from the user of the client device to authenticate the user of the client device and a determination is made when the request is authenticated. The E-IdP device 12 performs authentication of the request by associating the stored user identity information with the collected user identification information to authenticate the request. After the E-IdP device 12 performs authentication of the request, a token is generated which is utilized later for validation of the request.

In step 5, the E-IdP device 12 sends a redirected error notification request, when it is determined that the authentication request fails authentication and that the request is not authenticated in step 4. The E-IdP device 12 sends a redirected error notification request that redirects the client device to the service provider server-1.

In step 6, the client device follows the redirected error notification request to the service provider-1 notifying the service provider server-1 that the request has failed authentication.

In step 7 the E-IdP device 12 generates a token, when it is determined that the request is authenticated back in step 4. The E-IdP device 12 generates a token in response to the request being authenticated, and this token is utilized for validation. The utilization of token for validation is explained below.

In step 8, the E-IdP device 12 periodically monitors one or more parameters of the plurality of service provider server device 1-n and performs comparison between the service provider server device-1 and the other plurality of service provider server devices 2-n. The E-IdP device 12 periodically monitors one or more network parameters for the plurality of service provider server device 1-n which are utilized to perform the comparison. By way of example, the one or more network parameters may include, a current load parameter, a server health parameter, and/or geographic location parameter associated with the plurality of service provider server devices 1-n, although other types and/or numbers of parameters may be used. The E-IdP device 12 periodically monitors one or more network parameter and collects one or more network parameter data values associated with the one or more network parameters. By way of example, the one or more network parameter data values may include, a current load value, a server health value, and/or geographic location value associated with the plurality of service provider server devices 1-n, although other types and/or numbers of parameter data values may be used. The collected one or more network parameters values for the plurality of service provider server devices 1-n are utilized for comparison.

The E-IdP device 12 compares the collected one or more network parameter values associated with the intended service provider server device 1 against corresponding other one or more network parameter values associated with the other of the plurality of service provider server devices 2-n. By way of example, the one or more network parameter data values may include, a current load value, a server health value, and/or geographic location value associated with the plurality of service provider server devices 1-n, although other types and/or numbers of parameter values may be used. By way of example, the E-IdP device 12 compares the current load value associated with the service provider server device-1 with each of the corresponding current load values associated with the service provider server devices 2-n. By way of example, the E-IdP device 12 compares the CPU utilization value associated with the service provider server device-1 with each of the corresponding CPU utilization values associated with the service provider server devices 2-n. In another example, the E-IdP device 12 compares the server health value associated with the service provider server device-1 with corresponding each of the server health value associated with the service provider server devices 2-n. In yet another example, the E-IdP device 12 compares the geographic location value associated with the service provider server device-1 with each of the corresponding geographic location value associated with the service provider server devices 2-n. The detecting of the hardware deficiencies or failures in the service provider server devices 1-n is performed to identify potential issues in the service provider server devices 1-n.

Further, the E-IdP device 12 performs the comparing, for example, by comparing the current load parameter value of the intended service provider server device 1 with the current load parameter value of the other service provider server devices 2-n. The current load parameter value of the plurality of service provider server devices 1-n may be the current load capacity of the server determined based on the number of processes waiting in a queue to access a processor of the associated service provider server devices 1-n for a specific time period. The smaller the current load means more resources available to process the requests and hence better performance state of the service provider server devices 1-n. Based on the comparison the capacity of current load for each of the plurality of service provider server devices 1-n is determined. By way of example, the current load parameter value for the intended service provider server device 1 may be determined at 60% of its capacity and further the current load parameter value associated with the other service provider server devices 2-n are all determined to be less than 60% of their capacity. In another example, the current load parameter value for the intended service provider server device 1 may be determined at 60% of its capacity and further the current load parameter value associated with the other service provider server devices 2-n are all determined to be more than 60% of their capacity. Further, by way of another example, the comparison may also determine the current load parameter value associated with the intended service provider server device 1 is the same as that of the other service provider server device 2-n.

The health parameter associated with service provider server devices 1-n for example helps in determining the performance of the service provider server devices 1-n. The health parameters include server response time of the service provider server devices 1-n, hardware failures or deficiencies associated with the service provider server devices 1-n, CPU utilization associated with the service provider server devices 1-n, server heartbeats associated with the service provider server devices 1-n. Although, any other parameters associated with determining health of the service provider server devices may also be included. The monitoring of the server response times is performed to determine potential latency issues for the service provider server devices 1-n. By way of example, the comparison may be determine that the server response time of the intended service provider server device 1 is 50 ms and the server response time associated with each of the other service provider server devices 2-n is less than 50 ms. In another example, the comparison may be determine that the server response time of the intended service provider server device 1 is 50 ms and the server response time associated with each of the other service provider server devices 2-n is more than 50 ms. Further, by way of another example, the comparison may also determine the server response time parameter value associated with the intended service provider server device 1 is the same as that of the other service provider server device 2-n.

The monitoring of the CPU utilization of a server is performed to determine memory utilization of the server, high CPU utilization may cause alerts of performance issues with the service provider server devices 1-n. By way of example, the comparison may be determine that the CPU utilization of the intended service provider server device 1 is 65% of its usage capacity and the CPU utilization associated with each of the other service provider server devices 2-n is less than 65%. In another example, the comparison may be determine that the CPU utilization of the intended service provider server device 1 is 65% of its usage capacity and the CPU utilization associated with each of the other service provider server devices 2-n is more than 65%. Further, by way of another example, the comparison may also determine the CPU utilization parameter value associated with the intended service provider server device 1 is the same as that of the other service provider server device 2-n.

The heartbeat of the service provider server devices 1-n may be determined by sending a network ping command or a heartbeat message to the service provider server devices 1-n, and a response to the ping command provides information of the service provider server devices 1-n being alive and accepting communications. By way of example, the comparison may be determine that the response time to the ping for determining the heartbeat of the intended service provider server device 1 is 20 ms and the response time to the ping for determining the heartbeat associated with each of the other service provider server devices 2-n is less than 20 ms. In another example, the comparison may be determine that the response time to the ping for determining the heartbeat of the intended service provider server device 1 is 20 ms and the response time to the heartbeat message for determining the heartbeat associated with each of the other service provider server devices 2-n is more than 20 ms. Further, by way of another example, the comparison may also determine the response time parameter value associated with the intended service provider server device 1 is the same as that of the other service provider server device 2-n.

The geographic location parameter of the service provider server devices 1-n may be determined as a distance between geographic location of the service provider server devices 1-n potentially servicing the request and the requesting one of the client devices 16(1)-16(n) requesting to access the application. Lesser the distance lesser would be the latency, number of hops, and lesser would be a potential of hardware failure as the number of hardware components are reduced with lesser distance. By way of example, the comparison may be determine that the geographic distance between the intended service provider server device 1 and the requesting one of the client devices 16(1)-16(n) is less than and the distance associated with each of the other service provider server devices 2-n. In another example, the comparison may be determine that the geographic distance between the intended service provider server device 1 and the requesting one of the client devices 16(1)-16(n) is more than and the distance associated with each of the other service provider server devices 2-n. Further, by way of another example, the comparison may also determine the geographic distance associated with the intended service provider server device 1 is the same as that of the other service provider server device 2-n.

In another embodiment, if in the comparison step 8 the one or more of the other service provider server devices 1-n has a current load parameter equal to the current load parameter of the intended service provider server devices 1-n, then the intended service provider server is selected. In another embodiment, when the one or more of the other service provider server devices 1-n has a current load parameter equal to the current load parameter of the intended service provider server, then the one or more of the other service provider servers devices 1-n may be selected over the intended service provider server. In another embodiment, more than one other service provider server devices 1-n may be selected.

In yet another embodiment, the comparison may be performed by comparing more than one parameters of the service provider server devices 1-n based on priorities assigned to the parameters. By way of example, the comparison may be performed by comparing the current load parameter, the health parameter and the geographic location parameter for the intended service provider server and the other service providers based on priorities assigned to each of the parameters. The current load parameter may be assigned the highest priority rank of 1 followed by the health parameter having a lower priority rank of 2 and the geographic location parameter having the least priority rank of 3. Although other types and/or numbers of other parameter comparison may be performed with any number of priorities.

In step 9, the E-IdP device 12 selecting one of the other plurality of service provider server devices 2-n based on the comparison of step 8 and one or more selection rules stored in the memory 26. The stored selection rules, may include, selecting the service provider server device with the least current load parameter value, selecting the service provider server device with the least response time, selecting the service provider service device with the least CPU utilization, selecting the service provider service device with the least response time for heartbeat messages, selecting the service provider service device with least geographic distance between the client devices 16(1)-16(n) and the service provider server devices 1-n. Further, the selection rules may include, when the one or more network parameter values between the intended service provider server device 1 and the other service provider server devices 2-n are equal, then selecting the intended service provider server device 1. Based on the selection rules, the E-IdP device 12 selects of a service provider server device that would process the request from the service provider server devices 1-n.

Specifically, the selection rules, may include, by way of example, selecting one of the other service provider server devices 2-n when the comparison indicates that the current load parameter value for the intended service provider server device 1 may be determined at 60% of its capacity and further the current load parameter value associated with the other service provider server devices 2-n are all determined to be less than 60% of their capacity. In this example, from the other service provider server devices 2-n the E-IdP device 12 selects the service provider server device with the least current load parameters. By way of example, E-IdP device 12 selects the service provider server device 2 as it is determined in step 8 that the service provider server device 2 has a current load parameters value of 40% and is the least in comparison to all of the other service provider server devices 1, 3-n. By way of example, another selecting rules may include, selecting the intended service provider server device 1 when the comparison of step 8 determines that the current load parameter value for the intended service provider server device 1 may be determined at 60% of its capacity and further the current load parameter value associated with the other service provider server devices 2-n are all determined to be more than 60% of their capacity. In this example, as the intended service provider server device 1 has the least current load parameter value it is selected.

In another example, the selection rules, may include, by way of example, selecting one of the other service provider server devices 2-n when the comparison of step 8 determines that the response time of the intended service provider server device 1 is 50 ms and the response time associated with each of the other service provider server devices 2-n is less than 50 ms. In this example, from the other service provider server devices 2-n the E-IdP device 12 selects the service provider server device with the least response time value. By way of example, E-IdP device 12 selects the service provider server device 2 as it is determined in step 8 that the service provider server device 2 has a response time value of 30 ms and is the least response time in comparison to all of the other service provider server devices 1, 3-n. By way of example, another selecting rules may include, selecting the intended service provider server device 1 when the response time of the intended service provider server device 1 is 50 ms and the response time associated with each of the other service provider server devices 2-n is more than 50 ms. In this example, from the other service provider server devices 1-n the E-IdP device 12 selects the service provider server device with the least response time value. By way of example, E-IdP device 12 selects the service provider server device 1 as it is determined in step 8 that the service provider server device 1 has a response time value of 50 ms, which is the least response time in comparison to all of the other service provider server devices 2-n.

In another example, the selection rules, may include, by way of example, selecting one of the other service provider server devices 2-n when the comparison of step 8 determines that the CPU utilization of the intended service provider server device 1 is 65% and the CPU utilization associated with each of the other service provider server devices 2-n is less than 65%. In this example, from the other service provider server devices 2-n the E-IdP device 12 selects the service provider server device with the least CPU utilization value. By way of example, E-IdP device 12 selects the service provider server device 2 as it is determined in step 8 that the service provider server device 2 has a CPU utilization value of 45% and is the least CPU utilization in comparison to all of the other service provider server devices 1, 3-n. By way of example, another selecting rules may include, selecting the intended service provider server device 1 when the CPU utilization of the intended service provider server device 1 is 65% and the CPU utilization associated with each of the other service provider server devices 2-n is more than 65%. In this example, from the other service provider server devices 1-n the E-IdP device 12 selects the service provider server device with the least CPU utilization value. By way of example, E-IdP device 12 selects the service provider server device 1 as it is determined in step 8 that the service provider server device 1 has a CPU utilization value of 65%, which is the least CPU utilization in comparison to all of the other service provider server devices 2-n.

In another example, the selection rules, may include, by way of example, selecting one of the other service provider server devices 2-n when the comparison of step 8 determines that the geographic distance between the intended service provider server device 1 and the requesting one of the client devices 16(1)-16(n) is more than and the geographic distance between each of the other service provider server devices 2-n and the requesting one of the client devices 16(1)-16(n). In this example, from the other service provider server devices 2-n the E-IdP device 12 selects the service provider server device with the least geographic distance between each of the other service provider server devices 2-n and the requesting one of the client devices 16(1)-16(n). By way of example, E-IdP device 12 selects the service provider server device 2 as it is determined in step 8 that the service provider server device 2 has the least geographic distance between each of the other service provider server devices 2-n and the requesting one of the client devices 16(1)-16(n) in comparison to all of the other service provider server devices 1, 3-n. By way of example, another selecting rules may include, selecting the intended service provider server device 1 geographic distance between the intended service provider server device 1 and the requesting one of the client devices 16(1)-16(n) is less than and the geographic distance between each of the other service provider server devices 2-n and the requesting one of the client devices 16(1)-16(n). In this example, from the other service provider server devices 1-n the E-IdP device 12 selects the service provider server device with the least geographic distance between each of the other service provider server devices 1-n and the requesting one of the client devices 16(1)-16(n). By way of example, E-IdP device 12 selects the service provider server device 1 as it is determined in step 8 that the service provider server device 1 has the least geographic distance to the requesting one of the client devices 16(1)-16(n) in comparison to all of the other service provider server devices 2-n.

In step 10, the E-IdP device 12 redirects the requesting one of the client devices 16(1)-16(n) to the selected one of the other plurality of service provider server devices 2-n with the generated token for accessing one or more applications associated with the selected one of one or more other of the plurality of service provider server devices 2-n. The E-IdP device 12 may send a redirect request to the requesting one of the client devices 16(1)-16(n), which redirects the requesting one of the client devices 16(1)-16(n) to the selected one of the other plurality of service provider server devices 2-n with the generated token. As part of a registration process the E-IdP device 12 registers URI for each of the other plurality of service provider server devices 2-n in the memory and based on a service provider server selected, the requesting one of the client devices 16(1)-16(n) are redirected back to the registered redirect URI associated with the selected service provider server device. The redirect request redirects the requesting one of the client devices 16(1)-16(n) to the selected one of the other plurality of service provider server devices 2-n with the token for accessing one or more applications associated with the selected one of the plurality of service provider server devices 2-n.

In step 11, the client device follows the redirect request from the E-IdP device 12 to the selected service provider server-n with the token generated in step 7.

In step 12, the selected service provider server-n performs the validation of the token. The service provider server-n performs a validation of the token to determine if the token is valid.

In step 13, the service provider server-n sends an error notification to the client device, when back in step 12 the validation fails and it is determined that the token is not valid. The service provider server-n sends an error notification to the client device, notifying the client device that the validation has failed.

In step 14 the service provider server-n allows the client device access to one or more applications, upon successful validation of the token back in step 12. The service provider server-n allows the client device access to one or more applications that are protected by the backend application server associated the service provider server-n.

In step 15 the client accesses the applications protected by the selected service provider-n, and in step 16 the selected service provider-n provides the client device access to applications at the backend server application associated with the service provider server-n. As a result based on the comparison the selected service provider server-n services the client device, this provides the advantage of dynamically servicing requests based on the current network status of the parameters of the service provider servers. This optimized process of processing requests and content delivery to client devices provides an optimal end-user experience.

In another example, back in step 9 of FIG. 4, when the E-IdP device 12 selects the service provider server device 1 based on the comparison of step 8 and one or more stored selection rules. The E-IdP device 12 sends a redirect message to the client device. In this example, the E-IdP device 12 redirects the requesting one of the client devices 16(1)-16(n) to the selected intended service provider server device 1 with the generated token for accessing one or more applications associated with the selected intended service provider server device 1. The E-IdP device 12 may send a redirect request to the requesting one of the client devices 16(1)-16(n), which redirects the requesting one of the client devices 16(1)-16(n) to the selected intended service provider server device 1 with the generated token. As part of a registration process the E-IdP device 12 registers URI for each of the plurality of service provider server devices 1-n in the memory and based on a service provider server selected, the requesting one of the client devices 16(1)-16(n) are redirected back to the registered redirect URI associated with the selected service provider server devices. The redirect request redirects the requesting one of the client devices 16(1)-16(n) to the selected intended service provider server device 1 with the token for accessing one or more applications associated with the selected intended service provider server device 1.

With this technology, load balancing of user traffic across multiple service providers is provided to select a service provider server based on multiple parameters for servicing user access request. Additional advantages of this technology include improved availability and manageability of applications by providing optimized load balancing and servicing of requests to select a service provider based on current status of network utilization dynamically and intelligently to provide optimal end-user experience.

Having thus described the basic concept of the invention, it will be rather apparent to those skilled in the art that the foregoing detailed disclosure is intended to be presented by way of example only, and is not limiting. Various alterations, improvements, and modifications will occur and are intended to those skilled in the art, though not expressly stated herein. These alterations, improvements, and modifications are intended to be suggested hereby, and are within the spirit and scope of the invention. Additionally, the recited order of processing elements or sequences, or the use of numbers, letters, or other designations therefore, is not intended to limit the claimed processes to any order except as may be specified in the claims. Accordingly, the invention is limited only by the following claims and equivalents thereto.

Claims

1. A method for load balancing in a federated identity environment implemented by a network traffic management system comprising one or more identity provider server devices, service provider server devices, backend application server devices or client devices, the method comprising: receiving a redirected authentication request from a client requesting access to an intended service provider server device of a plurality of service provider server devices, the authentication request originating from the intended service provider server device and being redirected through the client;generating a token in response to successfully authenticating the authentication request;comparing one or more network parameter values of the intended service provider server device against one or more network parameter values associated with each of the other service provider server devices of the plurality of service provider server devices;selecting a different service provider server device from among the other service provider server devices based on the comparison and one or more selection rules; andin response to successfully authenticating the authentication request, redirecting the client request to the selected different service provider server device instead of the intended service provider server device, and sending the generated token for accessing one or more applications associated with the selected different service provider server device to the client.

2. The method of claim 1, wherein the one or more network parameter values of a respective service provider server device comprises a current load parameter value indicative of a load capacity of the respective service provider server device.

3. The method of claim 1, wherein the one or more network parameter values of a respective service provider server device comprises a health parameter value indicative of a hardware failure of the respective service provider server device.

4. The method of claim 1, wherein the one or more network parameter values of a respective service provider server device comprises a geographic location parameter value indicative of a distance between a geographic location of the intended service provider server device and the respective service provider server device.

5. The method of claim 1, further comprising registering a uniform resource identifier (URI) for each of the plurality of service provider server devices with an identity provider, and wherein the client request is redirected to the selected different service provider server device using the registered URI of the selected different service provider server device.

6. An identity provider apparatus, comprising a memory with programmed instructions stored thereon and one or more processors configured to be capable of executing the stored programmed instructions to: receive a redirected authentication request from a client requesting access to an intended service provider server device of a plurality of service provider server devices, the authentication request originating from the intended service provider server device and being redirected through the client;generate a token in response to successfully authenticating the authentication request;compare one or more network parameter values of the intended service provider server device against one or more network parameter values associated with each of the other service provider server devices of the plurality of service provider server devices;select a different service provider server device from among the other service provider server devices based on the comparison and one or more selection rules; andin response to successfully authenticating the authentication request, redirect the client request to the selected different service provider server device instead of the intended service provider server device, and sending the generated token for accessing one or more applications associated with the selected different service provider server device to the client.

7. The apparatus of claim 6, wherein the one or more network parameter values of a respective service provider server device comprises a current load parameter value indicative of a load capacity of the respective service provider server device.

8. The apparatus of claim 7, wherein the one or more network parameter values of a respective service provider server device comprises a health parameter value indicative of a hardware failure of the respective service provider server device.

9. The apparatus of claim 7, wherein the one or more network parameter values of a respective service provider server device comprises a geographic location parameter value indicative of a distance between a geographic location of the intended service provider server device and the respective service provider server device.

10. The apparatus of claim 7, wherein the one or more processors are further configured to be capable of executing the stored programmed instructions to: register a uniform resource identifier (URI) for each of the plurality of service provider server devices with the identity provider apparatus, and wherein the client request is redirected to the selected different service provider server device using the registered URI of the selected different service provider server device.

11. A non-transitory computer readable medium having stored thereon instructions for load balancing in a federated identity environment comprising executable code which when executed by one or more processors, causes the one or more processors to: receive a redirected authentication request from a client requesting access to an intended service provider server device of a plurality of service provider server devices, the authentication request originating from the intended service provider server device and being redirected through the client;generate a token in response to successfully authenticating the authentication request;compare one or more network parameter values of the intended service provider server device against one or more network parameter values associated with each of the other service provider server devices of the plurality of service provider server devices;select a different service provider server device from among the other service provider server devices based on the comparison and one or more selection rules; andin response to successfully authenticating the authentication request, redirect the client request to the selected different service provider server device instead of the intended service provider server device, and sending the generated token for accessing one or more applications associated with the selected different service provider server device to the client.

12. The non-transitory computer readable medium of claim 11, wherein the one or more network parameter values of a respective service provider server device comprises a current load parameter value indicative of a load capacity of the respective service provider server device.

13. The non-transitory computer readable medium of claim 12, wherein the one or more network parameter values of a respective service provider server device comprises a health parameter value indicative of a hardware failure of the respective service provider server device.

14. The non-transitory computer readable medium of claim 12, wherein the one or more network parameter values of a respective service provider server device comprises a geographic location parameter value indicative of a distance between a geographic location of the intended service provider server device and the respective service provider server device.

15. The non-transitory computer readable medium of claim 12, wherein the executable code when executed by the one or more processors further causes the one or more processors to: register a uniform resource identifier (URI) for each of the plurality of service provider server devices with an identity provider, and wherein the client request is redirected to the selected different service provider server device using the registered URI of the selected different service provider server device.

16. A network traffic management system, comprising one or more traffic management apparatuses, client devices, or server devices, the network traffic management system comprising memory comprising programmed instructions stored thereon and one or more processors configured to be capable of executing the stored programmed instructions to: receive a redirected authentication request from a client requesting access to an intended service provider server device of a plurality of service provider server devices, the authentication request originating from the intended service provider server device and being redirected through the client;generate a token in response to successfully authenticating the authentication request;compare one or more network parameter values of the intended service provider server device against one or more network parameter values associated with each of the other service provider server devices of the plurality of service provider server devices;select a different service provider server device from among the other service provider server devices based on the comparison and one or more selection rules; andin response to successfully authenticating the authentication request, redirect the client request to the selected different service provider server device instead of the intended service provider server device, and sending the generated token for accessing one or more applications associated with the selected different service provider server device to the client.

17. The network traffic management system of claim 16, wherein the one or more network parameter values of a respective service provider server device comprises a current load parameter value indicative of a load capacity of the respective service provider server device.

18. The network traffic management system of claim 17, wherein the one or more network parameter values of a respective service provider server device comprises a health parameter value indicative of a hardware failure of the respective service provider server device.

19. The network traffic management system of claim 17, wherein the one or more network parameter values of a respective service provider server device comprises a geographic location parameter value indicative of a distance between a geographic location of the intended service provider server device and the respective service provider server device.

20. The network traffic management system of claim 17, wherein the one or more processors are further configured to be capable of executing the stored programmed instructions to: register a uniform resource identifier (URI) for each of the plurality of service provider server devices with an identity provider, and wherein the client request is redirected to the selected different service provider server device using the registered URI of the selected different service provider server device.