JP7301682B2 - Management system, method and program - Google Patents

Description

The present invention relates to a management system, method and program.

2. Description of the Related Art Conventionally, a management apparatus that manages an image forming apparatus (hereinafter also referred to as a device) such as a printer or a multi-function peripheral acquires information from the device using communication such as SNMP or HTTP, and processes the device. give instructions. SNMP is an abbreviation for Simple Network Management Protocol, and HTTP is an abbreviation for Hyper Text Transfer Protocol.

Authentication information is required when the management apparatus connects to the device using these communications. For example, in the case of SNMP version 1 or version 2, the community name set in the device must match the community name set in the SNMP request sent by the management device. For example, when connecting to a device using HTTP, authentication information that matches authentication information set in the device must be set in HTTP header information or the like. Therefore, the management apparatus needs to manage authentication information used when accessing each device for each type of communication.

For this authentication information management method, it has been proposed to determine appropriate authentication information from a plurality of candidates according to the type of device to be managed (see, for example, Patent Document 1). Alternatively, when authentication information is managed for each function in a management application, it has been proposed to use management information set by other functions (see Patent Document 2, for example).

JP 2009-110261 A JP 2013-16143 A

For devices managed by a management apparatus, various types of authentication are performed for each device according to, for example, the model, configuration, and organization of the device. Therefore, when operating a management apparatus that manages a plurality of devices, setting and managing different authentication information for each device is very troublesome for the user.

The management system of one embodiment includes management means for managing information required for authentication, which is registered at least one for each protocol as common authentication information, and authentication required when communicating with a network device. In this case, if the authentication information to be used for the communication is undecided, the communication means for trying the authentication process with the network device by sequentially using the managed common authentication information one by one, and the authentication is successful. and storage means for storing the authentication information used in the authentication in association with the network device. When authentication is required when communicating with the network device, the communication means does not perform the above-mentioned attempt if the authentication information used for the communication is stored. Communicate using information.

According to the management system of one embodiment, it is possible to efficiently set and manage authentication information for each network device, which is used when communicating with the network device.

1 is a block diagram showing the overall configuration of a network device management system and components of each application; FIG. It is a block diagram which shows the hardware configuration example of a management apparatus. FIG. 10 is a diagram showing a display example of a common authentication information management screen and a common authentication information editing screen. 9 is a flowchart for explaining processing for confirming authentication information; FIG. 11 is a flowchart illustrating processing for acquiring a list of common authentication information; FIG. FIG. 10 is a flowchart for explaining processing when connecting to a device using a web service; FIG. FIG. 10 is a diagram showing a display example of a common authentication information management screen and a common authentication information editing screen. 9 is a flowchart for explaining processing for confirming authentication information; FIG. 11 is a flowchart illustrating processing for acquiring a list of common authentication information; FIG. FIG. 12 is a block diagram showing the overall configuration of a network device management system and components of each application in the third embodiment; 14A and 14B are diagrams showing display examples of a common authentication information management screen and a common authentication information editing screen in the third embodiment; FIG. FIG. 11 is a flow chart illustrating processing for specifying an agent and acquiring common authentication information; FIG.

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings.

(First embodiment)
FIG. 1 shows an example of the overall configuration of a network device management system according to the first embodiment. In FIG. 1, a management apparatus 102 and devices 103, 104, and 105 are connected by a network 106, respectively.

The devices 103, 104, and 105 are network devices managed by a device management application 101 of the management apparatus 102, which will be described later. Examples of the devices 103, 104, and 105 include various peripheral devices that can be connected to a network, such as image forming apparatuses such as printers and multifunction peripherals, network-connected projectors, and network cameras. Note that the number of network devices connected to the management apparatus 102 is not limited to the example in FIG.

The management device 102 is an information processing device that manages the devices 103 , 104 and 105 . A device management application 101 and an agent application 107 operate on the management apparatus 102 .
The device management application 101 is an example of first software and is software for managing the devices 103 , 104 and 105 . The agent application 107 is an example of second software, and is software that cooperates with the device management application 101 to manage network devices.

The device management application 101 has an agent management section 111, a device management section 112, an authentication information management section 113, and a task management section 114 as software modules.
The agent management unit 111 manages information on the agent application 107 . The agent management unit 111 also manages association (linking) between identification information and authentication information of network devices to be managed by the agent application 107 .

The device management unit 112 manages information on the devices 103, 104, and 105 to be managed.
The authentication information management unit 113 manages authentication information used by the agent application 107 . Authentication information managed by the authentication information management unit 113 is stored in a storage device such as a hard disk, which will be described later.

The task management unit 114 creates tasks that define processing details such as information acquisition and setting distribution for the devices 103, 104, and 105, execution timing, and the like, and manages these tasks. For example, the tasks include a task of acquiring device configuration information, a task of searching for devices, a task of distributing an address book, and a task of distributing device setting information.

The agent application 107 has a task execution unit 121 and an authentication processing unit 122 as software modules.
The task execution unit 121 communicates with network devices using SNMP, for example, based on tasks created by the device management application 101 . The task execution unit 121 acquires various information from the devices 103, 104, and 105 or changes the setting values of the devices 103, 104, and 105 by communicating with the network devices.
The authentication processing unit 122 executes authentication processing using authentication information managed by the device management application 101 when communicating with the devices 103 , 104 and 105 .

FIG. 2 is a block diagram showing an example of the hardware configuration of the management device 102. As shown in FIG.
As shown in FIG. 2, the information processing device that operates as the management device 102 includes a CPU 201, a RAM 202, a ROM 203, a KBDC 204, a VC 205, a DC 206, and a NIC 208. CPU 201 , RAM 202 , ROM 203 , KBDC 204 , VC 205 , DC 206 and NIC 208 are interconnected via system bus 209 . An external storage device 207 is connected to the management device 102 . The management device 102 is also connected to the network 210 .
Note that CPU is an abbreviation for Central Processing Unit, and RAM is an abbreviation for Random Access Memory. ROM is an abbreviation for Read Only Memory.

The CPU 201 loads software (programs) stored in the ROM 203 or the external storage device 207 or downloaded from the network 210 into the RAM 202 as necessary and executes them. Thereby, the CPU 201 comprehensively controls each element connected to the system bus 209 .

A RAM 202 functions as a main memory or work area for the CPU 201 . The ROM 203 is a nonvolatile storage medium that stores data, various programs, various information tables, and the like.

The external storage device 207 is composed of a hard disk (HD), solid state drive (SSD), or the like. The external storage device 207 stores various applications including a boot program, an operating system (OS), an authentication server, an authentication client, database data, user files, and the like. Programs corresponding to the device management application 101 and the agent application 107 are also stored in the external storage device 207 . The CPU 201 loads these programs into the RAM 202 and executes them, thereby implementing processing described later.

A KBDC 204 is a keyboard controller, and sends input information from an input device such as a keyboard or pointing device (not shown) to the CPU 201 .
A VC 205 is a video controller that controls display on a display device such as a liquid crystal display (LCD).

A DC 206 is a disk controller and controls access to the external storage device 207 .
A NIC 208 is a communication controller, and the information processing apparatus is connected to a network 210 via the NIC 208 .

Next, common authentication information managed by the device management application 101 will be described.
Table 1 schematically shows an example of managed common authentication information. One or more pieces of authentication information are registered for each protocol, and consist of authentication type information, access right (authority) information, and authentication information. As the authentication type information, information indicating the name of the authentication type (protocol) such as "SNMPv1", "SNMPv3", etc. is held. Information indicating the type of access, such as "for reading (R)" and "for reading and writing (RW)", is held as the access right information. As the authentication information, authentication information specified by the type of authentication described in a character string in JSON format is held.

Here, the data in the first row shown in Table 1 indicates that the community names are "public", "banana", and "orange" when the authentication type is "SNMPv1" and the access right is "for reading". means The data in the second row shown in Table 1 means that the community names are "secret", "cabbage", and "carrot" when the authentication type is "SNMPv1" and the access right is "read/write". ing.

The data in the third row shown in Table 1 shows two types of authentication information with the name "admin" and "manager" when the authentication type is "SNMPv3" and the access right is "for reading". It means that the type is set. The data in the fourth row shown in Table 1 holds authentication information for SNMPv3 writing.

FIG. 3A shows a display example of a common authentication information management screen. 3A to 3C are executed by the authentication information management unit 113 of the device management application 101. FIG.

As shown in FIG. 3A, the authentication information management screen includes a table 304 listing currently set common authentication information. A table 304 in FIG. 3A shows an example in which common authentication information is set for "Read SNMPv1", "Read/Write SNMPv1", and "Read SNMPv3".
When the user's designation operation of the icon 305 indicated by an X mark at the right end of the table 304 is detected, the device management application 101 deletes the authentication information in the corresponding row from the common authentication information shown in Table 1 above. At the same time, the display of the corresponding row is deleted from the table 304 as well.

Also, when the user's specifying operation for a row in the table 304 is detected, the device management application 101 opens a screen for editing common authentication information corresponding to the clicked row.
Further, when it is detected that the add button 303 included in the authentication information management screen has been pressed, the device management application 101 adds the common authentication information selected in the authentication type selection dropdown 301 and the access right selection dropdown 302. Open the edit screen of

Note that the device management application 101 controls the dropdowns 301 and 302 so that only the types of authentication that can be added and access rights can be selected on the authentication information management screen. For example, in the case of FIG. 3A, when only SNMPv1 and SNMPv3 can be set as authentication types, only common authentication information for reading and writing SNMPv3 can be added.

FIG. 3B shows a display example of an editing screen for editing common authentication information for reading SNMPv1, which is displayed by the operation of FIG. 3A.
As shown in FIG. 3B, the edit screen includes a text box 306 for entering a community name, a save button 307 and a cancel button 308. FIG. Multiple lines of input are possible in the text box 306, and the user can input multiple community names in the text box 306 at once. In the example of FIG. 3B, "public", "banana", and "orange" are entered in the text box 306 as community names.

When it is detected that the save button 307 has been pressed, the device management application 101 associates the community name entered by the user in the text box 306 with the type of authentication (SNMPv1) and access rights, and saves common authentication information shown in Table 1. memorize to After that, the device management application 101 closes the edit screen in FIG. 3B and returns to the common authentication information setting screen in FIG. 3A.
When it is detected that the cancel button 308 has been pressed, the device management application 101 discards the edited content, closes the editing screen shown in FIG. 3B, and returns to the common authentication information setting screen shown in FIG. return.

FIG. 3(C) shows a display example of an editing screen for editing common authentication information for read/write of SNMPv3, which is displayed by the operation of FIG. 3(A).
As shown in FIG. 3C, the edit screen includes an add button 309 , a table 310 , a save button 312 and a cancel button 313 .

Table 310 shows a list of credentials to be set. When the user's designation operation of the icon 311 indicated by the cross mark on the right end of the table 310 is detected, the device management application 101 deletes the corresponding row from the table 310 . Upon detecting that the add button 309 has been pressed, the device management application 101 adds a row to the end of the table 310 .

When it is detected that the save button 312 has been pressed, the device management application 101 associates the contents of the table 310 set by the user with the type of authentication (SNMPv3) and access rights, and stores them in the common authentication information shown in Table 1. do. After that, the device management application 101 closes the edit screen of FIG. 3C and returns to the common authentication information setting screen of FIG. 3A.
When it is detected that the cancel button 313 has been pressed, the device management application 101 discards the edited content, closes the editing screen shown in FIG. 3C, and returns to the common authentication information setting screen shown in FIG. return.

Next, authentication information associated with network devices and stored by the device management application 101 will be described.
Table 2 schematically illustrates an example of authentication information associated with network devices. Note that the types of authentication, authority, and the meanings of authentication information in Table 2 are the same as in Table 1, so redundant explanations will be omitted.

The device IDs in Table 2 are identifiers that uniquely identify the devices 103, 104, and 105, respectively. Here, "4037e754", "8ff73899", and "d04973eb" indicate device IDs of devices 103, 104, and 105, respectively. This Table 2 manages the authentication information for accessing each network device for each type of authentication. For example, data in the first row of Table 2 indicates that "banana" is used as the community name when reading information from the device 103 using SNMPv1.

FIG. 4 is a flow chart illustrating the process of verifying authentication information when agent application 107 communicates with device 103 using a predetermined type of authentication that requires authentication.
In the following description, an example in which the agent application 107 acquires information from the device 103 using SNMPv1 will be described. The agent application 107 calls this authentication process together with information (device ID) that uniquely identifies the device 103 and information on the type of authentication and authority (for example, "read" of "SNMPv1").

In step S<b>401 , the agent application 107 requests the device management application 101 to acquire authentication information linked to the device 103 .

At this time, the agent application 107 specifies the device ID of the device 103, the type of authentication, and the authority, and makes the above request. The authentication information management unit 113 of the device management application 101 refers to the authentication information (Table 2) associated with the network device and returns authentication information corresponding to the request to the agent application 107 . If the authentication information corresponding to the request does not exist in Table 2, the authentication information management unit 113 returns a notification indicating that there is no authentication information.

For example, when the device ID of the request indicates the device 103, the data in the first row in Table 2 exists as data matching the device ID, authentication type, and authority. In this case, the agent application 107 acquires "banana" as the authentication information (community name). On the other hand, if the device ID of the request indicates the device 105, there is no data in Table 2 that matches the device ID, authentication type, and authority. In this case, the agent application 107 fails to obtain authentication information.

In step S402, the agent application 107 checks the acquisition result of the authentication information and determines whether the acquisition of the authentication information has succeeded. If the acquisition of the authentication information succeeds, the process proceeds to step S403, and if the acquisition of the authentication information fails, the process proceeds to step S405.

If the acquisition of the authentication information succeeds, the agent application 107 uses the acquired authentication information to perform communication for accessing the device 103 in step S403.
After that, in step S404, the agent application 107 checks the access result to the device 103 and determines whether the authentication is successful.

If the authentication is successful, the process moves to step S411. In step S411, the agent application 107 returns authentication information indicating successful authentication to the caller.
On the other hand, if authentication fails (or communication with the device 103 fails), the process proceeds to step S405.
For example, if the read community name of SNMPv1 in the device 103 is set to a value other than "banana", the agent application 107 fails authentication (communication).

If acquisition of authentication information fails (No in S402), or if authentication or communication with the device 103 fails (No in S404), the process proceeds to step S405.
In step S405, the agent application 107 requests the device management application 101 to obtain a common authentication information list.

At this time, the agent application 107 specifies the type of authentication and authority (for example, "read" of "SNMPv1") and makes the above request. The authentication information management unit 113 of the device management application 101 refers to the common authentication information (Table 1) and returns authentication information corresponding to the request to the agent application 107 . Details of this process will be described later with reference to FIG.

As an example, in Table 1, assume that SNMPv1 read/write authentication information (community name) is requested. In this case, the device management application 101 returns "secret", "cabbage", and "carrot" as SNMPv1 read/write authentication information (community names) by the processing of S502 and S506 in FIG. 5, which will be described later.

Also, in Table 1, it is assumed that SNMPv1 read authentication information is requested. In this case, the device management application 101 returns a list of authentication information created by combining SNMPv1 read authentication information and read/write authentication information through the processing of S503 to S506 in FIG. 5, which will be described later.

In step S406, the agent application 107 sequentially extracts the obtained authentication information from the list.
In step S407, the agent application 107 determines whether the retrieval of the authentication information has succeeded. If the retrieval of the authentication information fails, the process proceeds to step S412, and the agent application 107 returns a notification to the effect that the authentication has failed to the caller.

On the other hand, if it is determined in step S407 that the extraction of the authentication information has succeeded, the process proceeds to step S408.
In step S408, the agent application 107 performs communication for accessing the device 103 using the acquired common authentication information.

In step S409, the agent application 107 checks the access result to the device 103 and determines whether the authentication has succeeded.
If authentication fails (or communication with the device 103 fails), the process returns to step S406. In this case, the agent application 107 acquires the next authentication information in the list in the process of step S406.

On the other hand, if it is determined in step S409 that the authentication has succeeded, the process proceeds to step S410.
In step S410, the agent application 107 requests the device management application 101 to store the successfully authenticated authentication information in association with the device 103, authentication type, and authority. The authentication information management unit 113 of the device management application 101 stores the authentication information for each device shown in Table 2 in association with the authentication information of successful authentication with the device 103, authentication type, and authority.

After that, the processing moves to step S411, and the agent application 107 returns authentication information indicating successful authentication to the caller.
This completes the description of FIG.

In the example of this embodiment, the data in the second row of Table 2 indicates that the SNMPv1 read/write authentication information (community name) of the device 103 is "tomato". However, "tomato" is not included in the list of SNMPv1 read/write common credentials shown in the second row of Table 1.
For example, when "tomato" was previously included in the common authentication information and authentication information for reading and writing SNMPv1 of the device 103 is set to "tomato", the authentication processing in FIG. The data of the second row are stored. After that, when the user changes the authentication information shown in Table 1 using the authentication information management screen described with reference to FIG. 3, "tomato" is deleted from the common authentication information list. As described above, the above case can occur.

FIG. 5 is a flowchart for explaining the process of acquiring the common authentication information list by the device management application 101, which is called in step S405 of FIG.
When the device management application 101 receives a request from the agent application 107, the device management application 101 designates the type of authentication and authority (for example, "read" of "SNMPv1") and calls the processing in FIG.

In step S501, the device management application 101 checks access rights (authorities) for the specified authentication type. If the access right is "read/write", the process moves to step S502. On the other hand, if the access right is "read", the process moves to step S503.

In step S502, when the access right is "read/write," the device management application 101 acquires a list of specified authentication information for "read/write" from among the common authentication information shown in Table 1. After that, the process moves to step S506.

For example, assume that "read/write" of "SNMPv1" is specified as the type of authentication when obtaining the common authentication information is requested in step S405 of FIG. In this case, the list of authentication information that the device management application 101 acquires based on Table 1 by the processing in step S502 is as follows.
[secret, cabbage, carrot]
In this way, when the common authentication information for SNMP reading and writing is requested, the device management application 101 does not combine the lists (S505) as in the case of reading, which will be described later.

In step S<b>503 , when the access right is “read”, the device management application 101 acquires a list of authentication information for “read” of the designated authentication from among the common authentication information shown in Table 1.

Subsequently, in step S<b>504 , the device management application 101 acquires a list of “read/write” authentication information for designated authentication from among the common authentication information shown in Table 1. FIG.

In step S505, the device management application 101 creates a list combining the "read" authentication information list (S503) and the "read/write" authentication information list (S504). After that, the process moves to step S506.

For example, assume that "read" of "SNMPv1" is specified as the type of authentication when requesting acquisition of common authentication information in step S405 of FIG. In this case, the authentication information list created by the device management application 101 based on Table 1 through the processing of steps S503 to S505 is as follows.
[public, banana, orange, secret, cabbage, carrot]

Acquisition of information using SNMP can be performed by designating authentication information for "reading" or by designating authentication information for "reading/writing". When acquisition of a list of authentication information for SNMP "reading" is requested, as described above, the device management application 101 creates a list combining the authentication information lists for "reading" and "reading/writing". do. This process is the same for both SNMPv1 and SNMPv3.

For example, in the data in the third row of Table 2, "carrot", which is one of common "read/write" authentication information, is set in the SNMPv1 read authentication information of the device 104 . The authentication of the device 104 is performed based on a list combining the authentication information for "read" and the authentication information for "read/write", and the successfully authenticated authentication information is stored in Table 2 in association with the device 104 and the type of authentication. It shows a state where the

The reason why the SNMPv3 "read" authentication information of the device 105 in the fifth row of Table 2 matches the SNMPv3 "read/write" common authentication information in the fourth row of Table 1 is also described above. is similar to

In step S506, the device management application 101 returns the list of authentication information acquired in S502 or the list of authentication information combined in S505 to the caller.
This completes the description of FIG.

Here, assuming that authentication information to be used for communication between the management apparatus 102 and the device 103 is undetermined when the management apparatus 102 performs communication requiring authentication with the device 103, A processing example will be described.
In this case, the agent application 107 fails to acquire the authentication information from the device management application 101 because there is no saved authentication information (No in S402).

The agent application 107 acquires a list of managed common authentication information from the device management application 101 (S405). Then, the agent application 107 takes out the acquired authentication information one by one from the list, and tries authentication processing with the device 103 (loop of S406 to S409). When this authentication process succeeds, the device management application 101 stores the successfully authenticated authentication information in association with the device 103 at the request of the agent application 107 (S410).

After that, when the management apparatus 102 again communicates with the device 103 requiring authentication, the agent application 107 succeeds in acquiring the authentication information because the authentication information saved in the previous communication exists (S402). Yes). Then, the agent application 107 uses the obtained authentication information to perform communication for accessing the device 103 (S403). In this case, the authentication process is not attempted by the above loop of S406 to S409.
However, if authentication or communication using the acquired authentication information fails (No in S404), the agent application 107 acquires a common authentication information list and retries authentication processing with the device 103 ( S405-S409).

Further, in this embodiment, the authentication information managed by the management apparatus 102 in Table 2 is associated with the identification information (device ID) of the network device, but does not specify any tasks related to the network device. Therefore, the authentication information managed by the management apparatus 102 in Table 2 can be shared and used in a plurality of tasks as long as the device ID, authentication type, and authority match.
For example, when the agent application 107 communicates with the device 103 using a predetermined protocol when executing a first task, the agent application 107 communicates with the device 103 using a predetermined protocol stored by authentication when executing another second task. credentials can be used.

The following is an example of sharing authentication information among multiple tasks. For example, a common SNMP is used in communications for tasks to acquire device configuration information and tasks to search for devices. Therefore, when the device ID, the type of authentication, and the authority match, authentication information can be shared between the task of acquiring device configuration information and the task of searching for a device. Similarly, authentication information can be shared between, for example, a task of distributing an address book and a task of distributing device setting information when the device ID, authentication type, and authority match.

(Second embodiment)
Next, a second embodiment will be described. Note that the overall configuration of the network device management system and the application of the management device in the second embodiment are the same as those in the first embodiment, so redundant description will be omitted.

The authentication process inside the device may vary depending on the device settings. For example, it can be set to authenticate the device in conjunction with an authentication system on the network, or to authenticate the device based on authentication information stored inside the device. Authentication systems on networks also include, for example, those that perform authentication using user names and passwords, those that perform authentication using domain names, user names, and passwords, and the like. In the case of a function call by a web service, access control using an authentication ticket is often performed using a technique such as SAML (Security Assertion Markup Language) in order to absorb these differences in authentication processing.

Therefore, in the second embodiment, an example of device authentication using a web service will be described.
FIG. 6 is a flowchart for explaining processing when the agent application 107 connects to the device 103 using the WEB service.
Here, the device 103 in the second embodiment has a web service section 601 and an authentication processing section 602, as shown in FIG. It should be noted that other network devices to be managed in the second embodiment also have the web service unit 601 and the authentication processing unit 602 as required, like the device 103 .

First, in step S601, the agent application 107 of the management apparatus 102 requests the device 103 for a list of authentication types currently supported by the device.
In step S<b>602 , the web service processing unit 601 of the device 103 that has received this request returns a list 603 of authentication types currently supported by itself to the management apparatus 102 .

At step S603, the agent application 107 sends an authentication request including the authentication information 604 to the device 103. FIG. The authentication type of the authentication information 604 sent in step S603 is supported by the authentication type list 603 returned from the device 103 .

In step S<b>604 , the web service processing unit 601 of the device 103 that has received the authentication request requests the authentication processing unit 602 corresponding to the specified authentication type within the device 103 to verify the authentication information 604 .
In step S<b>605 , the authentication processing unit 602 verifies the authentication information received from the web service processing unit 601 and returns the verification result to the web service processing unit 601 .

The web service processing unit 601 generates an authentication ticket 605 when the verification result of the authentication information is successful.
Then, in step S606, the web service processing unit 601 returns the generated authentication ticket 605 to the agent application 107 that called it.
Although not shown, if the authentication fails, the web service processing unit 601 returns a response to the effect that the authentication has failed to the agent application 107 .

At step S607, the agent application 107 sends the request to the device 103 including the authentication ticket 605. FIG. The request transmitted in step S607 is, for example, a request to acquire information from the device 103 or a request to change the setting value of the device 103. FIG.

The web service unit 601, which has received the request in step S607, extracts the authentication ticket 605 from the request and verifies it. If the verification of the authentication ticket 605 is successful, the web service unit 601 executes the processing requested by the agent application 107 .
In step S<b>608 , the web service unit 601 returns the requested processing result to the agent application 107 . It should be noted that if the verification of the authentication ticket 605 fails, the web service execution unit 601 returns a notification of authentication failure to the agent application 107 .
This completes the description of FIG.

In the second embodiment, the content of authentication information differs depending on the authentication type. The authentication information includes a personal identification number consisting only of numerical values, a password character string, a combination of a user name and password, a combination of a domain name, a user name and a password, and the like.

Table 3 shows examples of combinations of authentication types and authentication information in the second embodiment. For example, for authentication type "ADMIN", an administrator's password is required to access device 103 as an administrator. In the case of the authentication type "SSO", the network device requests authentication by user name and password to the external system. For the authentication type “LDAP”, the network device cooperates with the LDAP server to perform authentication.

FIG. 7A shows a display example of a common authentication information management screen in the second embodiment. 7A and 7B are executed by the authentication information management unit 113 of the device management application 101. FIG.

The common authentication information management screen shown in FIG. 7A corresponds to the common authentication information management screen shown in FIG. 3A. Therefore, in FIG. 7(A), elements common to those in FIG. 3(A) are assigned the same reference numerals, and duplicate descriptions thereof are omitted.
In FIG. 7A, as the common authentication information listed in the table 304, there are cases where the authentication types are "PIN", "password", and "user authentication (combination of user name and password)". Added. Further, the authentication type selection dropdown 301 in FIG. 7A indicates that "domain authentication (combination of domain name, user name and password)" can be selected.

FIG. 7B shows a display example of an editing screen for editing common authentication information for reading and writing domain authentication, which is displayed by the operation of FIG. 7A.
As shown in FIG. 7B, the edit screen includes an add button 701 , a table 702 , a save button 704 and a cancel button 705 .

Table 702 shows a list of credentials to be set. When the user's designation operation of the icon 703 indicated by an X mark at the right end of the table 702 is detected, the device management application 101 deletes the corresponding row from the table 702 . Upon detecting that the add button 701 has been pressed, the device management application 101 adds a row to the end of the table 702 .

When it is detected that the save button 704 has been pressed, the device management application 101 associates the contents of the table 702 set by the user with the type of authentication (domain authentication) and authority, and stores them in common authentication information. After that, the device management application 101 closes the edit screen of FIG. 7B and returns to the common authentication information setting screen of FIG. 7A.
When it is detected that the cancel button 705 has been pressed, the device management application 101 discards the edited content, closes the edit screen shown in FIG. 7B, and returns to the common authentication information setting screen shown in FIG. 7A. return.
Note that the editing screens for "PIN", "password", and "user authentication" are the same as those in FIG.

Table 4 schematically shows an example of managed common authentication information in the second embodiment. In Table 4, as authentication information registered at least one for each authentication type, authentication information data related to new authentication types "PIN", "Password", "User", and "Domain" are added. Other than that, since it is the same as Table 1, description is omitted.

Table 5 schematically shows an example of authentication information associated with network devices in the second embodiment.
In Table 5, "WebService", which does not exist in the authentication types of common authentication information in Table 4, is set. The authentication information of "WebService" in Table 5 stores the authentication information of the common authentication setting in Table 4 as the type of authentication.

FIG. 8 is a flow chart illustrating processing for confirming authentication information when the agent application 107 communicates with the device 103 using a predetermined type of authentication requiring authentication in the second embodiment.

In step S<b>801 , the agent application 107 acquires from the device 103 a list of web service authentication types currently supported by the device 103 . This process is implemented by steps S601 and S602 in FIG.
For example, the list returned from the device 103 is as follows.
[“LDAP”, “NTLM”]

In step S<b>802 , the agent application 107 requests the device management application 101 to acquire authentication information linked to the device 103 .

At this time, the agent application 107 specifies the device ID of the device 103, the type of authentication, and the authority (for example, "read/write" of "web service") to make the above request. The authentication information management unit 113 of the device management application 101 refers to the authentication information (Table 5) associated with the network device and returns authentication information corresponding to the request to the agent application 107 . If the authentication information corresponding to the request does not exist in Table 5, the authentication information management unit 113 returns a notification indicating that there is no authentication information.

For example, in the case of web service read/write for the device 103, the agent application 107 acquires the following authentication information.
{"type":"LOCAL", "auth":{"name":"admin", "pass":"53cr3txx."}}

In step S803, the agent application 107 checks the acquisition result of the authentication information and determines whether the acquisition of the authentication information has succeeded. If the acquisition of the authentication information succeeds, the process proceeds to step S804, and if the acquisition of the authentication information fails, the process proceeds to step S807.

In step S<b>804 , the agent application 107 determines whether the authentication type acquired from the device management application 101 (“LOCAL” in the above example) is included in the list of authentication types acquired from the device 103 .
If the authentication type acquired in step S802 matches any one of the authentication type list in step S803, the process proceeds to step S805. If the authentication type acquired in step S802 does not match the list of authentication types in step S803, the process proceeds to step S807.

If the acquired authentication type matches any of the authentication type lists, then in step S805 the agent application 107 communicates to access the device 103 using the acquired authentication information. This communication corresponds to step S603 in FIG.
After that, in step S806, the agent application 107 checks the access result to the device 103 and determines whether the authentication is successful.

If the authentication succeeds, the process moves to step S813. In step S813, the agent application 107 returns the authentication ticket (605) acquired from the device 103 to the caller.
On the other hand, if authentication fails (or communication with the device 103 fails), the process proceeds to step S807.

If acquisition of authentication information fails (No in S803), if the acquired authentication type does not match the authentication type list (No in S804), or if authentication or communication with the device 103 fails (No in S806) , the process proceeds to step S807.
In step S807, the agent application 107 requests the device management application 101 to obtain a common authentication information list.

At this time, the agent application 107 designates the type of authentication and makes the above request. The authentication information management unit 113 of the device management application 101 refers to the common authentication information (Table 4) and returns authentication information corresponding to the request to the agent application 107 . Details of this process will be described later with reference to FIG.

In step S<b>808 , the agent application 107 sequentially extracts authentication information that matches authentication types supported by the device 103 from the list of common authentication information acquired from the device management application 101 .
In the above example, authentication information whose authentication type is "LDAP" or "NTLM" is sequentially extracted from the list of common authentication information acquired from the device management application 101. FIG.

In step S809, the agent application 107 determines whether the retrieval of the authentication information has succeeded. If the retrieval of the authentication information fails, the process proceeds to step S814, and the agent application 107 returns a notification to the effect that the authentication has failed to the caller.

On the other hand, if it is determined in step S809 that the extraction of the authentication information has succeeded, the process proceeds to step S810.
In step S810, the agent application 107 performs communication for accessing the device 103 using the acquired common authentication information. This communication corresponds to step S603 in FIG.

In step S811, the agent application 107 checks the access result to the device 103 and determines whether the authentication has succeeded.
If authentication fails (or communication with the device 103 fails), the process returns to step S808. In this case, the agent application 107 acquires the next authentication information in the list in the process of step S808.

On the other hand, if it is determined in step S811 that the authentication has succeeded, the process proceeds to step S812.
In step S812, the agent application 107 requests the device management application 101 to store the successfully authenticated authentication information in association with the device 103 and authentication type. The authentication information management unit 113 of the device management application 101 stores the authentication information for each device shown in Table 5 in association with the authentication information of successful authentication with the device 103, authentication type, and authority.

After that, the processing moves to step S813, and the agent application 107 returns the authentication ticket (605 in FIG. 6) acquired from the device 103 to the caller. This communication corresponds to step S607 in FIG.
This completes the description of FIG.

FIG. 9 is a flowchart for explaining the process of acquiring the common authentication information list by the device management application 101, which is called in step S807 of FIG.
Upon receiving a request from the agent application 107, the device management application 101 designates the type of authentication and authorization, and calls the processing in FIG.

In step S901, the device management application 101 determines whether the designated authentication type is a web service (WebService). If the type of authentication is web service, the process moves to step S903. On the other hand, if the type of authentication is not a web service, the process moves to step S902.

If the specified authentication type is not a web service, the device management application 101 acquires the specified authentication type and access right information from the common authentication information in Table 4 in step S902. After that, the process moves to step S905.

On the other hand, if the designated authentication type is the web service, the device management application 101 acquires authentication information to be used for the web service from the common authentication information in Table 4 in step S903.
Here, the authentication information used in the WEB service is, for example, among the common authentication information, the authentication types "PIN", "Password", "User", and "Domain".

Next, in step S904, the device management application 101 creates authentication information for the web service from the authentication information acquired in step S903. After that, the process moves to step S905.
The authentication information created in S904 is a combination of authentication information whose authentication types are "PIN", "Password", "User", and "Domain". As an example, an example of authentication information for a web service created from Table 4 is shown below.

In step S905, the device management application 101 returns the authentication information list acquired in S902 or the authentication information list created in S904 to the caller.
This completes the description of FIG.

(Third embodiment)
Next, a third embodiment will be described. FIG. 10 shows an example of the overall configuration of a device management system according to this embodiment. In the following description, the same reference numerals are used for the same components as in the first embodiment and the second embodiment, and redundant description is omitted.

In this embodiment, the device management system comprises one device management application 101 and multiple agent applications 107 , 1001 and 1005 . Here, the device management application 101 and agent applications 1001 and 1005 operate on different devices. On the other hand, the agent application 107 may run on the management apparatus 102 on which the device management application 101 runs, or on another apparatus.

The components of the software modules of the device management application 101 and agent application 107 shown in FIG. 10 are the same as in FIG. 10 are the same as those of the agent application 107 shown in FIG.

The agent application 107 of this embodiment communicates with the devices 103, 104, and 105 and executes various processes. Similarly, agent application 1001 communicates with devices 1002, 1003, and 1004 to perform various processes. The agent application 1005 communicates with the devices 1006, 1007 and 1008 and executes various processes.

The device management application 101 of this embodiment assigns devices to each agent application according to device addresses and network names. The device management application 101 allocates devices with IP addresses in the range of 192.168.0.0 to 192.168.9.255 to the agent application 107, for example. Also, the device management application 101 allocates to the agent application 1001 devices whose IP addresses are in the range of 192.168.10.0 to 192.168.19.255, for example.

It is assumed that each device in this embodiment is assigned an appropriate IP address according to the location where the device is installed. For example, devices with IP addresses in the range 192.168.0.0 to 192.168.9.255 are located in the Tokyo office and have IP addresses from 192.168.10.0 to 192.168.19.255. shall be located in the London office. In other words, the device in the Tokyo office is assigned to the agent application 107, and the device in the London office is assigned to the agent application 1001, respectively.

Table 7 shows the correspondence between agent applications and device IP addresses assigned to the agent applications. Here, the agent ID is an identifier (character string) generated by the device management application 101 for uniquely identifying each agent application. The agent name is a character string set by the user to identify each agent application. In the example of Table 7, the agent names of agent applications 107, 1001 and 1005 are "Tokyo", "London" and "Chicago" respectively.

Table 8 schematically shows an example of common authentication information managed by the device management application 101. In Table 8, the agent application to which each authentication information applies is shown in the "Agent ID" column. Here, "*" means that the authentication information is used for all agent applications. The following items (1) to (4) are set in the table of Table 8.

(1) Common authentication information whose authentication type is "SNMPv1", access right is "read", and community name is "public" is used by all agent applications.
(2) Common authentication information with authentication type "SNMPv3", access right "read/write", user name "admin", and authentication key "cabbage" is used by all agent applications.

(3) Common authentication information with authentication type "SNMPv3", access right "read/write", user name "manager", and authentication key "apple" is used by the agent application with agent ID "64d968ecc9cc". . The agent ID "64d968ecc9cc" is an agent application whose agent name is "Tokyo".

(4) Common authentication information with authentication type "SNMPv3", access right "read/write", user name "manager", and authentication key "banana" is an agent whose agent ID is "1a1b7bce6bb0" or "dd858a155274". Use in your application. The agent IDs "1a1b7bce6bb0" and "dd858a155274" are agent applications whose agent names are "London" and "Chicago", respectively.

FIGS. 11A and 11B show display examples of a common authentication information management screen in this embodiment. 11A and 11B are executed by the authentication information management unit 113 of the device management application 101. FIG. FIGS. 11A and 11B are display examples of the screens of FIGS. 3A and 3C in the first embodiment, according to the present embodiment. Therefore, only differences from FIGS. 3A and 3C will be described here.

As shown in FIG. 11A, the authentication information management screen includes a table 304 listing currently set common authentication information. In table 304 of FIG. 11A, column 1101 corresponding to "agent" indicates the agent name of the agent application that uses each common authentication information. In the display of column 1101 in FIG. 11A, when used in all agent applications, a character string to that effect may be displayed instead of the agent name.

FIG. 11B shows a display example of an editing screen for editing common authentication information for read/write of SNMPv3. In the edit screen shown in FIG. 11B, items (1102 to 1108) for setting agent applications that use authentication information are added compared to the screen in FIG. 3C. Here, the above items 1102 to 1108 are displayed on the screen regardless of the type of authentication information to be edited.

Radio buttons 1102 and 1103 shown in FIG. 11B are used to set whether to use the authentication information in all agent applications or individually specify agent applications that use the authentication information. When radio button 1102 (Use this credential for all agents) is selected, control 1104 for selecting an agent in FIG. 11B is disabled. On the other hand, if radio button 1103 (Use this credential with the selected agent) is selected, control 1104 for selecting an agent in FIG. 11B becomes available.

The control 1104 shown in FIG. 11B also includes checkboxes 1105-1108.
Check boxes 1106 to 1108 are check boxes for individually selecting each agent. Checkboxes 1105 are checkboxes for selecting all (or deselecting all) each agent in control 1104 .

When it is detected that the save button 312 has been pressed, the device management application 101 stores the type of authentication information, the access right, the authentication information entered by the user, and the setting of the agent application that uses the authentication information in the common settings shown in Table 8. Store in authentication information. After that, the device management application 101 closes the editing screen in FIG. 11B and returns to the common authentication information setting screen in FIG. 11A.

FIG. 12 is a flowchart showing the details of the authentication information acquisition process in steps S502, S503, and S504 of the authentication information acquisition process shown in FIG.
The agent-designated authentication information acquisition process shown in FIG. 12 is called with the agent ID that uniquely identifies the agent application, the type of authentication, and access rights. In each step of FIG. 5, the process of FIG. 12 is called using its own agent ID.

In step S1201, the processing for obtaining agent-specified authentication information obtains (a plurality of) items that can be used by all agent applications from the specified authentication type and common authentication information having access rights.

In step S1202, the agent-specified authentication information acquisition process acquires information that can be used by the agent application indicated by the specified agent ID from the specified authentication type and common authentication information having access rights.

In step S1203, the processing for acquiring agent-designated authentication information combines the common authentication information acquired in steps S1201 and S1202, and returns the combined information to the caller. After that, the processes after step S506 in FIG. 5 are executed.

For example, in the settings in Table 8, consider a case where the authentication type is "SNMPv3", the access right is "read/write", and the agent ID is "1a1b7bce6bb0", and the process in FIG. 12 is called. In this case, the common authentication information in rows 2 and 4 of Table 8 is returned to the caller.

(Application example)
In FIG. 12, authentication information that can be used by all agent applications is acquired in S1201, but the process of S1202 in FIG. 12 may be executed first. Further, if the authentication information corresponding to the designated agent ID can be acquired in the processing of S1202 that has been executed in advance, the processing of S1201 may be skipped.
This application allows only preconfigured combinations of authentication information for an agent ID to be attempted during authentication.

(Other embodiments)
The present invention supplies a program that realizes one or more functions of the above-described embodiments to a system or device via a network or a storage medium, and one or more processors in the computer of the system or device reads and executes the program. It can also be realized by processing to It can also be implemented by a circuit (for example, ASIC) that implements one or more functions.

Although preferred embodiments of the present invention have been described above, the present invention is not limited to these embodiments, and various modifications and changes are possible within the scope of the gist thereof.

101 Device management application 102 Management apparatus 103, 104, 105 Device 107 Agent application 113 Authentication information management unit 121 Authentication processing unit

Claims (11)

management means for managing information required for authentication, which is registered at least one for each protocol as common authentication information;
When authentication is required when communicating with a network device, if the authentication information to be used for the communication has not been determined, the network device is sequentially used one by one from the managed common authentication information. a communication means for attempting an authentication process with
storage means for storing authentication information used in the authentication in association with the network device when the authentication is successful;
When authentication is required when communicating with the network device, the communication means saves the authentication information used for the communication without performing the trial. A management system characterized by performing communication using authentication information. the management means and the storage means are implemented by processing of a first application that manages the common authentication information;
2. The management system according to claim 1, wherein said communication means is realized by processing of a second application different from said first application. The management means further manages a protocol and common authentication information in association with the identification information of the second application,
When authentication is required when communicating with the network device, the communication means is managed in association with the identification information of the second application if authentication information to be used for the communication is undetermined. 3. The management system according to claim 2, wherein an authentication process with the network device is attempted by sequentially using the common authentication information one by one. wherein, when communication using the stored authentication information fails, the communication means sequentially uses the managed common authentication information one by one to retry authentication processing with the network device. 4. Management system according to any one of claims 1 to 3. The storage means stores the successfully authenticated authentication information in association with the network device for each protocol,
The communication means uses the authentication information corresponding to the predetermined protocol stored in association with the network device when authentication is required when communicating with the network device using a predetermined protocol. 5. The management system according to any one of claims 1 to 4, characterized in that: The communication means are
when authentication is required when communicating with the network device using the predetermined protocol in order to perform a first task;
The authentication information stored in association with the predetermined protocol and the network device and used for authentication when executing a second task different from the first task is shared for use. 6. Management system according to claim 5. The management means further manages, as the common authentication information, one or more pieces of information necessary for authentication, which are registered for each authentication type of the web service corresponding to the network device,
The communication means are
obtaining the authentication type corresponding to the network device from the network device when authentication is required when communicating with the network device using a web service;
If authentication information to be used for said communication is undecided, trying authentication processing with said network device by sequentially using managed common authentication information corresponding to said acquired authentication type one by one. Management system according to any one of claims 1 to 6. when authentication using the authentication information corresponding to the authentication type is successful, the storage means stores the authentication information in association with the network device as authentication information for the web service;
When authentication is required when communicating with the network device using a web service, the communication means does not perform the trial if authentication information for the web service is stored. 8. The management system according to claim 7, wherein communication is performed using the stored authentication information. The communication means fails in communication using the stored authentication information for the web service, or the authentication type of the stored authentication information for the web service does not match the authentication type acquired from the network device. 9. The method according to claim 8, wherein, in the event of a failure, authentication processing with the network device is retried by sequentially using one of the managed common authentication information corresponding to the acquired authentication type. management system. A method in a management system for managing network devices, comprising:
a management process for managing information necessary for authentication, which is registered at least one for each protocol as common authentication information;
When authentication is required when communicating with a network device, if the authentication information to be used for the communication has not been determined, the network device is sequentially used one by one from the managed common authentication information. a communication step of attempting an authentication process with
a saving step of, when the authentication is successful, storing the authentication information used in the authentication in association with the network device;
In the communication step, when authentication is required when communicating with the network device, and authentication information used for the communication is saved, the saved authentication information is saved without performing the trial. A method characterized in that communication is performed using authentication information. A computer in a management system for managing network devices,
management means for managing information required for authentication, which is registered at least one for each protocol as common authentication information;
A program for functioning as storage means for storing authentication information to be used for authentication in association with a network device,
When authentication is required when communicating with a network device, if the authentication information to be used for the communication is undecided, one by one sequentially from the common authentication information managed by the management means authentication processing with the network device is attempted using
When authentication is required when communicating with the network device, if the authentication information used for the communication has been stored by the storage means, it is stored without performing the trial. A program characterized by communication using authentication information.

Images