Computer-implemented method for authenticating a user, computer program for authenticating a user, and computer system for authenticating a user (injecting risk assessment into user authentication)

Abstract

To enable a system to fill an authentication script for authenticating a user, and to transmit a backend request for risk evaluation without changing a code and directly updating application.SOLUTION: In a method for authenticating a user, a processor receives a login request for application. The processor sends the login request to a collection page. The collection page may include an authentication script. The processor receives risk evaluation based on an identity authenticated through the authentication script. The processor permits access with a certain level to the application based on the risk evaluation.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] 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 technology]

[0002] Many computer applications, including web applications, contain confidential, sensitive, or restricted content, or a combination thereof, that is not intended to be accessed by the general public. These computer applications may restrict access to the content by requiring authentication, whereby users verify their identity. Authentication may involve verifying the validity of identification documents, verifying the authenticity of a website using a digital certificate, or requiring a user to perform a login operation. In computer security, login is the process by which an individual gains access to a computer system by identifying and authenticating themselves. User credentials may include some form of a "username" and a matching "password." Some applications may require a second factor, such as email or SMS authentication, for additional security. Summary of the Invention [Problem to be solved by the invention]

[0003] It allows the system to embed authentication scripts to authenticate users and send back-end requests for risk assessment without modifying code or directly updating applications. [Means for solving the problem]

[0004] An aspect of an embodiment of the present invention discloses a method, computer program product, and computing system for authenticating a user. A processor receives a login request for an application. The processor sends the login request to a collection page. The collection page may include an authentication script. The processor receives a risk assessment based on the authenticated identity through the authentication script. The processor grants a level of access to the application based on the risk assessment. [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 is a diagram of a user authentication environment according to one embodiment of the present invention.

[0006] [Figure 2] 2 is a flowchart of the steps of a risk assessment proxy program executed within the user authentication system of FIG. 1 according to one embodiment of the present invention.

[0007] [Figure 3] FIG. 10 illustrates a visual representation of a login procedure determined by a risk assessment proxy program according to one embodiment of the present invention.

[0008] [Figure 4] FIG. 10 illustrates a visual representation of a login procedure determined by a risk assessment proxy program according to one embodiment of the present invention.

[0009] [Figure 5] FIG. 2 is a block diagram of components of a computing device according to one exemplary embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0010] Disclosed embodiments include devices and methods for adding authentication code snippets to applications without directly updating the login pages for those applications. Updating login pages for applications can be limited for several reasons. For example, applications may be governed by strict change protocols that prohibit changes or increase the complexity or cost, or both, of modifying the application. Also, applications may include existing authentication mechanisms that do not include pages that can be modified with new or additional login techniques. For example, in a single sign-on (SSO) architecture, users access applications based on their authorized device. In such cases, users are granted direct access to web applications without visiting a login page.

[0011] The disclosed embodiments include adding a risk assessment proxy program that redirects login requests for an application to a collection page with one or more authentication scripts. The authentication scripts are 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 not already present in the application. The collection page may include functionality to signal completion of collection and approval to submit a risk assessment request. In this manner, the disclosed embodiments enable a system to embed authentication scripts to authenticate a user and send back-end requests for risk assessment without modifying the code or directly updating the application.

[0012] Referring now to the drawings, FIG. 1 illustrates a block diagram of a user authentication environment 100 according to one 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 may use one or more cloud computing services. Consistent with various embodiments, a cloud computing environment may include a network-based distributed / data processing system that provides one or more cloud computing services. Furthermore, a cloud computing environment may include many computers, such as hundreds, thousands, or more, located within one or more data centers and configured to share resources via the network 104.

[0013] The network 104 is also communicatively coupled to a backend server 110, an access manager 112, and a target server 114. In particular embodiments of the user authentication environment 100, there may be more or fewer components than those 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 through the network 104. In various embodiments, some or each of the components (e.g., the backend server 110, the access manager 112, or the target server 114, or a combination thereof) represent separate computing devices. Each of the disclosed devices (e.g., the client device 102, the target server 114, the access manager 112, or the backend server 110, or a combination thereof) may be configured the same as or similar to the computing device 500 shown in FIG. 5. In some embodiments, some or each of the components represent a particular computing instance of a single computing device (e.g., a program module, a computing component in a chassis, a blade server in a blade enclosure, 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, such as the backend server 110, the access manager 112, or the target server 114, or a combination thereof, may collectively be referred to as a "server system."

[0014] A user 122 uses a client device 102 to access information through the network 104. Specifically, the user 122 loads an application 130 that accesses protected resources 132 stored on the target server 114. Access to the protected resources 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 resources 132. In particular embodiments, the application 130 may also include a function that allows access to the protected resources 132 based on the identity 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 characteristics that cannot be updated, such as if the application 130 includes a policy that does not allow updates or if the SSO architecture does not include a login page that can be modified. In such embodiments, the application 130 may insert a risk assessment proxy program (proxy 134) into the login process that redirects a login request for the application 130 to a collection page 136. The proxy may be stored logically, physically, or both anywhere within the user authentication environment 100, but is shown as operating and accessed through the application 130. The collection page 136 may include an authentication script that enables the access manager 112 to communicate with a collection tool 138 on the client device 102.

[0015] The collection tool 138 can collect and transmit behavioral biometric information, device information, or multi-factor authentication information to the access manager 112. For example, the collection tool 138 may include a module that captures a device identifier or a code snippet for authenticating 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 identify an identity associated with the information collected by the collection tool 138. The identification information 140 includes personalized information for each profile attempting to access the protected resource 132. This may include historical user access data (e.g., where and when a 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 this device).

[0016] For embodiments in which the application 130 cannot be modified to update the login method, a proxy 134 is added, as described above. The proxy 134 operates the method illustrated in FIG. 2 . The proxy 134 receives a login request for the application 130 (block 202). The login request may be received from the client device 102 based on the user 122 selecting the application 130 or following a link from a web page hosting the application. The login request may also include a username and password, an SSO authentication method, or a Kerberos-enabled authentication method. The proxy 134 sends the login request to a collection page 136 (block 204). The collection page 136 includes one or more authentication scripts (e.g., JavaScript code; Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle, its affiliates, or both) that collect additional user variables from the client device 102, the user 122, or the authentication tool 138, or a combination thereof. For example, the authentication script may collect hashed usernames, user Internet Protocol (IP) addresses, user agents, browser information, etc., which application 130 does not collect and which application 130 cannot be programmed to collect.

[0017] Using a proxy 134 to route login requests includes the added ability to automatically adapt the collection page 136 to several different applications. Specifically, the proxy 134 may utilize server-side techniques to select from multiple collection pages 136 through configuration of the proxy 134. That is, the proxy 134 may be programmed to route login requests to several possible collection pages 136 depending on the user 122, the client device 102, the application 130, or other factors. Additional collection pages 136 may be created based on templates implemented for other applications, customized for specific applications 130, or both. Furthermore, customizing the proxy 134 login procedure may include client-side techniques in which authentication scripts are modified to operate and adapt the collection page 130. Thus, a proxy 134 may be added to an enterprise environment, and the user 122 can use the proxy 134 to log in to multiple applications 130. This one-page solution can be useful for all applications, allowing risk assessment to be performed with relatively easy and streamlined implementation.

[0018] Once the authentication script has collected additional information, the collection page 136 may submit the collected identifiers to the backend server 110 or the lookup information directly to the backend server 110. For example, the backend server 110 may contain an opaque, non-personally identifiable profile for each user 122 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 requiring multi-factor authentication.

[0019] The proxy 134 then receives the risk assessment from the collection page 136 (block 206) and makes a determination as to whether the user 122 poses a high risk (block 208). If the user 122 is determined to pose a high risk (block 208, "Yes"), the user 122 is blocked from accessing the application (block 210). A high risk may be determined if the user 122 does not have a profile on the backend server 110, if the profile does not contain sufficient information, or if the information or user profile indicates that the user 122 should not be allowed to access the application, or a combination thereof. If the user 122 does not pose a high risk (block 208, "No"), the proxy 134 may also determine whether the user 122 poses a medium risk (block 212). If the user 122 does not pose a medium risk (block 212, "Yes"), the proxy 134 uses a multi-factor authentication process (block 214). The risk levels, such as medium and high risk, are configurable based on the desired security attributes for protecting protected resources 132. For example, in certain embodiments, proxy 134 may determine a medium risk if user 122 attempts to log in from an unrecognized client device. In other embodiments, logging in from an unrecognized client device may be determined to pose a high risk.

[0020] In certain embodiments of the present invention, the proxy 134 may be configured to take various actions based on the risk level. The options shown may be one configuration for the application 130 with one level of sensitivity / confidentiality. The level of sensitivity / confidentiality may be based on business (e.g., organizational policy) or regulatory (e.g., Open Banking) requirements. For example, a low-risk application 130, such as a travel booking site, may include a proxy 134 configured to allow a medium-risk user 122 to log in directly without multi-factor authentication to view booking options. If the user 122 actually attempts to book a trip, the user 122 triggers a higher standard, and because the user has been detected as a medium risk, the proxy 134 prompts the user 122 to complete a multi-factor authentication process at that time. The multi-factor authentication process may require additional information, metrics, or authentication from the client device 102, or a different device, to ensure that the medium-level risk is mitigated. If the multi-factor authentication is not passed (block 214 "No"), the proxy 134 blocks access to the application 130. If the multi-factor authentication is passed (block 214 "Yes") or if the risk assessment is lower than medium (block 212 "No"), the proxy 134 allows access to the application 130 (block 216).

[0021] FIG. 3 illustrates a visual representation of a user authentication procedure determined by a risk assessment proxy program according to one embodiment of the present invention. When a user initiates a user authentication procedure for application 330 using a client device, a login request 342 is generated by the user. The login request 342 is received by a proxy 334 injected into the user authentication procedure for application 330. The proxy 334 may identify a primary risk level based on the login request 342. For example, the proxy may determine that the login request 342 may be initiated from a particular location, such as a field work location. If the primary risk level is sufficiently low, the proxy 334 may approve the login request 342 and allow access to application 330 without further requesting information. In other situations where the primary risk level is not approved for immediate access, the proxy 334 may send the login request to a collection page 336, which may request additional information from the client device that sent the login request 342. The collection page 336 may access information from the backend server 310, including information identifying the risk assessment. The proxy 334 may receive the risk assessment and grant access to the application 330 or send the login request 342 to a multi-factor authentication page 344, which may then enable the proxy 334 to grant access to the application 330.

[0022] 4 illustrates login procedures for some embodiments of the present invention. A first login procedure 450 includes an SSO / Kerberos scheme without a proxy 434. The first login procedure 450 proceeds from a login request 442 to access an application 430 without the possibility of performing a risk assessment. A second login procedure 452 includes an SSO / Kerberos scheme with a proxy 434 inserted into the login procedure. The proxy 434 sends 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 identified in the collection page 436, the second login procedure 452 either proceeds to the application 430 or to a multi-factor authentication page 444. The second login procedure 452 may proceed from the multi-factor authentication page 444 to the application 430 if the multi-factor authentication page 444 approves the login request 442.

[0023] The third login procedure 454 may not use an SSO / Kerberos scheme and therefore may include a login page 428 that takes a username and password. The third login procedure 454 may still include a collection page 436 to perform further risk assessment as to whether the login request 442 should be sent to the multi-factor authentication page 444. While additional login stages may be included within the scope of the disclosed embodiments, the first login procedure 450, second login procedure 452, and third login procedure 454 illustrate that the addition of a proxy 434 increases the adaptability of the risk assessment for logging into the application 430.

[0024] 5 illustrates a block diagram of components of a computing device 500 according to an exemplary embodiment of the invention. As described above, computing device 500 may represent any of the above-described devices (e.g., client device 102, target server 114, access manager 112, or backend server 110, or a combination thereof) or a combination of such devices in embodiments where the devices are embodied as components of a single computing device 500. It should be understood that FIG. 5 is intended as an illustration of only one implementation and is not intended to suggest any limitation with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made.

[0025] Computing device 500 includes a communications fabric 502 that provides communications between RAM 514, cache 516, memory 506, persistent storage 508, communications unit 510, and input / output (I / O) interface 512. Communications fabric 502 may be implemented using any architecture designed to pass data or control information, or both, between a processor (such as a microprocessor, communications and network processor), system memory, peripheral devices, and any other hardware components in a system. For example, communications fabric 502 may be implemented using one or more buses or crossbar switches.

[0026] Memory 506 and persistent 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 medium. Cache 516 is high-speed memory that increases the performance of computer processor 504 by holding recently accessed data and data near recently accessed data from memory 506.

[0027] Software components (e.g., proxies, 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 respective computer processors 504 via cache 516. In one embodiment, persistent storage 508 includes a magnetic hard disk drive. Instead of, or in addition to, a magnetic hard disk drive, persistent storage 508 may include a solid-state hard drive, a semiconductor storage device, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, or any other computer-readable storage medium capable of storing program instructions or digital information.

[0028] The media used by persistent storage 508 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.

[0029] The communications unit 510, in these examples, provides for communication with other data processing systems or devices. In these examples, the communications unit 510 includes one or more network interface cards. The communications unit 510 may provide communication through the use of either or both physical and wireless communications links. Proxies, applications, access managers, collection pages, authentication tools, or multi-factor authentication pages may be downloaded to persistent storage 508 through the communications unit 510.

[0030] The I / O interface 512 allows for the input and output of data to 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, keypad, touchscreen, or any other suitable input device, or a combination thereof. The external device 518 may also include portable computer-readable storage media, such as thumb drives, portable optical or magnetic disks, and memory cards. Software and data used to practice embodiments of the present invention (e.g., proxies, applications, access managers, collection pages, authentication tools, or multi-factor authentication pages) may be stored on such portable computer-readable storage media and loaded onto persistent storage 508 via the I / O interface 512. The I / O interface 512 also connects to a display 520.

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

[0032] The present invention may be a system, method, or computer program product, or combination thereof, at any possible level of technical detail of integration. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions that cause a processor to perform aspects of the present invention.

[0033] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, 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 sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves that record instructions, and any suitable combination of the foregoing. Computer-readable storage medium, as used herein, is not to be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted through a wire.

[0034] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions to a computer-readable storage medium in the respective computing / processing device for storage.

[0035] The computer-readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk®, C++, etc., and procedural programming languages ​​such as the “C” programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer readable program instructions to personalize the electronic circuitry by utilizing state information of the computer readable program instructions to perform aspects of the present invention.

[0036] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0037] These computer-readable program instructions may be provided to a computer processor or other programmable data processing apparatus to produce a machine, whereby the instructions, executed by the computer processor or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium, whereby the instructions can instruct a computer, programmable data processing apparatus or other device, or combination thereof, to function in a particular manner, such that the computer-readable storage medium having the instructions stored thereon comprises an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0038] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be executed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, whereby the instructions executing on the computer, other programmable apparatus, or other device implement the functions / operations specified in one or more blocks of the flowcharts or block diagrams, or both.

[0039] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions, that implement the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be implemented as a single step, or may be executed concurrently, substantially concurrently, partially, or fully overlapping in time, or the blocks may even be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware and computer instructions.

Claims

1. 1. A computer-implemented method for authenticating a user, comprising: receiving a request to log in to an application; sending the login request to a collection page on a computer different from the computer, the collection page including an authentication script, the collection page being selected from a plurality of collection pages based on a selection from the group consisting of a user identity, a client device, and the application; receiving a risk assessment based on the identity authenticated through the authentication script; granting a level of access to the application based on the risk assessment; A method comprising:

2. The method of claim 1 , wherein the login request includes 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.

3. The method of claim 1 or 2, wherein the login request includes information identifying the application.

4. The method of claim 1 , wherein the authentication script collects user variables including a selection from the group consisting of a hashed username, a user IP address, a user agent, and a browser.

5. 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.

6. 6. The method of claim 1, wherein the level of access comprises a selection from the group consisting of: allowing the user to access the application, denying access to the application, and requiring multi-factor authentication.

7. The method of claim 1 , comprising determining a primary risk level based on the login request.

8. A computer-implemented method for authenticating a user, comprising: receiving a request to log in to an application; sending the login request to a collection page on a computer different from the computer, the collection page including an authentication script, the authentication script including a code snippet that authenticates a device fingerprint; receiving a risk assessment based on the identity authenticated through the authentication script; granting a level of access to the application based on the risk assessment; A method comprising:

9. A computer-implemented method for authenticating a user, comprising: receiving a login request to an application, the application controlling only access to protected resources remote from the user and not having the ability to control access to resources other than the protected resources; selecting a collection page from a plurality of collection pages stored on a server and customized for a particular application, the collection page being selected based on the application for which the received login request is intended; sending the login request to the collection page, the collection page including an authentication script requesting login information that the application does not collect; receiving a risk assessment based on the identity authenticated through the authentication script; granting a level of access to the application based on the risk assessment; A method comprising:

10. 1. A computer program for authenticating a user, the computer program including: receiving a login request to the application; sending the login request to a collection page on a computer different from the computer, the collection page including an authentication script, the collection page being selected from a plurality of collection pages based on a selection from the group consisting of a user identity, a client device, and the application; receiving a risk assessment based on the identity authenticated through the authentication script; granting a level of access to the application based on the risk assessment; A computer program for executing

11. 11. The computer program product of claim 10, wherein the login request includes 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.

12. The computer program product according to claim 10 or 11, wherein the login request includes information that identifies the application.

13. The computer program product of claim 10 , wherein the authentication script comprises a code snippet for authenticating a device fingerprint.

14. A computer program for authenticating a user, the computer program comprising: receiving a login request to the application; sending the login request to a collection page on a computer different from the computer, the collection page including an authentication script, the authentication script including a code snippet that authenticates a device fingerprint; receiving a risk assessment based on the identity authenticated through the authentication script; granting a level of access to the application based on the risk assessment; A computer program for executing

15. 15. The computer program of claim 10, wherein the authentication script collects user variables including a selection from the group consisting of a hashed username, a user IP address, a user agent, and a browser.

16. 16. The computer program of claim 10, wherein the risk assessment is received from a backend server that includes an opaque, non-personally identifiable user profile associated with the identity.

17. 17. The computer program product of claim 10, wherein the level of access comprises a selection from the group consisting of: allowing the user to access the application, denying access to the application, and requiring multi-factor authentication.

18. A computer program for authenticating a user, the computer program comprising: receiving a login request to an application, the application controlling only access to protected resources remote from the user and not having the ability to control access to resources other than the protected resources; selecting a collection page from a plurality of collection pages stored on a server and customized for a particular application, the collection page being selected based on the application for which the received login request is received; sending the login request to the collection page, the collection page including an authentication script that requests login information that the application does not collect; receiving a risk assessment based on the identity authenticated through the authentication script; granting a level of access to the application based on the risk assessment; A computer program for executing

19. 1. A computer system for authenticating a user, comprising: one or more computer processors; one or more computer-readable storage media; and program instructions stored on the one or more computer-readable storage media that are executed by at least one of the one or more computer processors, the program instructions comprising: program instructions for receiving a login request to an application; program instructions for sending the login request to a collection page on a computer different from the computer system, the collection page including an authentication script, the collection page being selected from a plurality of collection pages based on a selection from the group consisting of a user identity, a client device, and the application; program instructions for receiving a risk assessment based on the identity authenticated through the authentication script; program instructions for granting a level of access to the application based on the risk assessment; A computer system comprising:

20. 20. The computer system of claim 19, wherein the login request includes 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.

21. 21. The computer system of claim 19, wherein the login request includes information identifying the application.

22. 22. The computer system of claim 19, wherein the authentication script includes a code snippet that authenticates a device fingerprint.

23. A computer system for authenticating a user, comprising: one or more computer processors; one or more computer-readable storage media; and program instructions stored on the one or more computer-readable storage media that are executed by at least one of the one or more computer processors, the program instructions comprising: program instructions for receiving a login request to an application; program instructions for sending the login request to a collection page on a computer different from the computer system, the collection page including an authentication script, the authentication script including a code snippet for authenticating a device fingerprint; program instructions for receiving a risk assessment based on the identity authenticated through the authentication script; program instructions for granting a level of access to the application based on the risk assessment; A computer system comprising:

24. 24. The computer system of claim 19, wherein the risk assessment is received from a backend server that includes an opaque, non-personally identifiable user profile associated with the identity.

25. 25. The computer system of claim 19, wherein the level of access includes a selection from the group consisting of: allowing the user to access the application, denying access to the application, and requiring multi-factor authentication.

26. A computer system for authenticating a user, comprising: one or more computer processors; one or more computer-readable storage media; and program instructions stored on the one or more computer-readable storage media that are executed by at least one of the one or more computer processors, the program instructions comprising: program instructions for receiving a login request to an application, the application controlling only access to protected resources remote from the user and not having the ability to control access to resources other than the protected resources; program instructions for selecting a collection page from a plurality of collection pages stored on a server and customized for a particular application, the collection page being selected based on the application for which the received login request is received; program instructions for sending the login request to the collection page, the collection page including an authentication script that requests login information that the application does not collect; program instructions for receiving a risk assessment based on the identity authenticated through the authentication script; program instructions for granting a level of access to the application based on the risk assessment; A computer system comprising:

27. 1. A computer-implemented method for authenticating a user, comprising: inserting a proxy into a login procedure of an application, the proxy accessing a collection page on a computer different from the computer on which the proxy is located, the collection page including an authentication script, the collection page being selected from a plurality of collection pages based on a selection from the group consisting of a user identity, a client device, and the application; the collection page obtaining identifying information collected on a client device running the application and performing a risk assessment based on the obtained collected identifying information, the client device being the same as or different from the computer on which the proxy is located; granting a level of access to the application based on the risk assessment; A method comprising:

28. 28. The method of claim 27, wherein the level of access comprises a selection from the group consisting of: allowing the user to access the application, denying access to the application, and requiring multi-factor authentication.

29. A computer-implemented method for authenticating a user, comprising: inserting a proxy into an application's login procedure, the proxy accessing a collection page on a computer different from the computer on which the proxy is located, the collection page including an authentication script, the authentication script including a code snippet for authenticating a device fingerprint; the collection page obtaining identifying information collected on a client device running the application and performing a risk assessment based on the obtained collected identifying information, the client device being the same as or different from the computer on which the proxy is located; granting a level of access to the application based on the risk assessment; A method comprising:

30. 30. The method of claim 29, comprising selecting the collection page from a plurality of collection pages based on a selection from the group consisting of a user identity, a client device, and the application.

31. A computer-implemented method for authenticating a user, comprising: inserting a proxy into a login procedure of an application, the application being configured to access only protected resources, (i) the proxy selecting a collection page from a plurality of collection pages stored on a server and customized for a particular application, the selection being based on the application using the login procedure, and (ii) the proxy accessing the collection page including an authentication script that requests login information that the application does not collect; the collection page obtaining identifying information collected on a client device running the application and performing a risk assessment based on the obtained collected identifying information, the client device being the same as or different from the computer on which the proxy is located; granting a level of access to the application based on the risk assessment; A method comprising:

Images