RESILIENCY ARCHITECTURE FOR IDENTITY PROVISIONING AND VERIFICATION

Abstract

Identity access and management (“IAM”) systems with resiliency features and methods related to the same are provided. Two or more identity provider (“IDP”) systems each have a matching copy of user authentication data for users authorized to access the system of an organization. An identity proxy is interposed between user systems and each of the two or more IDP system. The identity proxy routes authentication requests, challenges, and responses between the user systems and the IDP systems based on availability.

Claims

1. An identity access and management (“IAM”) system having resiliency features, said IAM system comprising: one or more computerized systems associated with an organization and comprising data; two or more identity provider (“IDP”) systems, each comprising a matching copy of user authentication data for users authorized to access the one or more computerized systems and configured to provide authentication services for user systems attempting to access the one or more computerized systems; and an identity proxy interposed between user systems and each of the two or more IDP system, wherein said identity proxy is configured to route authentication requests, challenges, and responses between each respective one of the user systems and one of the two or more IDP systems based on availability of each of the two or more IDP systems.

2. The IAM system of claim 1 wherein: said identity proxy is configured to establish a hierarchy of the two or more IDP systems.

3. The IAM system of claim 2 wherein: said identity proxy is configured to: monitor for heartbeats from at least a primary designated one of the two or more IDP systems; while said heartbeats are received from said primary designated one of the two or more IDP systems, route the authentication requests, challenges, and responses from the user systems to the primary designated one of the two or more IDP systems; and where said heartbeats are not received from said primary designated one of the two or more IDP systems, route the authentication requests, challenges, and responses from the user systems to a secondary designated one of the two or more IDP systems.

4. The IAM system of claim 3 wherein: each of said two or more IDP systems are configured to regularly transmit said heartbeats indicating operational status to said identity proxy; and said identity proxy is configured to anticipate said heartbeats and determine that any of said two or more IDP systems from which one or more anticipated heartbeats is not received is unavailable.

5. The IAM system of claim 3 wherein: said identity proxy is configured to receive authentication requests and responses from each of the user systems, and encrypt the received authentication requests and responses with a certification and key issued by the organization for transmission to a respective one of said two or more IDP systems.

6. The IAM system of claim 5 wherein: said identity proxy is configured to receive authentication challenges from the respective one of said two or more IDP systems, and encrypt the received authentication challenges with a public key for transmission to one of said user systems from which an associated authentication request is received.

7. The IAM system of claim 3 wherein: said identity proxy is configured to resume routing the authentication requests, challenges, and responses from the user systems to the primary designated one of the two or more IDP systems upon resumption of receipt of the heartbeats from the primary designated one of the two or more IDP systems.

8. The IAM system of claim 3 wherein: said identity proxy is configured to: monitor for heartbeats from said secondary designated one of the two or more IDP systems; and continue routing the authentication requests, challenges, and responses from the user systems to the secondary designated one of the two or more IDP systems until a heartbeat is no longer received from the secondary designated one of the two or more IDP systems.

9. The IAM system of claim 1 wherein: the identity proxy is hosted at one or more cloud servers.

10. The IAM system of claim 9 wherein: each of the two or more IDP systems are hosted at one or more cloud servers.

11. The IAM system of claim 1 further comprising: a legacy IDP system associated with the organization and comprising the matching copy of the user authentication data.

12. The IAM system of claim 1 further comprising: a number of additional computerized systems, each associated with the organization and comprising different data, wherein each of the two or more IDP systems are configured to provide authentication services for the user systems attempting to access the number of additional computerized systems, and wherein each of the two or more IDP systems are configured to provide a single sign-on service for the one or more computerized systems and each of the number of additional computerized systems

13. The IAM system of claim 1 wherein: said identity proxy is designated as an identity service provider for each of said one or more computerized systems.

14. The IAM system of claim 13 wherein: said one or more computerized systems are configured to accept tokens from any of said two of more IDP systems.

15. A method for operating an identity access and management (“IAM”) system having resiliency features, said method comprising the steps of: electronically interposing a virtualized identity provider (“V-IDP”) system between user systems, a number of identity provider (“IDP”) systems, and computerized systems associated with an organization; receiving, at the V-IDP system, requests to access at least one of the computerized systems of the organization; determining an available one of the number of IDP systems; and routing the authentication request, and any issued challenges and response related to the same, to the available one of the number of IDP systems.

16. The method of claim 15 wherein: the number of IDP systems are arranged into a hierarchy; and the authentication request, and any issued challenges and responses related to the same, are routed to a highest ranked available one of the number of IDP systems.

17. The method of claim 16 wherein: the step of determining an available one of the number of IDP systems comprises the sub-steps of: monitoring for heartbeats from each of the number of IDP systems; and determining that a respective one of the number of IDP systems is unavailable when one or more of the heartbeats is not received from the respective one of the number of IDP systems.

18. The method of claim 16 wherein: the step of determining an available one of the number of IDP systems comprises the sub-steps of: monitoring for heartbeats from each of the number of IDP systems; and determining that a respective one of the number of IDP systems is available when one or more of the heartbeats is received from the respective one of the number of IDP systems.

19. The method of claim 15 wherein: the step of routing the authentication request, and any issued challenges and response related to the same, to the available one of the number of IDP systems comprises the sub-steps of: receiving the authentication request from a respective one of the user systems at the V-IDP system; encrypting the received authentication request with a certification and key issued by the organization; transmitting the encrypted authentication request to the available one of the number of IDP systems; receiving the issued challenges from the available one of the number of IDP systems; encrypting the issued challenges with a public key for transmission; transmitting the encrypted challenges to the respective one of the user systems; receiving the challenge responses from the respective one of the user systems at the V-IDP system; encrypting the received challenge responses with the certification and key issued by the organization; and transmitting the encrypted challenge responses to the available one of the number of IDP systems.

20. An identity access and management (“IAM”) system having resiliency features, said IAM system comprising: one or more computerized systems, each associated with an organization, comprising data regarding information or service, and configured to receive access requests to portions of the data; a database associated with the organization and comprising information regarding users authorized to access various portions of the data; two or more identity provider (“IDP”) systems, each comprising a matching copy of the information regarding the users authorized to access the portions of the data, wherein each of said two or more IDP systems are configured to: receive authentication requests from user systems attempting to access any portion of any of the number of systems; issue challenges to the user systems from which said authentication requests are received; receive responses from the user systems to which challenges are issued; compare said responses to said copy of the information regarding the users authorized to access the various ones of the number of systems to determine a match indicating authentication of requesting ones of the user systems; upon determination of a match, issue one or more tokens to the authenticated user systems; and periodically transmit a heartbeat signal indicating operability; an identity proxy electronically interposed between user systems and each of the two or more IDP systems, wherein said identity proxy is configured to: monitor for the heartbeat signals from each of the two or more IDP systems to determine availability of the two or more IDP providers; consult a hierarchy to determine a highest ranking one of the two or more IDP systems which is available; and route the authentication requests, challenges, and responses to the highest ranking one of the two or more IDP providers indicated as available upon receipt of a respective one of the authentication requests from a respective one of the user systems.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In addition to the features mentioned above, other aspects of the present invention will be readily apparent from the following descriptions of the drawings and exemplary embodiments, wherein like reference numerals across the several views refer to identical or equivalent features, and wherein:

[0016] FIG. 1 is a plan view of a prior art IAM system;

[0017] FIG. 2 is a plan view of another prior art IAM system providing a SSO feature;

[0018] FIG. 3 is a system diagram of an exemplary embodiment of the prior art IAM systems of FIGS. 1-2;

[0019] FIG. 4 is a plan view of an exemplary resilient IAM system utilizing multiple IDPs in accordance with the present invention;

[0020] FIG. 5 is a system diagram of an exemplary embodiment of the resilient IAM system of FIG. 4;

[0021] FIG. 6A is a flow chart with exemplary logic for operating the resilient IAM systems of FIGS. 4-5;

[0022] FIG. 6B is a flow chart with other exemplary logic for operating the resilient IAM systems of FIGS. 4-5;

[0023] FIG. 7 is a flow chart with other exemplary logic for operating the resilient IAM systems of FIGS. 4-5;

[0024] FIG. 8 is an exemplary workflow for the exemplary resilient IAM systems of FIGS. 4-5 where the primary IDP is active, and illustrating routing of authentication requests to the primary IDP;

[0025] FIG. 9 is an exemplary workflow for the exemplary resilient IAM systems of FIGS. 4-5 where the primary IDP is disrupted, and illustrating the routing of identity challenges between a secondary IDP and the user; and

[0026] FIG. 10 is an exemplary workflow for the exemplary resilient IAM system of FIGS. 4-5 where the primary IDP is disrupted, and illustrating routing of further authentication requests to the secondary IDP.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENT(S)

[0027] Various embodiments of the present invention will now be described in detail with reference to the accompanying drawings. In the following description, specific details such as detailed configuration and components are merely provided to assist the overall understanding of these embodiments of the present invention. Therefore, it should be apparent to those skilled in the art that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present invention. In addition, descriptions of well-known functions and constructions are omitted for clarity and conciseness.

[0028] Embodiments of the invention are described herein with reference to illustrations of idealized embodiments (and intermediate structures) of the invention. As such, variations from the shapes of the illustrations as a result, for example, of manufacturing techniques and/or tolerances, are to be expected. Thus, embodiments of the invention should not be construed as limited to the particular shapes of regions illustrated herein but are to include deviations in shapes that result, for example, from manufacturing.

[0029] FIG. 1 is a plan view of an exemplary conventional identity access and management (hereinafter also “IAM”) system 10A. An individual or entity 12 (hereinafter also the “user”) may request access to a system 16 which may be owned, operated, hosted, and/or managed by an individual or organization (hereinafter also the “organization”). The request may be routed to an identity provider 14 (hereinafter also the “IDP”) to authenticate the user. The IDP 14 may issue one or more challenges requesting the user 12 provide certain information to authenticate its purported identity. The user 12 may provide such information by way of one or more responses. If the one or more responses match user records held by the IDP 14, access may be granted. If not, access may be denied.

[0030] Access may be provided by issuance of a token from the IDP 14 to the user 12, which the user 12 may present to the system 16 to demonstrate that it has been authenticated by the IDP 14. The system 16 may issue a cookie to the user 12 to permit ongoing access during a session. The system 16 or organization may be in a trust relationship with the IDP 14. The IDP 14 may comprise a mirrored copy or sole copy of the records for the organization of the users authorized to access the system 16, and associated proper challenge responses.

[0031] The user 12, IDP 14, and/or system 16 may each comprise, or be hosted on, one or more computerized systems, including but not limited to, a personal computer, server, database, processor, electronic storage device, tablet, smartphone, combinations thereof, or the like. Communications between each of the user 12, IDP 14, and/or system 16 may be made by way of one or more networks 18. The network(s) 18 may comprise one or more of an internet, intranet, world wide web, cellular network, combinations thereof, or the like and may be wired, wireless, combinations thereof, or the like. While a single user 12 is illustrated, multiple users 12 of the same or different type may be authenticated using the IAM system 10A.

[0032] The requests from the IDP 14 and the responses received from the user 12 may be communicated to/from the IDP 14 without the user 12 knowing that it is communicating with the IDP 14, rather than the system 16 or the organization directly. For example, the challenges and responses may be gathered through an internet portal which appears as part of the organization. The IDP 14 may be owned, managed, and/or operated by the organization or a third-party.

[0033] The IDP 14 may be located on the organization's premises, such as in an organization owned, managed, and/or operated datacenter, or may be remote therefrom. The IDP 14 may be provided at a cloud system or may be a dedicated, enterprise system.

[0034] FIG. 2 illustrates another embodiment of the IAM system 10B, which may provide access to multiple systems 16A, 16B, 16C of the organization, or multiple organizations, through the IDP 14. For example, each system 16 may provide access to certain information, software, applications (software-as-a-services (hereinafter also “SaaS”)) or otherwise, combinations thereof, or the like. The IAM system 10B may provide a SSO or federated authentication solution.

[0035] FIG. 3 illustrates another embodiment of the IAM system 10C. Certain users 12A may be external to the organization, and other users 12B may be internal to the organization. The organization may include an on-premises data center 22 which may host a database 15 of users 12 authorized to access certain systems 16. The database 15 may comprise authentication information for each user. Such authentication information may include, for example, user names, passwords, security questions, answers, and images, security keys or other hardware devices, biometrics, tokens, cookies, network information, device information, one time access codes, combinations thereof, or the like. This information may be mirrored to the IDP 14. The systems 16 and/or IDP 14 may be hosted by one or more cloud services 20. The database 15 may be mirrored to the IDP 14 where there is compatibility.

[0036] FIG. 4 illustrates an IAM system with resilient architecture features 100A (hereinafter also the “resilient IAM system”) in accordance with the present invention. Similar components may be numbered similarly but increased by 100 (e.g., 12 to 112). The resilient IAM system 100A may comprise multiple IDPs 114A, 114B. An identity proxy 124 may be interposed between a user 112 and each of the multiple IDPs 114. The identity proxy 124 may also be interposed between the user 1112 and/or systems 116A, 1168, 116C. In this manner, access requests from the user 112 for any of the systems 116 may be routed through the identity proxy 124 for authentication by any of the IDPs 114. Such interposition may be accomplished by hardware (e.g., communication pathways) and/or software routines (e.g., commands). Alternatively, or additionally, authentication related communications may be formatted such that they must necessarily pass through the identity proxy 124 to be properly interpreted by the IDPs 114 and/or user 112.

[0037] The identity proxy 124 may be configured to route authentication requests from users 112 between the multiple IDPs 114. The identity proxy 124 may comprise, or be hosted on, one or more computerized systems such as but not limited to, computers, servers, electronic storage devices, combinations thereof, or the like. The identity proxy 124 may be owned, operated, and/or managed by the organization or a third-party. The identity proxy 124 may be hosted by on-premises datacenter(s) 112 for the organization, remote therefrom, or may be hosted by one or more cloud services 120. One or multiple systems 116 may be utilized. One or multiple users 112 may be authenticated. Two, three, four, or any number of IDPs 114 beyond just one may be utilized. The identity proxy 124 may be in electronic communication with the users 112, systems 116, and/or IDPs 114, such as by way of one or more networks 118.

[0038] FIG. 5 illustrates another exemplary embodiment of the resilient IAM system 1108 in accordance with the present invention. Users 112A, 1128 may be internal or external to the organization. Authentication information for users 112 authorized to access the systems 116 may be stored at one or more databases 115 and may be mirrored, or otherwise copied over, to each of the multiple IDPs 114A, 1148. In exemplary embodiments, without limitation, the database(s) 115 may be hosted by an on-premises datacenter 112. Alternatively, the authentication information may be stored at the multiple IDPs 114A, 114B such that the database 115 is not necessarily required. The database 115, where used, may be compatible with each of the multiple IDPs 114. The datacenter 115 may comprise a legacy IDP for the organization, though such is not required. At least the user base authentication data from the legacy IDP may be stored at each of the multiple IDPs 114. The authentication information may be synched between the database 115 and/or each of the multiple IDPs 114 and/or between the multiple IDPS 114. While two IDPs 114A, 114B are illustrated, any number of IDPs 114 above just one may be utilized.

[0039] The multiple IDPs 114 may be arranged into a hierarchy. For example, one of the IDPs 114 may be designated as a primary IDP 114A and another one of the multiple IDPs 114 may be designated as a secondary or backup IDP 1148. Where more than two IDPs 114 are utilized, the hierarchy may likewise continue (e.g., tertiary IDP, etc.). The identity proxy 124 may be configured to direct requests to the various IDPs 114 based on such an established hierarchy. For example, without limitation, the identity proxy 124 may be configured to direct requests to the primary IDP 114A unless and until certain criteria are met as further explained herein. This may include a disruption or other downtime event of the primary IDP 114A, overloading of the primary IDP 114A, a certain number of authentication requests has been sent to the primary IDP 114A, combinations thereof, or the like.

[0040] Some or all of the multiple IDPs 114 may be hosted at one or more cloud servers 102, though such is not required. In exemplary embodiments, each of the multiple IDPs 114 are hosted in physically disparate structure. Alternatively, or additionally, each of the multiple IDPs 114 may be hosted or otherwise provided by different parties. Some or all of the systems 116 may be hosted at one or more cloud servers 102, though such is not required. The database 115 may be hosted at one or more on-premise data centers 122, though such is not required. The identity proxy 124 may be hosted at one or more cloud servers 102, though such is not required.

[0041] FIG. 6A illustrates exemplary logic for operating the resilient IAM systems 110A, 1108. One of the multiple IDPs 114 may be designated as primary, and another of the multiple IDPs 114 may be designated as secondary, tertiary, etc. in a hierarchy for each of the IDPs 114 utilized with the resilient IAM system 110. At least the primary designated one of the multiple IDPs 114 may be configured to regularly transmit a heartbeat to the identity proxy 124 to establish its operational status. In exemplary embodiments, each of the multiple IDPs 114 are configured to regularly transmit a respective heartbeat to the identity proxy 124. So long as the expected heartbeats are received at the identity proxy 124 from at least the primary designated one of the multiple IDPs 114, the identity proxy 124 may be configured to route authentication requests received from the users 112, as well as any challenges and/or responses related to the same, to the primary designated one of the multiple IDPs 114. If the heartbeat is not received from at least the primary designated one of the multiple IDPs 114, the identity proxy 124 may be configured to begin routing authentication requests received from the users 112, and/or any challenges and/or responses related to outstanding authentication requests, to the secondary designated one of the multiple IDPs 114. Upon resumption of one or more heartbeats from the primary designated one of the multiple IDPs 114, the identity proxy 124 may be configured to resume routing of authentication requests received from the users 112 to the primary designated one of the multiple IDPs 114.

[0042] While discussion is occasionally made herein with regard to a primary and secondary IDP 114, the same logic may be used up and down the hierarchy with any number of IDPs 114 until the list of available IDPs 114 is exhausted. For example, without limitation, if the primary and secondary designated IDP 114 go down, a tertiary IDP 114 may be utilized. The tertiary IDP 114 may be utilized until the secondary or primary IDP 114 comes back online. Progression through the hierarchy may be linear (e.g., primary to secondary to tertiary to secondary to primary) or non-linear (e.g., primary to secondary to tertiary to primary).

[0043] Each of the multiple IDPs 114 may be configured to transmit the heartbeats to the identity proxy 124 in exemplary embodiments, such as at certain intervals, which may be the same or different and may vary. The identity proxy 124 may be configured to anticipate these heartbeats from each of the multiple IDPs 114, such as within a margin of time. The margin of time may be set to preference levels, account for relatively minor delays in signaling, combinations thereof, or the like. In exemplary embodiments, without limitation, the identity proxy 124 may be configured to switch to the secondary designated one of the multiple IDPs 114 upon missing a single one of the anticipated heartbeats. In other exemplary embodiments, without limitation, the identity proxy 124 may be configured to not switch to the secondary designated one of the multiple IDPs 114 until multiple heartbeats are missed, such as in a row, within a particular time frame, or within a predetermined number of heartbeats. The identity proxy 124 may be configured to continually monitor the operational status of each of the multiple IDPs 114. The heartbeat signal from each of the multiple IDPs 114 may have one or more unique characteristics such that the identity proxy 124 may distinguish between the various received heartbeats. Alternatively, the identity proxy 124 may be configured to monitor only the operational status of the currently designated one of the multiple IDPs 114.

[0044] The heartbeat may be any type or kind of electronic signal configured to indicate operational status. For example, without limitation, each heartbeat may be a ping, an authentication request, or an arbitrary data signal. The heartbeat may be the same or different across the multiple IDPs 114. The multiple IDPs 114 need not transmit the heartbeat at the same interval at all times. For example, without limitation, each of the IDPs 114 may transmit their respective heartbeats at different times or intervals, which may be altered. The identity proxy 124 may be configured to monitor for heartbeats within particular windows of time, which may be regular intervals or a particular period of time from the last received one of the heartbeats, for example. Other techniques for monitoring operational status of the multiple IDPs 114 may be utilized. The heartbeats may be provided continuously, periodically, and/or upon request by the identity proxy 124.

[0045] In exemplary embodiments, without limitation, the heartbeats may only be provided from the primary designated one of the multiple IDP 114. Upon loss of heartbeat from the primary designated one of the multiple IDP 114, the identity proxy 124 may be configured to begin routing operations to the secondary designated one of the multiple IDPs 114. The identity proxy 124 may be configured to resume operations with the primary designated one of the multiple IDP 114 when the heartbeat from the primary designated one of the multiple IDP 114 resumes. Heartbeats in such embodiments need not be transmitted from the secondary designated one of the multiple IDPs 114, though such heartbeats may be used in exemplary embodiments to verify operational status of the secondary designated one of the multiple IDPs 114, such as prior to switching operations. In some embodiments, the identity proxy 124 may be configured to issue requests to the various ones of the IDPs 114 for heartbeats or other indications of operational status.

[0046] FIG. 6B illustrates alternative logic for operating the resilient IAM system 110. The identity proxy 124 may be configured to continue routing authentication requests received from the users 112 to whichever one of the multiple IDPs 114 is currently being utilized, even where a heartbeat has been received from the previously utilized one of the multiple IDPs 114, until that particular one of the multiple IDPs 114 is found to be experiencing a downtime event, for example. For example, operations with the primary designated one of the multiple IDPs 114 may not immediately resume when the primary designated one of the multiple IDPs 114 comes back online, but instead switching back to the primary designated one of the multiple IDPs 114 may instead only occur when the currently utilized one of the multiple IDPs 114 (e.g., the secondary designated one of the multiple IDPs 114) experiences a downtime event or is otherwise determined to be unavailable, such as by loss of a heartbeat signal.

[0047] While discussion is sometimes made herein with regard to loss of a heartbeat signal as an indication of operational disruption, inconsistent, irregular, or otherwise unanticipated heartbeat signals may likewise be used to indicate operational disruption and trigger switching between the multiple IDP 114.

[0048] FIG. 7 illustrates alternative logic for operating the resilient IAM system 110. The identity proxy 124 may be configured to utilize a primary designated one of the multiple IDPs 114 unless and until certain criteria is met, at which time the identity proxy 124 may be configured to utilize a secondary designated one of the multiple IDPs 114. The criteria may include a percentage of operating capacity utilized at the primary designated one of the multiple IDPs 114, the number of authentication requests transmitted to the primary designated one of the multiple IDPs 114 within a given time period, a date, a time, combinations thereof, or the like.

[0049] The identity proxy 124 may be configured to switch back to the primary IDP 114 once the criteria is no longer met. Alternatively, the identity proxy 124 may be configured to continue using the secondary or other IDP 114 currently being utilized until the criteria is met for the currently utilized one of the multiple IDPs 114. The criteria may be a number, range, window, threshold, maximum, minimum, average, median, mode, combinations thereof, or the like.

[0050] In other exemplary embodiments, without limitation, the identity proxy 124 may be configured to regularly or randomly distribute authentication requests between the multiple IDPs 114, such as for load balancing.

[0051] While a primary and secondary designated one of the multiple IDPs 114 is discussed, the logic may be used with any number of IDPs 114. For example, without limitation, if a first and second one of the multiple IDPs 114 are determined to meet the same or different criteria, the identity proxy 124 may be configured to route received authentication requests to a third IDPs 114.

[0052] FIG. 8 illustrates an exemplary workflow using the identity proxy 124 and the multiple IDPs 114A, B, C. User requests for access to the systems 116 may be provided between the users 112 and the systems 116. Before access is granted, authentication challenges and responses may be passed between the users 112 and the identity proxy 124. The identity proxy 124 may be a virtual IDP such that the user 112 is unaware of which of the multiple IDPs 114 the user 112 is interacting with. Further, the user 112 may be unaware that they are interacting with the identity proxy 124 or an IDP 114 altogether as the authentication requests, challenges, responses, and the like may be handled through a portal, such as but not limited to an internet portal, that appears unchanged to the user 112.

[0053] The identity proxy 124 may be configured to forward the authentication requests, challenges, responses, and other information between the identity proxy 124 and the first, primary designated, highest ranking, and/or currently utilized one of the multiple IDPs 114 currently designated as available. Heartbeats may be received from each of the IDPs 114 at the identity proxy to establish availability based on operational status. Alternatively, or additionally, criteria may be tracked by the identity proxy 124 and/or provided by the IDPs 114 to establish availability.

[0054] Tokens or other authentication certification items may be provided from the authenticating one of the multiple IDPs 114 to the user client 112 by way of the identity proxy 124. In exemplary embodiments, the tokens may comprise SAML/OAUTH tokens. These tokens, or other authentication certification items, may be presented by the user 112 to the system(s) 116, which may be configured to grant access upon receipt of the same. Cookies, or other items indicating a prior grant of access, may be issued by the system(s) 116 to the client 112, such as to permit ongoing access during a session.

[0055] In exemplary embodiments, some or all of the data received at the identity proxy 124 may be mirrored or otherwise copied across the multiple IDPs 114. For example, without limitation, the access requests, challenges, responses, tokens, cookies, combinations thereof, or the like may be provided from the identity proxy 124 to each of the multiple IDPs 114 for storage such that upon switching to a different one of the multiple IDPs 114, the user 112 may be recognized and/or operations may continue in a seamless fashion. Some or all of such data may alternatively or additionally be copied over to the database 115. This may be accomplished in substantially real time, and/or after each exchange of information. In this way, a different one of the multiple IDPs 114 may be positioned to take over authentication operations for any other one of the multiple IDPs 114 no matter which step the disrupted IDP 114 is in the authentication process.

[0056] In exemplary embodiments, without limitation, users 112 may register their identity and authentication credentials with the primary IDP 114A and/or the database 115. The credentials may be mirrored in the other IDPs 114, such as the secondary and tertiary IDPs 114B, 114C. Applications 116 which authorize users 112 for access may register within the identity proxy 124 (also referred to herein as the “V-IDP” and/or “virtual IDP”) as their authentication service provider. This may be accomplished by installing a PKC of V-IDP 124 in the servers for the applications 116.

[0057] Exemplary authentication workflow with SAML (OAUTH) may use a sequence of interactions, such as shown in FIG. 8. First, a user 112 may contact one of the applications 116 for access. The application 116 may in turn redirect user's SAML (OAUTH) request to the V-IDP service 124. The V-IDP 124 may forward the request to the primary IDP 114A. Authentication challenges from the primary IDP 114A may be encrypted with a public key of the V-IDP 124, for example, which may forward the challenges to the user 112, such as after re-encryption. Responses from the user 112 may be received by the V-IDP 124, which may forward them to the primary IDP 114A, which may in turn respond with a SAML assertion authorizing the user 112. The V-IDP 124 may forward the SAML assertion to the user 112, who may use it to access the service from the original application 116 contacted.

[0058] When sending and/or receiving authentication challenges, authentication responses, SAML assertions, combinations thereof, or the like, the V-IDP 124 may be configured to decrypt the messages received and re-encrypts them, such as by using an organization issued certification and key, to indicate the V-IDP 124 as the sending party. Other identifications of the transmitting party may be utilized. When sending and/or receiving authentication challenges, authentication responses, SAML assertions, combinations thereof, or the like, the primary IDP 114A may challenge the user 112 requesting access with multi-factor challenges which may include a password, plus one or more of the following: device ID, OTP, hardware key, trusted device and/or biometrics such a facial, voice, fingerprint for example, without limitation.

[0059] As illustrated in FIG. 9 and FIG. 10, upon determination that a first, primary designated one, highest ranked one, and/or currently utilized one of the multiple IDPs 114A is experiencing a disruption, a downtime event, is unavailable, and/or is meeting certain criteria, the identity proxy 124 may be configured to begin routing authentication requests to a next available one of the multiple IDPs 114, which may be a second, secondary one, second highest ranked one, and/or not currently utilized one of the multiple IPDs 114B. The same or similar process may be utilized for any number of multiple IDPs 114, such as but not limited to a tertiary IDP 114C.

[0060] Each of the multiple IDPs 114 may be configured to issue the same or similar tokens or authentication documents. Alternatively, or additionally, each of the systems 116 may be configured to accept tokens or authentication documents from any of the multiple IDPs 114.

[0061] A single or multiple authentication challenges and responses or other authentication techniques may be utilized. Any number or type of authentication techniques may be utilized such as but not limited to user names, passwords, security questions, answers, and images, security keys or other hardware devices, biometrics, tokens, cookies, network information, device information, and one time access codes, to name a few examples. Some or all of the multiple IDPs 114 may be configured to run various risk models to determine the type, kind, or number of authentication factors to utilize, which may be the same or difference across the multiple IDPs 114.

[0062] In exemplary embodiments, each of the multiple IDPs 114 are hosted on physically disparate infrastructure, such as but not limited to, different cloud service providers 120, though such is not required. The identity proxy 124 may act as a trusted proxy for each of the one or more systems 116. The identity proxy 124 may be hosted in a physically disparate infrastructure from some or all of the multiple IDPs 114, though such is not required. The systems 116 may be of the same or different organization. The systems 116 may be used for any type or kind of organization, or individual, to host or provide any type or kind of data, service, combinations thereof, or the like.

[0063] FIG. 9 illustrates exemplary work flows involved in the transport of challenge-response messages between the primary authentication service 114A and the user's 112 endpoint application (device). In exemplary embodiments, the V-IDP 124 has full awareness of all the challenge mechanisms and the sequence of messages involved between the user 112 and the primary IDP 114. The context is stored previously by the IDP 114 and retrieved when a user 112 first requests access. Several non-limiting examples are provided herein.

[0064] Password: A password challenge is first intercepted by the V-IDP 124. The challenge is re-encrypted, such as with the V-IDP's 124 private key(s) and sent to the user 112. When the user 112 responds with password (or its hash thereof), the V-IDP 124 may again intercept the response and re-encrypt the communication before sending to the primary IDP server 114A.

[0065] Biometric Factor: The challenge message requesting biometric may be forwarded first from primary IDP 114A to the identity proxy 124, which may in turn relay the challenge to the user 112 end. When user 112 responds with the biometric measurement response, V-IDP 124 may intercept the encrypted response, re-encrypt it, and forward it to the primary IDP 114A.

[0066] Two Factor Authentication, such as sent over a mobile: In this case, the second factor challenge (OTP) may be sent directly from the primary IDP 114A to the user 112 end point. The V-IDP 124 may not see the second factor challenge in exemplary embodiments. The challenge response, however, may be forwarded to the V-IDP 124, since the V-IDP 124 is perceived as the IDP 114 by the user 112 end point. In this case. The V-IDP 124 may have sufficient awareness of the sequence of messages involved in authenticating the user 112 based on the user's 112 identity, context, and/or behavioral history. When the V-IDP 124 receives the OTP response from the user 112 end point, the V-IDP 124 may interpret it as a valid message and forward it to the primary IDP server 114A as in the previous two cases. This flow is illustrated by the “2nd factor authentication” messages shown in FIG. 9.

[0067] Exemplary sequences of messages involved in the event of the failure of the primary IDP 114A are shown in FIG. 10. A heartbeat may be sent from all the IDPs 114 to the V-IDP 124, such as at regular time intervals. When the heartbeat of the primary IDP 114A fails, this may indicate to the V-IDP 124 that a switch over of the IDP service from the primary IDP 114A to the secondary IDP 1148 should be performed. Accordingly, the V-IDP 124 may redirect all new requests for authentication to the secondary IDP 114B. Previously issued SAML tokens may be stored in the users' 112 browsers and client applications 116 in case they are required for persistence, and may be re-presented to the original service 116 which requires federated identity verification in the primary IDP 114A. It may not necessarily be required that the state of the primary IDP 114A (beyond the long-term user credentials) be mirrored in the secondary or other IDPs 114. Other functions like disconnects, token expiries, and the like may be handled as if the primary IDP 114A were operational, in exemplary embodiments.

[0068] Resuming service when primary IDP is back and up: When the heartbeat from the primary IDP 114A resumes, the V-IDP 124 may suspend its SAML request redirections to the secondary IDP 1148 and may resume its previous relation with primary IDP 114A. The trust between the V-IDP 124 and the applications 116 may be established using PKCs signed with the enterprise's root certification authority, in exemplary embodiments. For example, without limitation, the SAML tokens issued by the IDPs 114 may be re-signed by V-IDP 124 using its PKC; and applications 116 may recognize this PKC and validate the tokens.

[0069] As illustrated in FIGS. 1-3, traditionally, organizations rely on a single IDP 14, which may result in business disruption in the event of any outage of the IDP 14. Even where certain market leading IDP solutions 14 are built for robustness, scalability and with redundant infrastructure and rolling upgrades, experience has demonstrated downtimes ranging from a few minutes to a few hours or more. The resilient IAM systems 110 shown and/or described herein proposes an improvement in which a near 100% uptime of IDP services are achievable, even in the event that any one identity service 114 goes down temporarily. Some situations in which the resilient IAM system 110 may provide a significant business benefit are, for example without imitation: insurance annual enrollment program where a service disruption could mean a loss of revenue and customer confidence; an ecommerce company during periods of high demand, such as during Christmas shopping period; the US government, such for the IRS during the annual tax filing season; or any critical service with high intensity—as for example with Covid-19 vaccinations. These are just a few examples provided without limitation. Any number or type of applications of the resilient IAM system 110 for authentication access to any type or kind of data or services may be realized with the resilient IAM system 110.

[0070] While certain references may be at time made herein to a primary or secondary designated IDP 114, the systems and methods shown and/or described herein may be used with any number of IDPs 114. Utilization of the IDPs 114 may be performed by the identity proxy 124 in accordance with an established hierarchy such that operations are performed with higher ranking, available ones of the multiple IDPs 114. In other exemplary embodiments, a strict hierarchy may not be required and operations may be directed to any available one of the multiple IDPs 114, such as randomly, by first to respond, last received heartbeat, combinations thereof, or the like.

[0071] While certain embodiments herein discuss cloud-based systems, non-cloud-based systems may be used instead of, and/or in conjunction with, such cloud-based systems.

[0072] Any embodiment of the present invention may include any of the features of the other embodiments of the present invention. The exemplary embodiments herein disclosed are not intended to be exhaustive or to unnecessarily limit the scope of the invention. The exemplary embodiments were chosen and described in order to explain the principles of the present invention so that others skilled in the art may practice the invention. Having shown and described exemplary embodiments of the present invention, those skilled in the art will realize that many variations and modifications may be made to the described invention. Many of those variations and modifications will provide the same result and fall within the spirit of the claimed invention. It is the intention, therefore, to limit the invention only as indicated by the scope of the claims.

[0073] Certain operations described herein may be performed by one or more electronic devices. Each electronic device may comprise one or more processors, electronic storage devices, executable software instructions, and the like configured to perform the operations described herein. The electronic devices may be general purpose computers or specialized computing device. The electronic devices may comprise personal computers, smartphones, tablets, databases, servers, or the like. The electronic connections and transmissions described herein may be accomplished by wired or wireless means. The computerized hardware, software, components, systems, steps, methods, and/or processes described herein may serve to improve the speed of the computerized hardware, software, systems, steps, methods, and/or processes described herein.