CN115134110B - Injection of risk assessment in user authentication - Google Patents

Abstract

The present disclosure relates to injecting risk assessment in user authentication. In a method for authenticating a user, a processor receives a login request for an application. The processor directs the login request to the collection page. The collection page may include an authentication script. The processor receives a risk assessment based on an identity authenticated by the authentication script. The processor grants a level of access to the application based on the risk assessment.

Description

Injecting risk assessment into user authentication

Technical Field

The present invention relates generally to the field of user authentication for applications, and more particularly to injecting a proxy in front of an application to enable authentication using an embedded collection page with additional authentication metrics.

Background Art

Many computer applications (including network applications) contain confidential, sensitive and/or restricted topics that are not meant to be accessed by the public. These computer applications can limit access to the topics by requiring authentication, so that users verify their identities. Authentication can involve verifying personal identity documents, verifying the authenticity of the website with a digital certificate, or requiring the user to perform a login operation. In computer security, logging in is the process in which an individual obtains access to a computer system by identifying and authenticating himself. User credentials can include a certain form of "user name" and a matching "password." Some applications may require a second factor such as an email or SMS confirmation for additional security.

Summary of the invention

Aspects of embodiments of the present invention disclose a method, computer program product, and computing system for authenticating a user. A processor receives a login request for an application. The processor directs the login request to a collection page. The collection page may include an authentication script. The processor receives a risk assessment based on an identity authenticated by the authentication script. The processor grants a level of access to the application based on the risk assessment.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 depicts a diagram of a user authentication environment according to one embodiment of the present invention;

2 depicts a flow chart of the steps of a risk assessment agent process performed within the user authentication system of FIG. 1 according to an embodiment of the present invention;

FIG3 depicts a visual representation of a login process determined by a risk assessment agent according to one embodiment of the present invention;

FIG4 depicts a visual representation of a login process determined by a risk assessment agent according to one embodiment of the present invention;

5 depicts a block diagram of components of a computing device, according to an illustrative embodiment of the invention.

DETAILED DESCRIPTION

The disclosed embodiments include devices and methods for adding authentication code snippets to applications without directly updating the login page of the application. Updating the login page of an application may be restricted for a variety of reasons. For example, an application may be managed with a strict change protocol that prohibits changing or increases the complexity and/or cost of changing the application. Moreover, an application may include an existing authentication mechanism that does not include pages that can be modified with new or additional login technologies. For example, in a single sign-on (SSO) architecture, users access applications based on approved devices. In such a case, users are granted direct access to the network application without accessing any login page.

The disclosed embodiments include adding a risk assessment agent that redirects login requests to an application to a collection page with one or more authentication scripts. The authentication script is used to collect additional login information for the login request. The additional information may include device information and behavioral biometric information, or any other authentication mechanism that does not already exist within the application. The collection page may include functionality to notify the completion of the collection and approval of the submission of the risk assessment request. Thus, the disclosed embodiments enable the system to embed authentication scripts to authenticate users and send backend requests for risk assessment without directly changing code or updating applications.

Turning now to the drawings, FIG1 illustrates a block diagram of a user authentication environment 100 according to an embodiment of the present invention. The user authentication environment 100 may include a client device 102 communicatively coupled within the user authentication environment 100 via a network 104. In some embodiments, the user authentication environment 100 may be implemented within a cloud computing environment, or use one or more cloud computing services. According to various embodiments, the cloud computing environment may include a network-based distributed/data processing system that provides one or more cloud computing services. Further, the cloud computing environment may include hundreds or thousands or more computers that are arranged within one or more data centers and configured to share resources via the network 104.

The network 104 is also communicatively coupled to the backend server 110, the access manager 112, and the target server 114. In certain embodiments of the user authentication environment 100, there may be more or fewer components than shown in FIG. 1. For example, the user authentication environment 100 may include many additional client devices 102 that communicate with the user authentication environment 100 via the network 104. In various embodiments, some or each of the components (e.g., the backend server 110, the access manager 112, and/or the target server 114) represent separate computing devices. Each of the disclosed devices (e.g., the client device 102, the target server 114, the access manager 112, and/or the backend server 110) may be configured to be the same or similar to the computing device 500 shown in FIG. 5. In some embodiments, some or each of the components represent a specific computing instance of a single computing device (e.g., a program module, a computing component within a chassis, a blade server within a blade housing, an input/output drawer, a processor chip, etc.). For example, the access manager 112 may be combined with the backend server 110 on a single server computing device. As disclosed herein, some or each of the components of backend server 110 , access manager 112 , and/or target server 114 may be generally referred to as a “server system.”

The user 122 uses the client device 102 to access information through the network 104. Specifically, the user 122 loads an application 130 that accesses a protected resource 132 stored on the target server 114. Access to the protected resource 132 is monitored or managed by the access manager 112. The application 130 may include a login function that requires a username and password to grant access to the protected resource 132. In some embodiments, the application 130 may also include functionality that allows access to the protected resource 132 based on the identification of the client device 102 (e.g., through an SSO page or a Kerberos-enabled operating system). In some of these embodiments, the application 130 may include a feature that cannot be updated (e.g., when the application 130 includes a policy that does not allow updates, or when the SSO architecture does not include a login page that can be modified). In such an embodiment, the application 130 may insert a risk assessment agent (agent 134) into the login process, which redirects the login request to the application 130 to the collection page 136. The agent may be logically and/or physically stored anywhere within the user authentication environment 100, but is shown as being activated and accessed by the application 130. The collection page 136 may include an authentication script that enables the access manager 112 to communicate with the collection tool 138 on the client device 102.

The collection tool 138 may collect behavioral biometric information, device information, or multi-factor authentication information and send it to the access manager 112. For example, the collection tool 138 may include a module to obtain a device identifier, or a code snippet for authentication of a device fingerprint. The collection tool 138 may also include other attribute collection modules that collect various attributes of the client device 102 or attributes of the user 122. The access manager 112 may communicate with the backend server 110 to authenticate the information collected by the collection tool 138. Specifically, the backend server may include stored identification information 140 to determine the identity associated with the information collected by the collection tool 138. The identification information 140 includes personalized information for each profile that is sought to access the protected resource 132. This may include historical user access data (e.g., where and when the user accessed the protected resource 132) or historical device access data (e.g., determining whether this is the first time the protected resource 132 has been accessed from the device).

For embodiments where the application 130 cannot be modified to update the login method, as described above, an agent 134 is added. The agent 134 operates the method depicted in Figure 2. The agent 134 receives a login request for the application 130 (box 202). The login request can be received from the client device 102 based on the user 122 selecting the application 130 or navigating to a link from a web page hosting the application. The login request can also include a username and password, an SSO authentication scheme, or a Kerberos-enabled authentication scheme. The agent 134 directs the login request to the collection page 136 (box 204). The collection page 136 includes one or more authentication scripts (e.g., Authentication Scripts) that collect additional user variables from the client device 102, the user 122, and/or the authentication tool 138. code, Java, and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates). For example, the authentication script may collect hashed usernames, user Internet Protocol (IP) addresses, user agents, browser information, etc. that application 130 does not collect and that application 130 cannot be programmed to collect.

Using the agent 134 to direct login requests includes the added ability to automatically adapt the collection page 136 to a plurality of various applications. Specifically, the agent 134 can utilize server-side technology to select from a plurality of collection pages 136 by configuring the agent 134. That is, the agent 134 can be programmed to direct login requests to several possible collection pages 136 based on the user 122, the client device 102, the application 130, or other factors. Additional collection pages 136 can be created and/or customized for specific applications 130 based on templates implemented for other applications. In addition, the login process of the customized agent 134 can include a client-side approach in which the authentication script is modified to manipulate and adapt the collection page 130. The agent 134 can therefore be added to an enterprise environment, and the user 122 can use the agent 134 to log in to a large number of applications 130. This one-page solution can serve all applications, allowing risk assessment to be performed with a relatively easy and streamlined implementation.

Once the authentication script collects the additional information, the collection page 136 may submit the collected identifiers to the backend server 110, or look up the information directly on the backend server 110. For example, the backend server 110 may include an opaque, non-personally identifiable profile of each user 122 that is authorized to access the application 130. The collection page 136 uses the information from the backend server 110 to determine a risk assessment associated with the user 122. For example, the risk assessment may include allowing the user to access the application, denying access to the application, or requesting multi-factor authentication.

The agent 134 then receives the risk assessment from the collection page 136 (box 206) and makes a determination as to whether the user 122 poses a high risk (box 208). If it is determined that the user 122 poses a high risk ("yes" for box 208), the user 122 is blocked from accessing the application (box 210). A high risk may be determined if the user 122 does not have a profile on the backend server 110, the profile does not contain sufficient information, and/or the information or user profile indicates that the user 122 should not be granted access to the application. If the user 122 does not pose a high risk ("no" for box 208), the agent 134 may also determine whether the user 122 poses a medium risk (box 212). If the user 122 does pose a medium risk ("yes" for box 212), the agent 134 uses a multi-factor authentication process (box 214). Risk levels such as medium risk and high risk are configurable based on the desired security attributes for protecting the protected resources 132. For example, in some embodiments, if user 122 attempts to log in from a client device that has never been certified, agent 134 may determine a medium risk. In other embodiments, a login from an uncertified client device may be determined to pose a high risk.

In certain embodiments of the present invention, the agent 134 may be configured to take various actions based on the risk level. The options shown may be a configuration of an application 130 with a level of sensitivity/confidentiality. The level of sensitivity/confidentiality may be based on business (e.g., organizational policy) or management (e.g., OpenBanking) requirements. For example, a low-risk application 130 (such as a travel booking site) may include an agent 134 that is configured to allow a medium-risk user 122 to log in directly without multi-factor authentication to view booking options. When the user 122 attempts to actually book a trip, then the user 122 will trigger a higher standard, and because they have been detected as a medium risk, the agent 134 will require the user 122 to complete the multi-factor authentication process at this time. The multi-factor authentication process may require additional information, metrics, or confirmation from the client device 102 or a different device to ensure that the medium level of risk is mitigated. If the multi-factor authentication is not passed (box 214 is "No"), the agent 134 blocks access to the application 130. If the multi-factor authentication passes ("yes" of block 214), or if the risk assessment is less than medium ("no" of block 212), the agent 134 grants access to the application 130 (block 216).

FIG. 3 depicts a visual representation of a user authentication process determined by a risk assessment agent according to one embodiment of the present invention. When a user uses a client device to initiate a user authentication process for an application 330, a login request 342 is generated by the user. The login request 342 is received by an agent 334 that has been injected into the user authentication process of the application 330. The agent 334 can determine a primary risk level based on the login request 342. For example, the agent can determine that the login request 342 can be initiated from a specific location (e.g., a field work location). If the primary risk level is low enough, the agent 334 can approve the login request 342 and grant access to the application 330 without further requests for information. In other cases where the primary risk level is not approved for immediate access, the agent 334 directs the login request to a collection page 336, which can request additional information from the client device that sent the login request 342. The collection page 336 can also access information from the backend server 310 containing information used to determine the risk assessment. Agent 334 receives the risk assessment and either grants access to application 330 , or directs login request 342 to a multi-factor authentication page 344 , which may then enable agent 334 to grant access to application 330 .

FIG. 4 depicts the login process of several embodiments of the present invention. A first login process 450 includes an SSO/Kerberos scheme without an agent 434. The first login process 450 proceeds from a login request 442 to access an application 430 without any possibility of performing a risk assessment. A second login process 452 includes an SSO/Kerberos scheme in which an agent 434 is inserted into the login process. The agent 434 directs the login request 442 to a collection page 436, which uses information from the login request 442 to perform a risk assessment. Depending on the level of risk determined at the collection page 436, the second login process 452 will proceed to the application 430 or to the multi-factor authentication page 444. If the multi-factor authentication page 444 approves the login request 442, the second login process 452 may also proceed from the multi-factor authentication page 444 to the application 430.

The third login process 454 does not use the SSO/Kerberos scheme and therefore may include a login page 428 that takes a username and password. The third login process 454 may still include a collection page 436 for further risk assessment of whether the login request 442 should be directed to the multi-factor authentication page 444. Although additional login steps may be included within the scope of the disclosed embodiments, the first login process 450, the second login process 452, and the third login process 454 illustrate that the addition of the agent 434 increases the adaptability of the risk assessment for logging into the application 430.

FIG5 depicts a block diagram of components of a computing device 500 according to an illustrative embodiment of the invention. As described above, in embodiments where the devices are embodied as components of a single computing device 500, the computing device 500 may represent any of the above devices (e.g., client device 102, target server 114, access manager 112, and/or backend server 110) or a combination of devices. It should be understood that FIG5 provides only an illustration of one implementation and does not imply any limitations regarding the environments in which different embodiments may be implemented. Many modifications may be made to the depicted environment.

Computing device 500 includes communications fabric 502 that provides communications between RAM 514, cache 516, memory 506, permanent storage 508, communications unit 510, and input/output (I/O) interface 512. Communications fabric 502 may be implemented with any architecture designed to pass data and/or control information between processors (such as microprocessors, communications and network processors, etc.), system memory, peripheral devices, and any other hardware components within the system. For example, communications fabric 502 may be implemented with one or more buses or crossbar switches.

Memory 506 and permanent storage 508 are computer-readable storage media. In this embodiment, memory 506 includes random access memory (RAM). In general, memory 506 may include any suitable volatile or non-volatile computer-readable storage media. Cache 516 is a fast memory that enhances the performance of computer processor 504 by saving recently accessed data and data that is close to being accessed from memory 506.

Software components (e.g., agents, applications, access managers, collection pages, authentication tools, or multi-factor authentication pages) may be stored in persistent storage 508 and memory 506 for execution and/or access by one or more of the corresponding computer processors 504 via cache 516. In an embodiment, persistent storage 508 includes a magnetic hard drive. Alternatively, or in addition to a magnetic hard drive, persistent storage 508 may include a solid-state hard drive, a semiconductor memory device, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), flash memory, or any other computer-readable storage medium capable of storing program instructions or digital information.

The media used by persistent storage 508 also may be removable. For example, a removable hard drive may be used for persistent storage 508. Other examples include optical and magnetic disks, thumb drives, and smart cards that are inserted into a drive for transfer to another computer-readable storage medium that is also part of persistent storage 508.

In these examples, communication unit 510 provides communications with other data processing systems or devices. In these examples, communication unit 510 includes one or more network interface cards. Communication unit 510 can provide communications using either or both physical and wireless communication links. Agents, applications, access managers, collection pages, authentication tools, or multi-factor authentication pages can be downloaded to permanent storage device 508 via communication unit 510.

The I/O interface 512 allows for input and output of data with other devices that may be connected to the computing device 500. For example, the I/O interface 512 may provide a connection to an external device 518 such as a keyboard, a keypad, a touch screen, and/or some other suitable input device. The external device 518 may also include a portable computer-readable storage medium such as, for example, a thumb drive, a portable optical or magnetic disk, and a memory card. Software and data (e.g., agents, applications, access managers, collection pages, authentication tools, or multi-factor authentication pages) for practicing embodiments of the present invention may be stored on such a portable computer-readable storage medium and may be loaded onto the permanent storage device 508 via the I/O interface 512. The I/O interface 512 is also connected to the display 520.

Display 520 provides a mechanism for displaying data to a user and may be, for example, a computer monitor.

The present invention may be a system, method and/or computer program product at any possible level of technical detail integration. The computer program product may include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon for causing a processor to execute various aspects of the present invention.

Computer readable storage medium can be a tangible device that can retain and store instructions for use by instruction execution devices. Computer readable storage medium can be, for example but not limited to, electronic storage device, magnetic storage device, optical storage device, electromagnetic storage device, semiconductor storage device or any suitable combination of the above. A non-exhaustive list of more specific examples of computer readable storage medium includes the following: portable computer disk, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanical encoding device such as punch card or a protruding structure in a groove with instructions recorded thereon, and any suitable combination of the above. Computer readable storage medium as used herein should not be interpreted as a temporary signal itself (such as radio waves or other free propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (for example, light pulses passing through optical fiber cables) or electrical signals transmitted by wires).

The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing/processing device via a network (e.g., the Internet, a local area network, a wide area network, and/or a wireless network), or downloaded to an external computer or external storage device. The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and/or edge servers. The network adapter card or network interface in each computing/processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing/processing device.

The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, configuration data of integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages (such as Smalltalk, C++, etc.) and process programming languages (such as "C" programming languages or similar programming languages). The computer-readable program instructions can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer, partially on the remote computer, or completely on the remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network (including local area network (LAN) or wide area network (WAN)), or can be connected to an external computer (for example, using an Internet service provider through the Internet). In some embodiments, the electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA) or a programmable logic array (PLA) can be executed by using the state information of the computer-readable program instructions to personalize the electronic circuit to perform computer-readable program instructions, so as to perform various aspects of the present invention.

Here, various aspects of the present invention are described with reference to the flowcharts and/or block diagrams of the methods, devices (systems) and computer program products according to embodiments of the present invention. It should be understood that each box of the flowchart and/or block diagram and the combination of each box in the flowchart and/or block diagram can be implemented by computer-readable program instructions.

These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions/actions specified in the box or multiple boxes of the flowchart and/or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium, which directs the computer, programmable data processing device, and/or other equipment to work in a specific manner, so that the computer-readable storage medium in which the instructions are stored includes a manufactured product including instructions for implementing various aspects of the functions/actions specified in the box or multiple boxes of the flowchart and/or block diagram.

Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, so that a series of operating steps are performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions/actions specified in a box or multiple boxes of the flowchart and/or block diagram.

The flow charts and block diagrams in the accompanying drawings show the architecture, functions and operations of the possible implementations of the systems, methods and computer program products according to various embodiments of the present invention. To this end, each box in the flow chart or block diagram may represent a module, segment or part of an instruction including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the box may not occur in the order marked in the figure. For example, depending on the functions involved, the two boxes shown in succession can actually be completed as a step, and are executed simultaneously, substantially simultaneously, in a partially or completely overlapping manner in time, or the boxes can sometimes be executed in the opposite order. It should also be noted that each box in the block diagram and/or flow chart, and the combination of the boxes in the block diagram and/or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

Claims (26)

1. A computer-implemented method for authenticating a user, comprising: receiving a login request to an application, wherein the application controls user access to protected resources; directing the login request to a collection page, wherein the collection page includes an authentication script that collects additional login information for the login request, wherein the collection page is selected from a plurality of collection pages based on the application; receiving a risk assessment based on an identity authenticated by the authentication script; and A level of access to the application is granted based on the risk assessment. 2. The method of claim 1, wherein the login request comprises a selection from the group consisting of: (i) a username and password, (ii) a single sign-on (SSO) authentication scheme, and (iii) a Kerberos-enabled authentication scheme. The method of claim 1 , wherein the login request includes information identifying the application. 4. The method of claim 1, wherein the selection of the collection page is further based on a selection from the group consisting of: user identity, client device. 5. The method of claim 1, wherein the authentication script collects user variables selected from the group consisting of: a hashed username, a user IP address, a user agent, and a browser. 6. The method of claim 1, wherein the risk assessment is received from a backend server that includes an opaque, non-personally identifiable profile associated with the identity. 7. The method of claim 1, wherein the access level comprises a selection from the group consisting of: allowing the user to access the application, denying access to the application, and requesting multi-factor authentication. The method of claim 1 , comprising determining a primary risk level based on the login request. 9. A computer program product for authenticating a user, the computer program product comprising: One or more computer-readable storage media and program instructions stored on the one or more computer-readable storage media, the program instructions comprising: program instructions for receiving a login request for an application, wherein the application controls user access to protected resources; program instructions for directing the login request to a collection page, wherein the collection page includes an authentication script that collects additional login information for the login request, wherein the collection page is selected from a plurality of collection pages based on the application; program instructions for receiving a risk assessment based on an identity authenticated by the authentication script; and Program instructions for granting a level of access to the application based on the risk assessment. 10. The computer program product of claim 9, wherein the login request comprises a selection from the group consisting of: (i) a username and password, (ii) a single sign-on (SSO) authentication scheme, and (iii) a Kerberos-enabled authentication scheme. 11. The computer program product of claim 9, wherein the login request includes information identifying the application. 12. The computer program product of claim 9, wherein the authentication script comprises a code snippet for authenticating a device fingerprint. 13. The computer program product of claim 9, wherein the authentication script collects user variables including those selected from the group consisting of: a hashed username, a user IP address, a user agent, and a browser. 14. The computer program product of claim 9, wherein the risk assessment is received from a backend server that includes an opaque, non-personally identifiable user profile associated with the identity. 15. The computer program product of claim 9, wherein the access level comprises a selection from the group consisting of: allowing the user to access the application, denying access to the application, and requesting multi-factor authentication. 16. A computer system for authenticating a user, the computer system comprising: One or more computer processors, one or more computer-readable storage media, and program instructions stored on the computer-readable storage media for execution by at least one of the one or more processors, the program instructions comprising program instructions for: program instructions for receiving a login request for an application, wherein the application controls user access to protected resources; program instructions for directing the login request to a collection page, wherein the collection page includes an authentication script that collects additional login information for the login request, wherein the collection page is selected from a plurality of collection pages based on the application; program instructions for receiving a risk assessment based on an identity authenticated by the authentication script; and Program instructions for granting a level of access to the application based on the risk assessment. 17. The computer system of claim 16, wherein the login request comprises a selection from the group consisting of: (i) a username and password, (ii) a single sign-on (SSO) authentication scheme, and (iii) a Kerberos-enabled authentication scheme. 18. The computer system of claim 16, wherein the login request includes information identifying the application. 19. The computer system of claim 16, wherein the authentication script includes a code snippet for authenticating a device fingerprint. 20. The computer system of claim 16, wherein the risk assessment is received from a backend server that includes an opaque, non-personally identifiable user profile associated with the identity. 21. The system of claim 16, wherein the access level comprises a selection from the group consisting of: allowing the user to access the application, denying access to the application, and requesting multi-factor authentication. 22. A computer-implemented method for authenticating a user, comprising: inserting an agent into a login process of an application, wherein the application controls user access to protected resources, wherein the agent accesses a collection page including an authentication script that collects additional login information for a login request, wherein the collection page is selected from a plurality of collection pages based on the application; performing a risk assessment based on identity information collected on a client device running the application; A level of access to the application is granted based on the risk assessment. 23. The method of claim 22, wherein the access level comprises a selection from the group consisting of: allowing the user to access the application, denying access to the application, and requesting multi-factor authentication. 24. The method of claim 22, wherein the selection of the collection page is further based on a selection from the group consisting of: user identity, client device. 25. A computer system comprising: processor; A computer readable storage medium coupled to the processor, the computer readable storage medium comprising instructions that when executed by the processor perform the method of any one of claims 22-24. 26. A computer program product comprising program code for performing the steps of the method as claimed in any one of claims 22 to 24 when executed by a processor.