JPH0981520A - Collation server used for authentication on network - Google Patents

Abstract

PROBLEM TO BE SOLVED: To easily authenticate a user on a network. SOLUTION: An application server 10 sends authentication data, which is sent from a user host 20, to a collation server 30. The collation server 30 preliminarily holds correct authentication data in a data base and compares and collates sent authentication data with correct authentication data. The collation result is returned to the application server 10. The application server 10 authenticates the user based on the result. As a result, the constitution of the application server is simplified. The collation server 30 can be used by plural application servers 10 to efficiently operate the resources on the network.

Description

Detailed Description of the Invention

[0001]

TECHNICAL FIELD The present invention relates to a method for authenticating an application user. In particular, it relates to user authentication on the network.

[0002]

2. Description of the Related Art In a service business such as a bank, it is extremely important to confirm whether or not the other party is the principal at the time of a transaction, that is, authentication. This is to prevent another person from withdrawing money from the account by impersonating the person or transferring money.

[0003] Classically, for this authentication, for example,
Ask them to submit a driver's license, certain identification cards, etc.
Checking whether or not he / she is himself. In recent years, with the development of automatic cash drawers and the like, a method of authenticating an individual by using a magnetic card or a password has been widely adopted.

[0004] Such "authentication" is often required for other than banks. For example, in research institutes and the like, in order to prevent leakage of secrets, it is often the case that only authorized persons are allowed to enter a certain area, and other persons are restricted from entering. Membership clubs must also confirm that they are members in some way. It is also preferable to use the above magnetic card, password, membership card or the like in this research institute or membership club. However, there is a possibility that the magnetic card and the membership card are lost, and a possibility of forgetting the password is not small. Therefore, as a method of confirming the identity, a method of using a so-called biometric physical quantity such as a fingerprint or a retinal pattern as data for authentication (hereinafter referred to as authentication data) has been proposed.

In the electronic document approval process in a company, it is natural to use a signature to confirm the identity and to approve the person. In recent years, the use of CAD has become common in companies, and in the approval process, the shape of the signature data can be attached to the CAD data as image data.

[0006]

In recent years, with the development of networks, various services have been provided on these networks. For example, in the so-called Internet, services for providing multimedia titles such as WWW (World Wide Web) are widely performed. In the provision of such services, access may be granted only to certain qualified persons, similarly to services in general banks and the like. For services on such a network, "authentication" is a very important issue, as is the case with conventional services.

However, it is generally extremely difficult to use the above-mentioned biometric authentication data when authenticating the person on the network. For example, each terminal needs to be provided with a device for inputting a retinal pattern, a fingerprint, a palm print or the like, and a mechanism for transmitting such a physical quantity via a network is also newly required.

[0008] Therefore, the use of signature data is drawing attention as a biometric physical quantity used on a network. This signature data can be easily entered by using a so-called tablet,
Not only the dimensional data, but also the change in writing pressure and the speed at which the signature is written are used as data, and thus have excellent characteristics as authentication data for confirming whether or not the person is the person.
Furthermore, since tablets can be generally configured at low cost, the tablet has a feature that the cost of the terminal can be reduced.

As described above, in addition to authentication data such as a password, biometric authentication data such as signature data is used for "authentication" on the network.

However, with the expansion of networks, the types of application servers serving as service providers have increased, and the number of clients receiving the services has become extremely large. As a result, the burden on each application server when performing authentication separately has become excessive. In particular, in the case of the world wide spread like the Internet, there are many cases where an application server and a client who receives the service are extremely far away. In such a case, exchanging authentication data may lead to an increase in traffic on the network.

The present invention has been made to solve such a problem, and an object thereof is to provide a collation function for authenticating a client on a network on the network independently of an application server. This makes it possible to reduce the load on the application server and easily authenticate the client.

[0012]

In order to solve the above-mentioned problems, the first aspect of the present invention stores a correct authentication data of a user on a network and an external authentication data of a predetermined user. Related to the collation request, the retrieval unit retrieving the correct authentication data of the predetermined user from the storage unit in response to the collation request, and the correct authentication data retrieved by the retrieval unit in response to the collation request. A collation server that includes collation means for comparing and collating authentication data and transmission means for transmitting the result of the collation, and collates whether or not the authentication data is the authentication data of the predetermined user.

With such a configuration, the collation operation of the authentication data can be centrally performed, and can be appropriately used from a predetermined application server that needs to authenticate the user.

As a result, the collating function conventionally possessed by each application server or the like can be centrally managed on the network, so that effective use of resources becomes possible.

In order to solve the above problems, a second aspect of the present invention is the collation server according to the first aspect of the present invention, wherein the storage means stores the identification data of the user and the authentication data of the user. And further comprising table means consisting of predetermined data requested by a collation server for the user, wherein the search means can retrieve the correct authentication data from the storage means based on the identification data of the user. The verification server is characterized in that the correct authentication data can be retrieved from the storage means based on the predetermined data.

As described above, since the index for extracting the "correct" authentication data is composed not only of the user's identification data but also of predetermined data, even if the user forgets the identification data. It is possible to extract authentication data from other data.

For example, it is preferable to use the user's name, telephone number, date of birth, etc. as the predetermined data. Further, blood types and the like can be used as long as they contribute to the identification of the user to some extent.

In order to solve the above-mentioned problems, the third aspect of the present invention, in the collation server of the above-mentioned first aspect of the present invention, reads the correct authentication data of the user from the storage means in response to a collation preparation request, The collation server includes a cache control unit that is stored in advance in a cache unit that has a faster reading speed than the storage unit.

According to the third aspect of the present invention, the "correct" authentication data is read in advance in the cache in response to the collation preparation request, so that when the authentication data of a predetermined user is actually sent, the authentication data can be promptly sent. It is possible to start the matching operation.

Therefore, it is possible to speed up the authentication operation.

[0021]

BEST MODE FOR CARRYING OUT THE INVENTION Preferred embodiments of the present invention will be described below with reference to the drawings.

FIG. 1 shows an application server (A) provided on the network in this embodiment.
user host (User Host) 20 that uses the service of the application server 10
And a collation server (Server) 30 used for authentication of the user host 20 are arranged on a network.

A feature of this embodiment is that the collating operation for authenticating the user host 20 is not performed by the application server 10 but is provided separately from the application server 10 on the network. This is performed by using the matching verification server 30. As described above, by providing the collation server 30 performing the collation operation on the network independently of the application server 10, each application server 10 can hold “correct” authentication data for authenticating the user host 20, There is no need to have a function for In FIG. 1, the application server 10
Although only one configuration is shown, it is also preferable to provide a plurality of application servers 10 on the network. In this case, the plurality of application servers 10 use one collation server 30 to perform “collation”. The operation can be entrusted, and the authentication data collation function conventionally provided in a plurality of application servers 10 can be integrated into one, and efficient resource operation becomes possible.

It is also preferable to provide a plurality of the collation servers 30 on the network. Then, each application server 10 can use a suitable collation server according to the contents of the authentication. For example, it is conceivable to change the matching server 30 to be used depending on whether the signature data is used as the authentication data or the fingerprint data is used as the authentication data. Alternatively, it is conceivable that each user specifies the collation server 30 which holds his / her authentication data.

As shown in FIG. 1, the collation server 3
By providing 0 on the network independently of the application server 10, the exchange of messages at the time of authentication becomes as shown by an arrow in FIG. 1, for example. As shown in FIG. 1A, first, the application server 10 requests the user host 20 to send the authentication data (indicated by a in FIG. 1A). For the authentication data, a password or a member number can be classically used, but it is preferable to use a biometric physical quantity, for example, signature data.
In particular, as described above, the signature data is stored in the user host 2
It is possible to input easily by preparing an inexpensive tablet for 0.

In response to the request a, the user host 20 inputs the user's signature data from the tablet and sends it back to the application server 10 together with the user's identification data (for example, membership number or user name) (see FIG. 1 ( b in a)
Indicated by). In the application server 10, this authentication data is stored in advance and collated with "valid" authentication data to judge whether or not the user host 20 is a correct user. That is, it is outsourced to the external verification server 30. Therefore, the application server 10 uses the user host 2
A message including the authentication data and the identification data sent from 0 is sent to the matching server 30 to request matching (shown by c in FIG. 1A).

Upon receiving the message including the authentication data and the identification data sent from the application server 10, the verification server 30 checks whether the authentication data is valid authentication data. The verification server 30 internally holds a user name, which the user host 20 claims to be the user, and correct authentication data of the user, as a database. Then, by searching this database, the correct authentication data for the user who claims that the user host 20 is the principal, for example, signature data in this embodiment, is retrieved. Then, the extracted authentication data is compared and collated with the authentication data sent from the application server 10, and the result is returned to the application server 10 (FIG. 1 (a)).
At d). The application server 10 authenticates the user host 20 based on the collation result returned from the collation server 30.

In the present embodiment, the portion for performing the collation operation in this manner is provided on the network independently of the application server 10, so that the collation that is commonly provided for a plurality of application servers 10 is performed. It is possible to save the functions and ensure the authenticity of the authentication operation.

In FIG. 1A, the signature data (authentication data) sent from the user host 20 is supplied to the collation server 30 via the application server 10. Sending is also suitable.

FIG. 1B shows an example in which the authentication data is directly sent from the user host 20 to the verification server 30. According to the example shown in FIG. 1B, first, the application server 10 requests the user host 20 to send the authentication data to the verification server 30 (shown by e in FIG. 1B). ).

The user host 20 inputs the user's signature data from the tablet in response to the request e, and sends the signature data to the collation server 30 (indicated by f in FIG. 1B). The application server 10 determines whether or not the user host 20 is a correct user, but entrusts the external verification server 30 with the “verification” action required for the authentication. Therefore, the collation server 30 stores the authentication data sent from the user host 20 in advance and collates it with “valid” authentication data. Similar to the example shown in FIG. 1A, the collation server 30 internally holds a user name, which claims that the user host 20 is the user, and the correct authentication data of the user, as a database. There is. Then, by searching this database, the correct authentication data for the user who claims that the user host 20 is the principal is retrieved. Then, the extracted authentication data is compared with the authentication data sent from the user host 20.
It collates and sends the result to the application server 10 (indicated by g in FIG. 1). The application server 10 authenticates the user host 20 based on the collation result returned from the collation server 30.

In each of FIGS. 1A and 1B, the application server 10 may be a server that provides various services such as a WWW server on the Internet or various databases.

FIG. 2 shows the user host 20, the application server 10, and the collation server 3 shown in FIG.
0 is a configuration block diagram showing a detailed configuration of 0.
FIG. 2A is a configuration diagram corresponding to FIG. As shown in FIG. 2A, the user host 20
It is composed of terminals such as personal computers,
A netscape (Netscape) 52 for connecting to the Internet and connecting to the WWW server 42 is provided. In this embodiment, the netscape 52 is used, but this is a mosaic (Mosaic).
For example, another WWW browser may be used. The user host 20 has, besides the netscape 52, a tablet (Tablet) 54 for the user to input signature data.
It has. Also, a tablet driver program 56 for controlling the tablet 54 and extracting signature data is provided. This tablet driver program 56 receives the request via the Netscape 52 when the application server 10 sends a request to send the authentication data, and drives the tablet 54 to obtain the authentication data (signature data). Is sent to the application server 10. FIG.
Message exchange a, b, shown in (a)
The same reference numerals a, b, c and d for the same message exchanges as those of c and d are also given in FIG.

The application server 10 is a Unix server.
Often built on machines. The application server 10 includes a WWW server 42 for providing a multimedia title as shown in FIG.
A signature verification request program 44 for confirming the validity of the user is provided. The collation server 30 is constructed on a machine such as Unix like the application server 10, and has registration data 62 in which a legitimate user and the authentication data of the user are registered. And
The signature verification request of the application server 10 is performed based on the user name (user identification code) sent from the signature verification request program 44 and the authentication data sent from the user host 20. Return to program 44.

The configuration diagram corresponding to FIG. 1B is shown in FIG.
It is shown in (b). The configurations of the application server 10, the user host 20, and the matching server 30 in FIG. 2B are exactly the same as the configurations shown in FIG. 2A. The difference is that a request for collation is issued directly from the driver program of the user host 20 to the collation server 30. 2A and 2B, except that the verification server receives the authentication data to be verified from the user host 20 or the application server 10.
Is exactly the same as. In addition, FIG. 2B shows FIG.
Corresponding to, the exchanged messages are given the symbols e, f, g.

In the present embodiment, the registration data 62 of the collation server 30 is managed by a relational database (hereinafter, referred to as RDB). FIG. 3 shows the state of the registration data in the RDB. As shown in FIG. 3, the registration data is recorded in the form of a table in which predetermined data is recorded for each valid user. As shown in the figure, first, a flag (flag) is a flag for indicating various states of the system, and is used as a deletion flag (for example, indicating whether the user has been deleted from the system) or the like. Can be The system unique key (SysUniq Key) is a system key given to each user, and is uniquely set in the table (shown in FIG. 3) in the verification server 30.
The registered tablet type indicates the type of tablet used by the user. In addition, signature data (Sig
Nature data) is time-series data representing the movement of the electronic pen moving on the tablet. Since this signature data includes not only the information indicating the two-dimensional position but also the writing pressure and the pen speed information, it is possible to accurately authenticate the person. is there.

As described above, the RDB in the collation server 30
Since the system unique key and the signature data are registered in, the signature data sent from the application server 10 and the system unique key representing the user are used to validate the sent signature data. It is possible to determine whether or not it is. The contents of the result of this determination will be described later.

In the RDB of this embodiment, in addition to the system unique key and signature data, system required items (System required items)
Is stored. As shown in FIG. 3, the system request items include the user name (Name) and the user's birthday (Date of bi).
rth) and the user's telephone number (Phone #) are registered. These system requirements are used in place of the system unique key. That is, the system unique key is a key for identifying the user held by the application server and the matching server as described later, but the user must remember the system unique key given to him / her. Not necessarily. Therefore, when the user wants to confirm the registered signature data, it is desirable that there is a means for specifying the user by using a means other than the system unique key. In such a case, in addition to the system unique key, the user can be identified by the user's name, birthday, telephone number, and the like.

System required items in this embodiment (System required items)
Corresponds to the “predetermined data requested by the matching server 30 for the user” of the present invention. The system unique key according to the present embodiment corresponds to the "user identification code" of the present invention.

As described above, in the present embodiment, the "correct" authentication data is not limited to the system unique key,
Since the predetermined data can be read out, even if the user forgets the system unique key, it is possible to confirm the authentication data from the telephone number or the like.

Further, in this embodiment, as shown in FIG. 3, an optional field (Opti
online fields) are provided. The data registered in this optional field is so-called system audit data, and is management data used when a network administrator manages the operation of the matching server 30. As shown in FIG. 3, the data for management includes a data creation date (Creation Date).
date), the creator of the data (Creation h
ost) and the last access date (Last acc.
date) and the last accessor (Last acc.
by), other access count (access cou)
nt) and the number of times matching failed (failure cou
nt) can be registered.

Further, the application server 10 is also provided with an RDB in which information about users is registered corresponding to the RDB in the collation server 30. Contents registered in the RDB in the application server 10 are shown in FIG. As shown in FIG. 4, various types of registration data are registered for each user. FIG.
As shown in FIG. 1, first, the “verification server name” indicates by which verification server the verification data (signature data) sent by the user should be verified. In the configuration diagram shown in FIG. 1, the collation server 3
Although only one 0 is shown, it is possible to have a plurality of matching servers 30 in the network. For example, each user may want to use a collation server 30 that is easy for him to contact, and the application server 10 may want to change the collation server for each user for administrative reasons. There will be cases.

The flag and system unique key (Sys Uniq Key) shown in FIG. 4 are the same as the flag and system unique key in FIG. This system unique key is uniquely determined in the RDB of the collation server 30 as described above. In other words, there is a possibility that the same system unique key is assigned to users having different collation servers 30. Therefore, the user is strictly identified by combining the system unique key and the matching server name. Application user key (App. User
key) is a key indicating whether or not the service provided by the application server 10 can be received. In some cases, as shown in FIG. 4, additional application user keys (Additional app.
user key) may be set. In addition, as shown in FIG.
ate) and the last access date (Last acc. da)
te), the last accessor (Last acc. b)
y), the number of accesses (access count), the number of times the verification failed (failure count), and the like are registered corresponding to the RDB in the verification server 30 shown in FIG. Although the specific item names are not shown, the application optional field (A
application optionalfield
It is also preferable to register predetermined registration data used by the application in s).

FIG. 5 is an explanatory diagram of protocols supported by the collation server 30 according to this embodiment. As shown in FIG. 5, first, in the protocol “key registration”, the application server 10 sends a message including predetermined required items to the collation server 30. The collation server registers these required items in the RDB and generates a system unique key. This system unique key is registered in the RDB and returned to the application server 10. In this way,
The system unique key that identifies the user is the matching server 3
0 is generated. This system unique key is also registered in the RDB in the application server 10, and the collation server 30 and the application server 10 share the system unique key.

Next, in the protocol "registration of signature data", the application server 10 sends the system unique key, three signature data, tablet type, etc. to the verification server 30 to verify the "correct" signature data. It is registered in the RDB in the server 30. Here, the reason why the three pieces of signature data are transmitted is that the average value of the signature data is obtained by the collation server and the average value is registered in the RDB. When the registration is completed normally, the return value “ok” is returned to the application server 10, and when the registration is already performed, “error” is returned as the return value. If the three pieces of signature data are significantly different from each other, the reliability of the signature data is low, and therefore "unstable" is not performed.
Is returned as a return value.

In the protocol "preparation for collation", the application server 10 sends only the system unique key to the collation server 30, and the "correct" authentication data is sent to the R server.
Let the cache call it from the DB. in this way,
By calling the authentication data in advance prior to the verification protocol with the actual authentication data, a quick verification process can be performed as described later. This protocol is performed for speeding up the processing. If speeding up is not necessary, the protocol may be omitted and a “collation” protocol described later may be directly issued. Note that the message ID is returned to the application server 10 when the call of the “correct” authentication data is normally completed, but when an error occurs, “error” is returned to the application server 10 as a return value.

The protocol "verify" is defined by the user host 20.
Alternatively, the protocol is such that the application server 10 sends the system unique key, the signature data, the tablet type, and the message ID to the collation server 30 to perform the collation operation. As the message ID, the message ID returned as a return value when the “collation preparation” protocol has been issued first is used. As will be described later, the matching result is sent to the application server 10, and at this time, this message ID is used as a tag for identifying which user is authenticated. That is, in the present embodiment, this message ID
Is an identification number for authentication, and is also an ID indicating that the authentication data has already been called in the cache. In this case, the first generation of the message ID is performed by the collation server 30 and is added to the message when a response to the collation preparation request is made.

On the other hand, if the "collation preparation" protocol has not been issued, this message ID serves only as an identifier for identifying to which user the authentication is made. In this case, the first creation of the message ID is the application server 20.

Now, the collation server 30 can know whether or not the authentication data has already been read into the cache by checking whether or not this message ID is given by itself. If the "correct" authentication data has already been called, the data is compared and collated with the sent authentication data. When the “correct” authentication data has not been called, the RDB newly calls the “correct” authentication data and the comparison / verification operation is performed.

As a result of the comparison and collation, when it is judged that the both are very close and correct authentication data, “yes” is sent to the application server 10 as a return value. On the other hand, if the sent authentication data is completely different from the "correct" authentication data, "no" is sent as the return value. If it is not clear whether the authentication data is correct or not as a result of comparison / verification, the return value is "m".
“Aybe” is sent to the application server 10. If you do not know what to do, use each application server 1
Although it may be different for each 0, for example, a procedure such as forcing the user to redo the signature will be taken. In addition, when “correct” authentication data for comparison / collation cannot be found, “error” is returned to the application server 10 as a return value.

Next, how an actual user is authenticated will be described with reference to FIG. Hereinafter, this user is referred to as an application client (FIG. 6). First, the application client is the user host 2
A connection request is made to the application server 10 via 0.

In response to this, the application server 1
0 requests the application client to input an application key. In response to this, a prompt for inputting the application key is displayed on the display device of the user host 20.

When the application client inputs a predetermined key on the user host 20, the data is sent to the application server 10.

Upon receiving this key data, the application server 10 sends a request for verification of signature data verification to the verification server 30. This collation preparation request is made for speeding up the processing as described above, and can be omitted.

Upon receiving the collation preparation request, the collation server 30 reads the authentication data from the RDB, stores it in the cache, and sends the message ID and the encryption key to the application server 10, as described above. The encryption key is a key used for encrypting communication data, and need not be sent if encryption is not required.

Upon receiving the message ID and the like, the application server 10 outputs a signature input request so that the application client can input a signature.

In response to this signature input request, the server host 2
At 0, the signature input program starts. Based on the activation of this program, the application client signs using the tablet 54 provided in the user host 20.

In the configuration corresponding to FIG. 1A, the user host 20 sends the signature data input from the tablet 54 to the application server 10. Then, the application server 10 issues a collation request including the received signature data to the collation server 30.
On the other hand, in the configuration corresponding to FIG. 1B, the user host 20 sends the signature data input from the tablet 54 to the verification server 30 (a verification request). At this time, FIG.
As shown in (1), the key data and the message ID are sent to the verification server 30 together with the signature data.

The collation server 30 performs collation based on the collation request, and returns the result to the application server 10. When the collation request is sent from the application server 10, the destination of the collation result is the application server 10 that issued the collation request. on the other hand,
When the verification request is sent from the user host 10, the message ID sent at the same time as the verification request
Based on the above, the application server 10 to which the matching result is to be transmitted is specified.

The application server 10 authenticates based on the collation result. The operation at this time differs depending on each application server 10, but if the authentication data match, "authentication" will be given, and if they do not match, "authentication" will not be given or the signature will be retried. .

As described above, according to the present embodiment, since the collating operation performed at the time of authentication is entrusted to the external collating server, the load on the application server is reduced and the collating operation is simplified. By using a single collation server by multiple application servers, more effective use of resources on the network is achieved.

[0062]

As described above, according to the first aspect of the present invention, the collation operation is intensively performed by the collation server, whereas each application server or the like conventionally performs the collation operation individually. The configuration of each application server can be simplified. Therefore, the resources on the network can be effectively used, and the centralized management of the user authentication data can be realized.

According to the second verification server, the authentication data can be accessed not only from the user's identification data but also from other predetermined data, so that the authentication data can be confirmed even if the identification data is lost. There is an effect that can.

Further, according to the third aspect of the present invention, it is possible to obtain a collation server capable of quick collation operation.

[Brief description of drawings]

FIG. 1 is a configuration diagram showing a configuration of an embodiment of the present invention.

FIG. 2 is an explanatory diagram illustrating details of a configuration according to an embodiment of the present invention.

FIG. 3 is an explanatory diagram illustrating a configuration of an RDB in a collation server.

FIG. 4 is an explanatory diagram illustrating a configuration of an RDB in an application server.

FIG. 5 is an explanatory diagram showing a protocol supported by the matching server.

FIG. 6 is an explanatory diagram showing exchange of messages in the present embodiment.

[Explanation of symbols]

10 application servers, 20 user hosts,
30 verification server, 42 WWW server, 44 signature verification request program, 52 netscape, 54 tablet, 56 tablet driver program, 62
Registration data.

Claims (3)

[Claims] 1. A storage unit for storing correct authentication data of a user on a network, and a correct authentication of the predetermined user from the storage unit in response to an external collation request relating to the authentication data of the predetermined user. Retrieval means for retrieving data, collating means for comparing and collating the correct authentication data retrieved by the retrieving means with the authentication data for the collation request in response to the collation request, and sending out the result of the collation And a means for verifying whether or not the authentication data is authentication data of the predetermined user. 2. The collation server according to claim 1, wherein the storage means includes identification data of the user, the authentication data of the user, and predetermined data requested by the collation server for the user. And a table means consisting of, the search means can retrieve the correct authentication data from the storage means based on the identification data of the user, and also based on the predetermined data from the storage means A collation server capable of extracting correct authentication data. 3. The collation server according to claim 1, wherein in response to a collation preparation request, the correct authentication data of the user is read from a storage unit and stored in advance in a cache unit having a faster reading speed than the storage unit. A collation server comprising: cache control means.