KR20170056566A - System and method for integrating an authentication service within a network architecture - Google Patents

Abstract

Systems, devices, methods, and machine-readable media for integrating authentication services within existing network infrastructure are described. One embodiment includes a gateway configured to restrict access to an internal network; An authentication server communicatively coupled to the gateway; A client device with an authentication client having a plurality of authentication devices coupled thereto for authenticating a user, the authentication client being configured to establish a communication channel with the authentication server and to register one or more of the authentication devices with the authentication server, Can be used to perform online authentication to the authentication server after registration; And an authentication client for authenticating the user to the authentication server using one or more of the registered authentication devices in response to an attempt to obtain access to the internal network via the gateway.

Description

[0001] SYSTEM AND METHOD FOR INTEGRATING AUTHENTICATION SERVICE WITHIN NETWORK ARCHITECTURE [0002] SYSTEM AND METHOD FOR INTEGRATING AN AUTHENTICATION SERVICE WITHIN A NETWORK ARCHITECTURE [

The present invention relates generally to the field of data processing systems. More particularly, the present invention relates to systems and methods for integrating authentication services within a network architecture.

Systems have also been designed to provide security user authentication over a network using biometric sensors. In such systems, scores generated by the authenticator, and / or other authentication data may be transmitted over the network to authenticate the user to the remote server. For example, U.S. Patent Application No. 2011/0082801 ("'801 Application") discloses a method for secure authentication (e.g., protection against identity theft and phishing), secure transactions (e.g., fingerprint readers, face recognition devices, smart cards, trusted platform modules, etc.) and client authentication token enrollment / management (e.g., protection against malware in the browser and man in the middle) And a framework for user registration and authentication on a network that provides authentication and authentication.

The assignee of the present application has developed various improvements to the authentication framework described in the ' 801 application. Some of these improvements are described in the following set of US patent applications, assigned to the assignee: 13 / 730,761, Query System and Method to Determine Authentication Capabilities; No. 13 / 730,776, entitled SYSTEM AND METHOD FOR Efficiently Enrolling, Registering, and Authenticating With Multiple Authentication Devices for Efficiently Registering, Recording, and Authenticating With Multiple Authentication Devices; 13 / 730,780, System and Method for Processing Random Challenges Within an Authentication Framework within an Authentication Framework; 13 / 730,791, Systems and Methods for Implementing Privacy Classes within an Authentication Framework; 13 / 730,795, System and Method for Implementing Transaction Signaling Within an Authentication Framework; And 14 / 218,504, Advanced Authentication Techniques and Applications (hereinafter "'504 application"). Such applications are sometimes referred to herein ("pending applications").

In brief, pending applications describe authentication techniques in which a user registers with authentication devices (or authenticators), such as biometric devices (e.g., fingerprint sensors) on a client device. When the user registers with the biometric device, the biometric reference data is captured (e.g., by finger swiping, photo snapping, voice recording, etc.). Subsequently, the user may register / provision the authentication devices to one or more servers (e.g., a website or other relying party with secure transaction / authentication services as described in published applications) over the network after; And may be authenticated in such servers using data exchanged during the registration process (e.g., cryptographic keys provisioned within the authentication devices). Once authenticated, the user is allowed to perform one or more online transactions with a web site or other trustee. In the framework described in the pending applications, the privacy of a user can be protected by locally maintaining sensitive information on the user's authentication device, such as fingerprint data and other data that can be used to uniquely identify the user .

The '504 application describes, in only a few examples, the design of multiple authenticators, intelligently generating authentication assurance levels, using non-intrusive user verification, sending authentication data to new authentication devices, Describes various additional techniques, including techniques for augmenting with risk data, applying authentication policies adaptively, and creating trust rings.

Increasing the trustee's web-based or other network capable application to leverage the remote authentication techniques described in the pending applications typically requires that the application be integrated directly with the authentication server. Since the trustee will need to expand their efforts to update their applications and integrate with the authentication server in order to obtain the authentication flexibility provided by the techniques described in the publications applications, Is raised.

In some cases, the trustor may have already been integrated into federated solutions, so a simple integration path is simply to integrate online authentication support into the federated solution. Unfortunately, this approach is not sufficient enough to allow for direct integration of online authentication functionality, which lacks awareness of federated protocols (and thus can make a federated server augmented with online authentication capabilities as a front end) But does not address legacy systems (e.g., VPN, Windows Kerberos deployments). Thus, the key problem that must be addressed for certain trusted applications is finding a way that they can make it possible to integrate the online authentication system, without the need to modify the code of the application itself.

BRIEF DESCRIPTION OF THE DRAWINGS A better understanding of the present invention can be obtained from the following detailed description taken in conjunction with the following drawings.
Figures 1a and 1b show two different embodiments of a security authentication system architecture.
Figure 2 is a transaction diagram illustrating how keys can be registered in authenticating devices.
Figure 3 shows a transaction diagram showing remote authentication.
Figure 4 shows a system for connecting a user to an internal network via a Secure Socket Layer (SSL) Virtual Private Network (VPN) gateway.
5 shows an embodiment of a system for integrating an authentication server within a network infrastructure.
Figure 6 illustrates one embodiment of a method for performing authentication using an authentication server integrated within a network infrastructure.
Figure 7 illustrates one embodiment of a system for integrating an authentication server within a coverslus infrastructure.
Figure 8 illustrates one embodiment of a method for performing authentication using an authentication server integrated within a coverslus infrastructure.
Figure 9 illustrates one embodiment of a computer architecture used for servers and / or clients.
10 illustrates one embodiment of a computer architecture used for servers and / or clients.

In the following, embodiments of devices, methods and machine-readable media for implementing advanced authentication techniques and related applications are described. Throughout the description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well known structures and devices are not illustrated or illustrated in block diagram form in order not to obscure the underlying principles of the invention.

Embodiments of the invention discussed below include authentication devices having user verification capabilities such as biometric aspects or PIN entries. Such devices are sometimes referred to herein as "token "," authentication device "or" authenticator ". Certain embodiments are focused on face recognition hardware / software (e.g., a camera and related software for recognizing a user's face and tracking a user's eye movement), but some embodiments may include, for example, a fingerprint sensor, (E.g., a microphone and related software for recognizing the user's voice) and optical recognition capabilities (e.g., an optical scanner and associated software for scanning the user's retina) have. The user verification capability may also include non-biometric aspects such as PIN entries. Authenticators can use devices such as trusted platform modules (TPM), smart cards, and security elements for cryptographic operations and key storage.

In a mobile biometric implementation, the biometric device may be remote from the trustee. As used herein, the term "remote" means that the biometric sensor is not part of the security boundary of the computer to which it is communicatively coupled (e.g., it is placed in the same physical fence as the trustee's computer . By way of example, the biometric device may be coupled to a trustee via a network (e.g., the Internet, a wireless network link, etc.) or via a peripheral input such as a USB port. Under these conditions, if the trusted device is a device authorized by the trustee (e.g., a device that provides an acceptable level of authentication strength and integrity protection) and / or a hacker compromises the biometric device, There may not be a way to know if you have replaced it. The reliability of the biometric device depends on the specific implementation of the device.

The term "local" is used herein to refer to the fact that a user is personally completing a transaction at a particular location, such as an automatic teller machine (ATM) or point of sale (POS) retail checkout location. However, as discussed below, the authentication techniques used to authenticate a user may include non-location components, such as communications over a network with remote servers and / or other data processing devices. Moreover, although specific embodiments have been described herein (such as ATM and retail locations), it should be noted that the underlying principles of the present invention may be implemented within the context of any system where transactions are initiated locally by an end user do.

The term "trustee" is sometimes used herein to refer to an entity for which a user transaction is attempted (e.g., a web site or an online service that performs a user transaction), as well as such entities capable of performing basic authentication techniques Are also used to refer to secure transaction servers, sometimes referred to as being implemented on behalf of < / RTI > Secure transaction servers may be owned by and / or under the control of a trustee, or may be under the control of a third party that provides secure transaction services to a trustee as part of a business agreement.

The term "server" is used herein to refer to a server (or other device) on a hardware platform that receives requests from a client over a network, performs one or more operations in response thereto, and typically sends a response Across the platform). ≪ / RTI > The server aids in providing or providing network "services" to clients in response to client requests. Importantly, the server is not limited to a single computer (e.g., a single hardware device for running server software), and may be distributed across multiple hardware platforms, potentially in multiple geographic locations.

Exemplary online authentication architectures and transactions

Figures 1A and 1B illustrate two embodiments of a system architecture including client-side and server-side components for registering authentication devices (sometimes referred to as "provisioning") and authenticating users. The embodiment shown in FIG. 1A uses a web browser plug-in based architecture to communicate with a web site, whereas the embodiment shown in FIG. 1B does not require a web browser. Various techniques described herein, such as registering a user with authentication devices, registering authentication devices with a security server, and verifying a user, may be implemented in any of these system architectures. 1A is used to illustrate the operation of various of the embodiments described below, the same basic principles (e.g., the communication between the server 130 and the secure transaction service 101 on the client) (E. G., By removing browser plug-in 105 as an intermediary for < / RTI >

First, referring to FIG. 1A, the illustrated embodiment includes one or more authentication devices 110-112 (sometimes referred to in the art as an authentication "token" or an authenticator) for registering and verifying an end user And a client (100). As described above, the authentication devices 110 to 112 may be a fingerprint sensor, a speech recognition hardware / software (e.g., a microphone and related software for recognizing the user's voice), facial recognition hardware / software (e.g., A biometric device such as a camera and associated software for recognizing a user's face) and optical recognition capabilities (e.g., an optical scanner and associated software for scanning a user's retina), and nonbiometric aspects such as PIN verification For example. The authentication devices may use Trusted Platform Module (TPM), smart card or security element for cryptographic operations and key storage.

The authentication devices 110-112 are communicatively coupled to the client via an interface 102 (e.g., an application programming interface or API) exposed by the secure transaction service 101. Secure transaction service 101 is a security application for communicating with one or more secure transaction servers 132, 133 over a network and for interfacing with secure transaction plug-ins 105 running within the context of web browser 104. As shown, the interface 102 includes a device identification code, a user identification code, user registration data (e.g., scanned fingerprint or other biometric data) protected by an authentication device, To provide secure access to the secure storage device 120 on the client 100 storing information associated with each of the authentication devices 110-112, such as keys sealed by an authentication device used to perform the techniques It is possible. For example, as discussed in detail below, a unique key may be stored within each of the authentication devices and used when communicating to the servers 130 over a network, such as the Internet.

Certain types of network transactions, such as HTTPS or HTTPS transactions with web sites 131 or other servers, are supported by secure transaction plug-in 105, as discussed below. In one embodiment, the secure transaction plug-in is a secure transaction plug-in that is embedded in the HTML code of the web page by the web server 131 in the secure enterprise or web destination 130 (sometimes referred to below simply as "server 130 ≪ / RTI > tags. In response to the detection of such a tag, the secure transaction plug-in 105 may send transactions to the secure transaction service 101 for processing. Additionally, for certain types of transactions (e.g., security key exchange), the secure transaction service 101 may communicate with the transaction server 132 (i.e., located at the same location as the web site) A direct communication channel can be established.

The secure transaction servers 132 and 133 are coupled to a secure transaction database 120 for storing user data, authentication device data, keys, and other security information required to support secure authentication transactions described below. It should be noted, however, that the underlying principles of the present invention do not require the separation of logical components within the security enterprise or web destination 130 shown in FIG. 1A. For example, the web site 131 and secure transaction servers 132 and 133 may be implemented within a single physical server or individual physical servers. Furthermore, the website 131 and transaction servers 132 and 133 may be implemented in an integrated software module running on one or more servers to perform the functions described below.

As described above, the basic principles of the present invention are not limited to the browser-based architecture shown in FIG. 1A. 1B illustrates an alternative implementation in which an independent application 154 authenticates a user over the network using the functionality provided by the secure transaction service 101. [ In one embodiment, application 154 is designed to set up communication sessions with one or more network services 151 that depend on secure transaction servers 132, 133 to perform user / client authentication techniques, do.

In any of the embodiments shown in FIGS. 1A and 1B, secure transaction servers 132 and 133 may generate keys, which are then transmitted securely to secure transaction service 101, RTI ID = 0.0 > 120 < / RTI > In addition, the secure transaction servers 132 and 133 manage the secure transaction database 120 on the server side.

Certain basic principles associated with remotely registering authentication devices and authenticating with trustees will be described in connection with FIGS. 2 and 3, and a detailed description of embodiments of the invention for establishing trust using secure communication protocols Will continue.

Figure 2 illustrates a series of transactions for registering (sometimes referred to as "provisioning " authentication devices) authentication devices (e.g., devices 110-112 on client 100 of Figures 1a and 1b) . The security transaction service 101 and the interface 102 are coupled together as the authentication client 201 and the security enterprise or web destination 130 including the secure transaction servers 132 and 133 is trusted 202).

During registration of an authenticator (e.g., a fingerprint authenticator, a voice authenticator, etc.), the key associated with the authenticator is shared between the authentication client 201 and the trustor 202. 1A and 1B, the key may be stored in the secure repository 120 of the client 100 and in the secure transaction database 120 used by the secure transaction servers 132,133. In one embodiment, the key is a symmetric key generated by one of the secure transaction servers 132, 133. However, in another embodiment discussed below, asymmetric keys are used. In this embodiment, a public / private key pair may be generated by secure transaction servers 132, 133. The public key may then be stored by the secure transaction servers 132, 133 and the associated private key may be stored in the secure store 120 on the client. In an alternative embodiment, the key (s) may be generated on the client 100 (e.g., by an authenticating device or an authenticating device interface rather than by secure transaction servers 132, 133). The underlying principles of the present invention are not limited in any way to generating any particular type of keys or keys.

The secure key provisioning protocol is employed in one embodiment to share a key with a client over a secure communication channel. One example of a key provisioning protocol is the Dynamic Symmetric Key Provisioning Protocol (DSKPP) (see, for example, RFC (Request for Comments) 6063). However, the underlying principles of the present invention are not limited to any particular key provisioning protocol. In one particular embodiment, the client generates a public / private key pair and sends the public key to the server, which can be proven with a proof key.

Returning to the specific details shown in FIG. 2, to initiate the registration process, the trustor 202 generates a random challenge (e.g., a cryptosense) that should be presented by the authentication client 201 during device registration do. The random challenge may be valid for a limited period of time. In response, the authentication client 201 initiates an out-of-band secure connection (e. G., Out-of-band transaction) with the trustor 202 and uses a key provisioning protocol (e. G., The DSKPP protocol described above) Lt; / RTI > To initiate a secure connection, the authentication client 201 may provide a random challenge back to the trustor 202 (with a signature generated for a potentially random challenge). The authentication client 201 may also be configured to provide a user identity (e.g., a user ID or other code) and an authentication credential ID (AAID) that uniquely identifies the type of authentication device (s) being provisioned The identity of the authentication device (s) to be provisionally registered.

The trustee can find the user using the username or ID code (e.g., within the user account database), identify the random challenge (e.g., by using a signature or simply comparing the random challenge with the one sent) (E.g., AAID) of the authentication device has been transmitted and verifies that the secure transaction database (e.g., database 120 of FIGS. 1A and 1B) for the user and the authentication device (s) ≪ / RTI > In one embodiment, the trustee maintains a database of authentication devices that it allows for authentication. The AAID (or other authentication device (s) code) may be used to query this database to determine if the authentication device (s) being provisioned is acceptable for authentication. In that case, the registration process will proceed.

In one embodiment, the trustor 202 generates an authentication key for each authentication device being provisioned. Records the key in the security database and sends the key back to the authentication client 201 using the key provisioning protocol. Once completed, the authenticator and trustor 202 share the same key if a symmetric key is used, or different keys if asymmetric keys are used. For example, when an asymmetric key is used, the trustor 202 may store the public key and provide the private key to the authentication client 201. [ Upon receiving the private key from the trustor 202, the authentication client 201 provisions the key to the authentication device (storing it in the secure store associated with the authentication device). Subsequently, a key may be used during authentication of the user (as described below). In an alternative embodiment, the key (s) are generated by the authentication client 201 and the key provisioning protocol is used to provide the key (s) to the trustor 202. In either case, once the provisioning is complete, the authentication client 201 and the trustor 202 each have one key, and the authentication client 201 notifies the trustee of the completion.

Figure 3 shows a series of transactions for user authentication using provisioned authentication devices. Once the device registration is complete (as described in FIG. 2), the trustor 202 will allow the authentication response (sometimes referred to as a "token") generated by the local authentication device on the client as a valid authentication response.

3, a user may initiate a transaction with a trustor 202 requesting authentication (e.g., initiating a payment from a trustee's web site, accessing personal user account data , Etc.), the trustor 202 generates an authentication request that includes a random challenge (e.g., a cryptographic nonce). In one embodiment, the random challenge has a time limit associated therewith (e.g., it is valid for a certain period of time). The trustee can also identify the authenticator to be used by the authentication client 201 for authentication. As described above, the trustee can provision each authentication device available on the client and store the public key for each provisioned authenticator. Thus, the public key of the authenticator can be used, or the authenticator to be used can be identified using the authenticator ID (e.g., AAID). Alternatively, a list of authentication options that the user can select can be provided to the client.

In response to receiving the authentication request, a graphical user interface (GUI) requesting authentication may be presented to the user (e.g., in the form of a web page or an authentication application / application's GUI). The user then performs authentication (e.g. finger swiping on the fingerprint reader, etc.). In response, the authentication client 201 uses the private key associated with the authenticator to generate an authentication response that includes a signature for the random challenge. Other relevant data, such as a user ID code, may also be included in the authentication response.

Upon receiving the authentication response, the trustee can verify the signature for the random challenge (e.g., using the public key associated with the authenticator) and verify the user's identity. Once the authentication is complete, the user is allowed to enter secure transactions with the trustee as shown.

(TLS) or Secure Socket Layer (SSL) to establish a secure connection between the trustor 201 and the authentication client 202 for any or all of the transactions shown in Figures 2 and 3 A secure communication protocol may be used.

System and method for integrating authentication services with network architecture

Many legacy systems may have features that support other authentication methods besides user names and passwords. For example, Secure Socket Layer (SSL) virtual private network (VPN) systems support the use of One Time Passwords (OTPs). Systems such as Covers allow users to authenticate with a network or service using a digital certificate.

Embodiments of the inventions described herein leverage these features to integrate these legacy systems with online authentication services without requiring any changes in the legacy system itself (except for configuration changes).

Secure Socket Layer (SSL) To increase the security of Virtual Private Networks (VPNs), enterprises deploy second factor authentication solutions based on the OTP approach. Solutions such as RSA SecurID or OATH require users to carry an OTP generator and to enter the OTP generated by this generator in combination with a username and password to authenticate against the VPN.

4 shows an OTP validation server 425 configured to operate in combination with an SSL VPN gateway 415. FIG. In operation, the user opens the web browser 410 and navigates to an SSL VPN gateway 415 which renders an HTML-based login form 411 containing a user ID field 412 and a password field 413. The user may enter the user ID in the UID field 412 and enter the OTP in the password field 413 (either by itself or in addition to the user's static password). After entering the user name and password through the HTML form 411, the user submits the results to the SSL VPN gateway 415. [

The SSL VPN gateway 415 verifies the user name and password for the user repository 420 (e.g., confirms that a user name exists and a correct password is entered) and sends the OTP entered by the user to the OTP verification server 425 ) To confirm the OTP. If the OTP verification server 425 provides a positive response confirming the OTP, the SSL VPN gateway 415 allows the user to access the protected internal network 430.

As mentioned in the above example, the SSL VPN gateway 415 may render an individual form element for enabling the input of the OTP, while in other cases the SSL VPN gateway 415 may allow the user to You can simply rely on adding its OTP to the password in the password field. In addition, the SSL VPN gateway 415 can immediately deny access if the primary username and password are not accepted by the user repository 420 identity. Communication between the SSL VPN gateway 415 and the OTP verification server 425 may be facilitated by a plug-in provided by one of the SSL VPN gateway vendor or the OTP verification server vendor. However, most SSL VPN gateways support RADIUS integration (see RFC 2865). Therefore, RADIUS support by the OTP solution eliminates the need for OTP server providers to develop SSL VPN gateway-specific connectors.

As shown in FIG. 5, one embodiment of the present invention uses SSL (Secure Socket Layer) to integrate online authentication technologies (e.g., as described above in connection with FIGS. 1A, 1B, and 3) Lt; RTI ID = 0.0 > 515 < / RTI > As shown, this embodiment includes an authentication server 202 communicatively coupled to an SSL VPN gateway 515 in a potentially identical (or similar) manner to the OTP verification server 425 described above. The authentication server 202 also includes an authentication client 201 for authenticating a user using one or more authentication devices 110 to 112 (e.g., fingerprint authenticator, voice authenticator, retina scan authenticator, etc.) And is communicatively coupled to the client device 510. Although the authentication server 202 is coupled to the authentication client 201 (e.g., in a manner similar to the embodiment illustrated in FIG. 1A) via the browser of FIG. 5, the underlying principles of the present invention are not limited to browser- Do not.

In one embodiment, the interaction between SSL VPN gateway 515, browser 510 and authentication server 202 is as follows. A user opens a web browser 510 and navigates to an SSL VPN gateway 515 that renders a web page 511 containing browser executable code 512 such as JavaScript. In one embodiment, the browser executable code 512 establishes a communication channel with the authentication server 202 and triggers authentication by triggering the authentication client 201 to authenticate the user. In one embodiment, the authentication server 202 and the client 201 enter a series of authentication transactions, such as those described above with respect to FIG. For example, the authentication server 202 may identify an authenticator 110-112 to be used by the authentication client 201 for authentication and may generate an authentication request that includes a random challenge (e.g., a cryptosense) (Or may not). In response to receiving the authentication request, a graphical user interface (GUI) requesting authentication may be presented to the user (e.g., in the form of a web page or an authentication application / application's GUI). The user then performs authentication (e.g. finger swiping on the fingerprint reader, etc.). In response, the authentication client 201 uses the private key associated with the authenticator to generate an authentication response that includes a signature for the random challenge. Other relevant data, such as a user ID code, may also be included in the authentication response. Upon receiving the authentication response, the authentication server 202 confirms the signature for the random challenge (e.g., using the public key associated with the authenticator) and verifies the user's identity. In one embodiment, the JavaScript or other browser executable code 512 conveys the above authentication messages between the authentication server 202 and the authentication client 201.

In one embodiment, in response to a successful authentication, the authentication server 202 generates a cryptographic data structure, referred to herein as a "ticket " In one embodiment, the ticket includes a random number sequence or other form of one-time password (OTP) that may be submitted to the SSL VPN gateway 515 via fields of the HTML form 511. [ For example, as noted above, a separate field may be defined for the ticket in the HTML form 511, or a ticket may be added to the end of the user's static password. Regardless of how the ticket is entered, in one embodiment, the JavaScript or other browser executable code 512 submits the ticket to the SSL VPN gateway 515. Once received, the SSL VPN gateway 515 verifies the ticket through communication with the authentication server 202 (e.g., providing a ticket to the authentication server and receiving a communication indicating that the ticket is valid). For example, when receiving a ticket and other user data (e.g., a user ID or other type of identifier) from the SSL VPN gateway 515, the authentication server 202 can compare the ticket with the ticket provided to the browser 510 have. If the tickets match, then the authentication server 202 sends an "authentication success" message to the SSL VPN gateway 515. If the tickets do not match, then the authentication server sends an "authentication failure" message to the SSL VPN gateway 515. In one embodiment, the SSL VPN gateway 515 uses RADIUS to validate the ticket against the authentication server 202 (although the underlying principles of the invention are not limited to any particular protocol). Once confirmed, the SSL VPN gateway 515 allows the user to access the protected internal network 530.

Significantly, transactions between the SSL VPN gateway 515 and the authentication server 202 are implemented in the same manner (e.g., using the same protocol and data fields) as the success / failure messages provided by the OTP verification server 425 . As a result, the SSL VPN gateway 515 does not need to be reconfigured to implement the embodiments of the present invention described herein, thereby simplifying implementation and reducing the time and cost associated therewith.

In the above approach, the SSL VPN login page 511 may be customized to include custom JavaScript or other browser executable code 512 to trigger authentication. Of course, alternative embodiments may be implemented when the installed authentication client 201 is not present to the user.

Additionally, communication with the SSL VPN gateway 515 by JavaScript or other browser executable code 512 may be performed via the same HTML form 511 that the user typically uses to authenticate to the SSL VPN gateway 515 It can be facilitated. The goal is to provide a ticket obtained by JavaScript or other executable code to the OTP field 511 of the HTML form 511 of an existing password or default SSL VPN (i.e., simplifying and reducing the time and cost associated with implementing the above techniques) Will be delivered using.

Achieving this integration requires relatively little effort because these technologies address a well-defined problem for most VPN solutions without developing VPN-specific integrations, and the authentication service provider (i.e., the authentication server 202) and an entity managing the client 201) secure remote access.

A method according to one embodiment of the present invention is shown in Fig. The method may be implemented within the context of the architecture illustrated in FIG. 5, but is not limited to any particular system architecture.

At 601, the user opens a browser and navigates to the SSL VPN gateway. At 602, the SSL VPN gateway renders a page containing browser executable code to trigger authentication on the client. At 603, the browser executable code establishes a connection with the authentication server to trigger the user's authentication. At 604, the browser executable code authenticates the user by exchanging messages between the authentication client and the authentication server (see, for example, the discussion above with respect to FIGS. 1A, 1B, 3 and 5). Once authenticated, the authentication server returns a ticket.

At 605, the browser executable code submits the ticket to the SSL VPN gateway, and at 606 the SSL VPN gateway verifies the ticket to the authentication server. As mentioned above, this may include comparing the ticket against the ticket returned in action 604 to verify the validity of the ticket (e.g., via RADIUS). Once the ticket is identified at 607, the SSL VPN gateway grants the user access to the protected internal network.

If the legacy system allows the use of digital certificates for authentication, an alternative approach to integration with legacy systems is possible. These solutions, such as VPNs, or Windows Active Directory using Kerberos, typically include client-side components for performing certificate authentication.

Unlike the integration approach outlined above, where the integration on the client side is primarily browser based (e.g., using JavaScript), the elements of the authentication client 201 in this embodiment are integrated into the client side software of the legacy solution to achieve integration , But as before, no server-side integration is required.

In the particular embodiment illustrated in FIG. 7, the authentication client 201 includes a credential provider component 711 for managing a signed certificate used to gain access to network resources via the coverler infrastructure 730 Respectively. For example, in one embodiment, the authentication client 201 uses the credential provider component 730 to authenticate the user via the Credential Provider Framework, Can be integrated into the operating system. It should be noted, however, that the underlying principles of the invention are not limited to a Coverrus implementation or any particular type of operating system.

This embodiment also relies on the communication between the authentication client (201) and the authentication server (725) entering a series of authentication transactions to authenticate the end user (e.g., as described above with respect to Figures 1B and 3) do. In one embodiment, the active directory 735 and the coverler infrastructure 730 are configured to trust the root certificate held by the authentication server 725. Once the user is authenticated, the authentication server 725 issues a short certificate containing the encrypted public / private key pair that signs using the root certificate held by the authentication server 725 (e.g., the private key of the root certificate To sign a short-term certificate). Specifically, in one embodiment, the public key of the short-term certificate is signed with the private key of the root certificate. In addition to the key pairs, the short-term certificate may also include timestamp / timeout data indicating the length of time the short-term certificate is valid (e.g., 5 minutes, 1 hour, etc.).

In one embodiment, once the credential provider 711 receives a signed short-term certificate from the authentication server, it enters a challenge response transaction that includes a coverler infrastructure 730 and a short-term certificate. In particular, the coverslus infrastructure sends a challenge (random data such as nonce) to the credential provider 711, which then signs the challenge using the private key of the short-term certificate. Subsequently, the short-term certificate is transmitted to the cover-less infrastructure, and (1) the cover-less infrastructure is created using the public key of the root certificate provided by the authentication server 725 Verify the signature on the certificate; (2) Verify the signature for the challenge using the public key from the short-term certificate. If both signatures are valid, then the Coveralls infrastructure then issues a Cover Russell ticket to the credential provider 711, which in turn authenticates the network resource, such as a file server, e-mail account, etc., You can use it to gain access to.

Using these techniques, the authentication server 725 and the client 201 can be integrated with the existing active directory 735 and the coverler infrastructure 730 without significant modification. Rather, it is only necessary that the Active Directory 735 / Cooper framework is configured to trust the root certificate held by the authentication server 725.

Figure 8 illustrates one embodiment of a method for integrating an online authentication infrastructure into a legacy system. The method may be implemented within the context of the architecture illustrated in FIG. 7, but is not limited to any particular system architecture.

At 801, the user opens a device such as a Windows device and attempts to log in. At 802, an authentication client is triggered to authenticate the user. The authentication client performs online authentication to the authentication server in response thereto. For example, as described above, the authentication client may have previously registered one or more authentication devices (e.g., fingerprint authentication device, voice authentication device, etc.) with the server. It is then possible to authenticate to the server using a series of transactions, such as those described above with respect to Figs. 1A, 1B and 3. For example, the authentication server may send an authentication request with a random challenge to an authentication client, which authenticates it using a private key associated with the authentication device being used. The authentication server can then use the public key to verify the signature.

Regardless of the particular protocol used for authentication, if the authentication is successful, at 803, the authentication server then returns a short digital certificate to the signed authentication client using the private key of the root certificate maintained by the authentication server. As mentioned, the root certificate is trusted by the Active Directory / Covers framework.

At 804, the authentication client then authenticates to the coverler infrastructure using a short digital certificate. For example, the coverler infrastructure may send a challenge (e.g., random data such as non-random) to the authentication client, which then uses the private key of the short-term certificate to sign the challenge. Subsequently, the short-term certificate is transmitted to the cover-less infrastructure, and at 805, the cover-less infrastructure uses the public key of the root certificate provided by the authentication server (the Cover-less infrastructure is configured to trust it) ≪ / RTI > Verify the signature for the challenge using the public key from the short-term certificate. If both signatures are valid, then the coverler infrastructure then issues a coverler ticket to the authentication client, and then at 806, the authentication client accesses network resources such as a file server, email account, etc., You can use it to get.

As a result, online authentication using authentication servers and authentication clients can be used for front-end authentication to legacy systems, thereby providing all the flexibility of efficient online authentication without requiring changes to the back-end legacy application infrastructure.

A number of advantages, including the following, are realized through the embodiments of the invention described herein, but are not limited thereto.

Reduced initial integration effort: Allowing the trustee to deploy online authentication without rewriting his application in integrating online authentication functionality or enabling integration with third-party federated servers.

Simplifying policy management: By expressing authentication policies as non-code, this approach allows organizations to easily update their authentication policies without requiring code changes. Changes to reflect new interpretations of regulatory commands or to respond to attacks on existing authentication mechanisms become simple policy changes and can be implemented quickly.

Enabling Future Improvements : As new authentication devices and mechanisms become available, organizations can assess the suitability of devices / mechanisms when addressing new or emerging risks. Integration of newly available authentication devices only requires adding the device to the policy, that is, no new code needs to be written to deploy new capabilities, even for legacy applications.

Direct token cost reduction: The legacy OTP approach relies on physical hardware tokens that are relatively costly on a per user basis (although the cost is getting cheaper) and tend to involve loss / break replacement cost problems. The online certification approach described herein can dramatically reduce deployment costs by leveraging the capabilities already available on the end user's device, eliminating the cost of each end user purchasing dedicated authentication hardware.

Indirect deployment costs: The OTP approach typically requires IT administrators to provision end-user tokens with an OTP verification server, while software-based desktop OTP generators still require help desk intervention during initial deployment. The online authentication approach can dramatically reduce deployment costs by leveraging capabilities already available on end-user devices and delivering a self-service registration model for deployment.

Improved end-user experience: The OTP approach requires users to manually populate the application with OTP as well as carry the OTP generator (which adds extra help desk costs to enable temporary access because many people forget it) Demand. The FIDO approach can dramatically reduce the impact of authentication on the end user by replacing user names / passwords and OTP entries with simpler ones, such as swiping a finger on a fingerprint sensor.

An exemplary data processing device

9 is a block diagram illustrating exemplary clients and servers that may be used in some embodiments of the present invention. Figure 9 illustrates various components of a computer system, but it should be understood that this is not intended to represent any particular architecture or manner of interconnecting components, as such details are not closely related to the present invention. It will be appreciated that other computer systems having fewer components or more components may be used in connection with the present invention.

9, a computer system 900 in the form of a data processing system includes a processing system 920, a power source 925, a memory 930 and a non-volatile memory 940 (e.g., a hard drive, flash memory , Phase change memory (PCM), and the like). The bus (s) 950 may be connected to one another via various bridges, controllers, and / or adapters as is well known in the art. The processing system 920 may retrieve the instruction (s) from the memory 930 and / or the non-volatile memory 940 and execute the instructions to perform the operations described above. The bus 950 interconnects the above components together and also includes such components as optional dock 960, display controller and display device 990, input / output devices 980 (e.g., a network interface (NIC), cursor control (e.g., a mouse, touch screen, touchpad, etc.), keyboard, etc.) and optional wireless transceiver (s) 990 (e.g., Bluetooth, WiFi, .

10 is a block diagram illustrating an exemplary data processing system that may be used in some embodiments of the present invention. For example, data processing system 1000 may include a handheld computer, a personal digital assistant (PDA), a mobile phone, a portable gaming system, a portable media player, a tablet, or a mobile phone, a media player, and / Lt; RTI ID = 0.0 > handheld computing device. In another example, data processing system 1000 may be a network computer, or an embedded processing device in another device.

According to one embodiment of the present invention, an exemplary architecture of data processing system 1000 may be used for the above-described mobile devices. Data processing system 1000 includes a processing system 1020 that may include one or more microprocessors and / or systems on integrated circuits. The processing system 1020 includes a memory 1010, a power source 1025 (including one or more batteries), an audio input / output 1040, a display controller and display device 1060, an optional input / output 1050, ) 1070 and the wireless transceiver (s) 1030. 10 may also be part of data processing system 1000 in certain embodiments of the present invention, and in some embodiments of the invention fewer components than those illustrated in FIG. 10 may be used . In addition, it will be appreciated that one or more buses not shown in FIG. 10 may be used to interconnect various components as is well known in the art.

Memory 1010 may store data and / or programs for execution by data processing system 1000. The audio input / output 1040 may include a microphone and / or a speaker to play music and / or provide a telephone function, for example, through a speaker and a microphone. The display controller and display device 1060 may include a graphical user interface (GUI). Wireless (e.g., RF) transceivers 1030 (e.g., a Wi-Fi transceiver, an infrared transceiver, a Bluetooth transceiver, a wireless cellular telephone transceiver, etc.) may be used to communicate with other data processing systems. One or more input devices 1070 allow the user to provide inputs to the system. Such input devices may be a keypad, a keyboard, a touch panel, a multi-touch panel, and the like. Another optional input / output 1050 may be a connector to the dock.

Embodiments of the present invention may include various steps as described above. The steps may be implemented with machine-executable instructions that cause a general purpose or special purpose processor to perform certain steps. Alternatively, these steps may be performed by specific hardware components including hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.

The elements of the present invention may also be provided as a machine-readable medium for storing machine executable program code. The machine-readable medium can be a floppy diskette, optical disk, CD-ROM and magneto-optical disk, ROM, RAM, EPROM, EEPROM, magnetic or optical card, or other type of media / But is not limited thereto.

In the foregoing description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without some of these specific details. For example, those skilled in the art will readily appreciate that the functional modules and methods described herein may be implemented as software, hardware, or any combination thereof. Moreover, although some embodiments of the present invention are described herein in the context of a mobile computing environment, the underlying principles of the invention are not limited to mobile computing implementations. Virtually any type of client or peer data processing apparatus, including, for example, desktop or workstation computers, may be used in some embodiments. Accordingly, the scope and spirit of the present invention should be determined in light of the following claims.

Embodiments of the present invention may include various steps as described above. The steps may be implemented with machine-executable instructions that cause a general purpose or special purpose processor to perform certain steps. Alternatively, these steps may be performed by specific hardware components including hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.

Claims (24)

A gateway configured to restrict access to the internal network;
An authentication server communicatively coupled to the gateway; And
A client device having a plurality of authentication devices coupled to it for authenticating a user, the authentication client configured to establish a communication channel with the authentication server and to register at least one of the authentication devices with the authentication server, Wherein the authentication devices are usable for performing on-line authentication to the authentication server after registration,
The authentication client authenticating the user to the authentication server using one or more of the registered authentication devices in response to an attempt to obtain access to the internal network via the gateway;
The authentication server providing a cryptographic data structure to the client device in response to successful authentication;
The client device providing the cryptographic data structure to the gateway as evidence of the successful authentication;
Wherein the gateway provides the access by the client device to the internal network when the gateway confirms the encrypted data structure to the authentication server and receives an indication from the gateway that the encrypted data structure is valid, . The method according to claim 1,
Further comprising a browser configured on the client device, wherein in response to the user's attempt to access the internal network through the browser, the gateway, when executed by the browser, And providing the browser executable code to trigger the authentication by establishing a communication channel between the clients. 3. The system of claim 2, wherein the cryptographic data structure comprises a ticket. 4. The method of claim 3, wherein the gateway is configured to provide the browser with a Hypertext Markup Language (HTML) form containing the browser executable code, the HTML form comprising one or more fields for entry of a username and one or more passwords . 5. The system of claim 4, wherein the ticket comprises a random number sequence or other form of one-time password (OTP) that can be submitted to the gateway via a field of the HTML form. 2. The system of claim 1, wherein the authentication server identifies the cryptographic data structure provided by the gateway using a key associated with the authentication device used for authentication. 7. The system of claim 6, wherein the gateway identifies the cryptographic data structure to the authentication server using a RADIUS (Remote Authentication Dial-In User Service) protocol. The system of claim 1, wherein the gateway comprises a secure socket layer (SSL) virtual private network (VPN) gateway. Network security infrastructure for providing network security services for internal networks;
An authentication server communicatively coupled to the existing network security infrastructure; And
A client device having a plurality of authentication devices coupled to it for authenticating a user, the authentication client configured to establish a communication channel with the authentication server and to register at least one of the authentication devices with the authentication server, Wherein the authentication devices are usable for performing on-line authentication to the authentication server after registration,
The authentication client authenticating the user to the authentication server using one or more of the registered authentication devices in response to an attempt to obtain access to the internal network;
The authentication server providing a cryptographic data structure to the client device in response to successful authentication;
Wherein the client device authenticates the network security infrastructure using the cryptographic data structure;
Wherein the network security infrastructure identifies the cryptographic data structure based on a trust relationship established for the authentication server, and wherein the network security infrastructure is configured to determine whether an access by the client device to the internal network . 10. The method of claim 9, wherein the cryptographic data structure comprises a digital certificate signed with a root certificate held by the authentication server and the trust relationship includes a network security infrastructure that trusts signatures generated using the root certificate Including the system. 11. The system of claim 10, wherein the digital certificate comprises a public / private key pair generated by the authentication server. 12. The system of claim 11, wherein the digital certificate comprises a timestamp or other data indicative of the length of time the digital certificate is valid. 13. The system of claim 12, wherein the authentication client signs a challenge provided by the network security infrastructure to authenticate the network security infrastructure using the digital certificate. 14. The system of claim 13, wherein the network security infrastructure is configured to verify the signature on the digital certificate using a public key of the root certificate provided by the authentication server having the trust relationship therewith, To verify the signature for the challenge using a public key of the system. 10. The system of claim 9, wherein the network security infrastructure comprises a Microsoft Active Directory and a Kerberos infrastructure. 10. The method of claim 9,
And a gateway for coupling the authentication client to the authentication server. Configuring a gateway to restrict access to the internal network;
Communicatively coupling an authentication server to the gateway; And
Configuring an authentication client of a client device with a communication channel with the authentication server and registering one or more authentication devices with the authentication server, the authentication devices being usable for performing online authentication with the authentication server after registration; / RTI >
The authentication client authenticating the user to the authentication server using one or more of the registered authentication devices in response to an attempt to obtain access to the internal network via the gateway;
The authentication server providing a cryptographic data structure to the client device in response to successful authentication;
The client device providing the cryptographic data structure to the gateway as evidence of the successful authentication;
Wherein the gateway verifies the cryptographic data structure for the authentication server and when the gateway receives an indication from the gateway that the cryptographic data structure is valid, the gateway provides the access by the client device to the internal network . 18. The method of claim 17, wherein a browser is configured on the client device, and in response to the user's attempt to access the internal network through the browser, the gateway, when executed by the browser, And providing the browser executable code that triggers the authentication by establishing a communication channel between the server and the authentication client. 19. The method of claim 18, wherein the cryptographic data structure comprises a ticket. 20. The method of claim 19, wherein the gateway is configured to provide an HTML form containing the browser executable code to the browser, wherein the HTML form has one or more fields for entry of a user name and one or more passwords. 21. The method of claim 20, wherein the ticket comprises a random number sequence or other form of one-time password (OTP) that can be submitted to the gateway via a field of the HTML form. 18. The method of claim 17, wherein the authentication server identifies the cryptographic data structure provided by the gateway using a key associated with the authentication device used for authentication. 23. The method of claim 22, wherein the gateway identifies the cryptographic data structure to the authentication server using a RADIUS protocol. 18. The method of claim 17, wherein the gateway comprises a secure socket layer (SSL) virtual private network (VPN) gateway.

Images