SYSTEM AND METHOD FOR MANAGING AUTHENTICATION SERVICES

Abstract

There is disclosed a method of providing an authentication service, wherein: i) a plurality of authentication virtual appliances is deployed in a distributed network by way of an authentication management platform application; ii) a pool of authentication licences is allocated to the authentication management platform application, each licence comprising computer code permitting an end user to authenticate his/her identity to at least one authentication virtual appliance by way of a predetermined computer-implemented authentication protocol; and iii) the management platform application allocates, revoke and reallocate authentication licences, from the pool of authentication licences, to end users by way of a graphical user interface.

Claims

1. A method of managing hardware tokens in an authentication service, wherein: at least one hardware token comprising a securely stored seed and a token identifier is provided by a service provider; the service provider associates the seed of the hardware token with the token identifier of the hardware token on a secure server operated by the service provider; the service provider makes the hardware token and the token identifier available to a customer; and the customer assigns the hardware token to an end user and operates an authentication server in which the token identifier is associated with the identity of the end user to whom the hardware token is assigned; wherein the seed of the hardware token is securely made available to the customer's authentication server by the service provider's server for association with the token identifier without being accessible by the customer or the end user; and wherein the authentication server authenticates the identity of the end user to the customer by way of a cryptographic challenge based on the seed of the hardware token.

2. A method according to claim 1, wherein the seed of the hardware token is stored on a secure partition on the authentication server that is not accessible by the customer.

3. A method according to claim 1, wherein the cryptographic challenge is a time-based one-time password, TOTP, challenge.

4. A method according to claim 1, wherein the cryptographic challenge is a hash-based message authentication code one-time password, HOTP, challenge.

5. A system for managing hardware tokens in an authentication service, the system comprising: at least one hardware token comprising a securely stored seed and a token identifier; a secure server operating by a service provider; and an authentication server operated by a customer; wherein the secure server is configured to associate the seed of the hardware token with the token identifier of the hardware token; wherein the authentication server is configured to associate the token identifier with an identity of an end user to whom the hardware token is assigned; wherein the authentication server is configured to receive the seed of the hardware token securely from the secure server and to associate the seed with the token identifier on the authentication server without the seed being accessible to the customer or the end user; and wherein the authentication server is configured to authenticate the identity of the end user to the customer by way of a cryptographic challenge based on the seed of the hardware token.

6. A system as claimed in claim 5, wherein the authentication server is configured to store the seed of the hardware token on a secure partition that is not accessible by the customer.

7. A system as claimed in claim 5 or 6, wherein the cryptographic challenge is a time-based one-time password, TOTP, challenge.

8. A system as claimed in claim 5 or 6, wherein the cryptographic challenge is a hash-based message authentication code one-time password, HOTP, challenge.

9. An authentication server of a system for managing hardware tokens in an authentication service, wherein: the authentication server is operated by a customer of a service provider; the authentication server is configured to associate a token identifier of a hardware token with an identify of an end user to whom the hardware token is assigned; the authentication server is configured to receive a seed of the hardware token from a secure server operated by the service provider and to associate the seed of the hardware token with the token identifier of the hardware token without permitting access to the seed by the customer or the end user; and the authentication server is configured to authenticate the identity of the end user to the customer by way of a cryptographic challenge based on the seed of the hardware token.

10. An authentication server as claimed in claim 9, wherein the authentication server is configured to store the seed of the hardware token on a secure partition that is not accessible by the customer.

11. An authentication server as claimed in claim 9, wherein the cryptographic challenge is a time-based one-time password, TOTP, challenge.

12. An authentication server as claimed in claim 9, wherein the cryptographic challenge is a hash-based message authentication code one-time password, HOTP, challenge.

13. A method of providing an authentication service, wherein: i) a plurality of authentication virtual appliances is deployed in a distributed network by way of an authentication management platform application; ii) a pool of authentication licences is allocated to the authentication management platform application, each licence comprising computer code permitting an end user to authenticate his/her identity to at least one authentication virtual appliance by way of a predetermined computer-implemented authentication protocol; and iii) the management platform application allocates, revoke and reallocate authentication licences, from the pool of authentication licences, to end users by way of a graphical user interface.

14. A computer-implemented authentication management platform application configured for implementation in a distributed network in which is deployed a plurality of authentication virtual appliances, wherein a pool of authentication licences is allocated to the authentication management platform application, each licence comprising computer code permitting an end user to authenticate his/her identity to at least one authentication virtual appliance by way of a predetermined computer-implemented authentication protocol; and wherein the management platform application is configured to allocate, revoke and reallocate authentication licences, from the pool of authentication licences, to end users by way of a graphical user interface.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0075] Embodiments of the invention are further described hereinafter with reference to the accompanying drawings, in which:

[0076] FIG. 1 is a schematic illustration of a high level architecture of an embodiment of the disclosure;

[0077] FIG. 2 is a schematic illustration of an MSP services layer of an embodiment of the disclosure; and

[0078] FIG. 3 is a schematic illustration of a secure server, authentication server and hardware token system of an embodiment of the disclosure.

DETAILED DESCRIPTION

[0079] FIG. 1 shows a high level architecture of an embodiment of the disclosure. A GUI element 1, which is responsible for interaction with a user interface, grabs display patterns from graphical templates 2 and passes user actions to a second layer 3.

[0080] The second layer 3 may, for example, be implemented an industry-standard authentication and access-control framework for secure I/O scrutiny, such as provided by Spring Security from Pivotal Software, Inc.

[0081] If the requests are passed as “clear” by the framework security scrutiny in the second layer 3, they are passed to a controller layer 4. The controller layer 4 is responsible for controlling business logic values and IAM (Identity and Access Management) validation. The prime function is to verify who is changing what, where any changes are being made, and if the changes are acceptable.

[0082] Once a request has cleared the controller layer 4, the request passes to a services layer 5, which may implement real “business logic” or “use case logic”.

[0083] The services layer 5 can delegate data persistency on a repository layer 6 and on an API (Application Program Interface) layer 7. The API layer 7 may provide an interaction dashboard to allow different APIs to be called as required, such as CMI (Content Management Interface) layer 8, an ASP.NET Core layer 9, and an SSO (Single Sign-On) layer 10. The repository layer 6 has access to a database 11, for example by way of JDBC (Java Database Connectivity).

[0084] The services layer 5 also has access to a utility layer 12 comprising appropriate reusable software tools.

[0085] FIG. 2 shows an MSP (Managed Service Provider) services layer of an embodiment of the disclosure. The MSP services layer may comprise: i) Alert 13 (responsible for sending email alerts); ii) Billing service 14 (collects data form each appliance under management for billing purposes); iii) Component 15 (responsible for collecting and preparing dashboard data); iv) Instance clone service 16 (handles VCenter API link and commands); v) Instance log service 17 (gets and processes appliance logs); vi) Instance server 18 (provides in-instance management of services and configurations); vii) Licence service 19 (responsible for communicating with a licence server and updating running machines/appliances on the fly); viii) Logging and event service 20 (manages the logging events from an ESXi appliance); ix) Parameters service 21 (responsible for managing the requests and respective configuration parameters); x) Reporting service 22 (manages and aggregates reports); xi) Roles service 23 (IAM supporting local “by role” authorisation); xii) Scheduler service 24 (reports events and time slot management service); xiii) Token manager 25 (manages, synchronises, assigns and reassigns physical tokens); xiv) User service 26 (user management tools and functions).

[0086] FIG. 3 is a schematic illustration of an embodiment comprising a secure server 31 operated by a service provider, such as an MSP or MSSP, an authentication server 34 operated by a customer, such as a bank, and a hardware token 36 operated by an end user, such as an account holder with the bank.

[0087] The secure server 31 is secured behind a firewall 311 or other security measures, and includes a database 39 in which a plurality of hardware token seeds 32 is associated with a corresponding plurality of hardware token identifiers 33 in one-to-one relation. The database 39 may be subdivided into separate databases for different customers.

[0088] The authentication server 34 is operated by the customer, and receives the seeds and the token identifiers securely from the secure server 31 by way of a secure link 312. The seeds 32′ received from the secure server 31 are held in a secure partition 310 of the authentication server 34 and are not accessible by the customer. The token identifiers 33′ received from the secure server 31 are accessible by the customer so as to allow the customer to assign tokens 36 to individual end users. Although the seeds 32′ are not accessible by the customer, they are stored in one-to-one relation with the token identifiers 33′. The authentication server 34 includes a processor 35 running a predetermined cryptographic algorithm configured to generate pseudorandom numbers on the basis of the seeds 32′ and other parameters as appropriate.

[0089] The hardware token 36 (in practice, there will be a plurality of hardware tokens 36 issued to a corresponding plurality of end users) is a small electronic device programmed on manufacture with a seed 32″ and a token identifier 33″, which may conveniently be stored in ROM. The hardware token 36 further comprises a processor 35′ running the same cryptographic algorithm as the processor 35 of the authentication server 34. The hardware token 36 includes an activation button 38 that, when pressed, causes the processor 35′ to generate a pseudorandom number by way of the cryptographic algorithm on the basis of the seed 32″ and to display the pseudorandom number on a display 37.

[0090] In order for an end user to authenticate himself/herself to the customer, a typical two-factor authentication process may be employed. The end user operates a client device 314 (for example, a PC or tablet or mobile handset) that communicates with the authentication server 34 by way of a link 313, which may be by way of the Internet. For example, the end user may navigate to a secure log in page on the Web, where the end user enters a user ID and (optionally) a password. This represents a first factor of a two-factor authentication process, and lets the authentication server know that a particular end user wishes to gain access. The authentication server 34 then requests the end user to generate a pseudorandom number using the hardware token 37 as previously described and to enter the pseudorandom number on the client device 314. The pseudorandom number entered by the end user is then transmitted to the authentication server 34. The authentication server 34 already knows the token identifier 33′ of the hardware token 36 that has been assigned to the authorised end user, and hence knows the seed 32′ of the hardware token 36. Accordingly, the processor 35 of the authentication server 34 can run the same cryptographic algorithm as that run by the processor 35′ of the hardware token 36, using the same seed 32′ and other relevant parameters (such as time or count), to generate a pseudorandom number (or selection of pseudorandom numbers). If there is a match between the pseudorandom number generated by the hardware token 36 and entered by the end user on the client device 314 and the pseudorandom number(s) generated by the authentication server 34, the identity of the end user is verified. This is the second factor in the two-factor authentication process.

[0091] The hardware token 36 can take forms other than that shown in the specific example of FIG. 3. For example, the hardware token 36 may be implemented as a USB or Bluetooth® dongle and be configured to provide the pseudorandom number directly to the client device 314 without the need to the end user to type in the pseudorandom number. In these embodiments, there is no need for the hardware token 36 to be provided with a display. Other variations will be apparent.

[0092] The processor 35′ of the hardware token 36 and the processor 35 of the authentication server 34 may use TOTP or HOTP or other seed-based protocols.

[0093] Throughout the description and claims of this specification, the words “comprise” and “contain” and variations of them mean “including but not limited to”, and they are not intended to (and do not) exclude other moieties, additives, components, integers or steps. Throughout the description and claims of this specification, the singular encompasses the plural unless the context otherwise requires. In particular, where the indefinite article is used, the specification is to be understood as contemplating plurality as well as singularity, unless the context requires otherwise.

[0094] Features, integers, characteristics, compounds, chemical moieties or groups described in conjunction with a particular aspect, embodiment or example of the invention are to be understood to be applicable to any other aspect, embodiment or example described herein unless incompatible therewith. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. The invention is not restricted to the details of any foregoing embodiments. The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

[0095] The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.